|
Re: Review of draft-mohali-dispatch-cause-for-service-number-12
2016-12-19 12:31:54
On 19 Dec 2016, at 11:11, Cullen Jennings wrote:
On Dec 15, 2016, at 10:07 PM, Joel M. Halpern <jmh(_at_)joelhalpern(_dot_)com>
wrote:
At this point I will defer to the relevant ADs.
+1 on that :-)
:-)
As far as I can tell, although the entry was created by an
Informational RFC, the registry still claims that it is standards
track.
And since this document is defining behavior, it behaves more like a
standards track document than an Informational one.
But it is up to you folks. In teh end, all I can do is raise the
question, not decide it :-)
So the registry takes PS to change it.
To reiterate a previous comment on the thread: This draft does not add
an entry to the registry, rather it adds a reference to an existing
entry. The only point of the registry change is to make it convenient
for implementors to discover that this draft updates 4458, which
registered the entry in the first place. I'm not convinced that's
completely necessary. But it might make sense to relax the standards
action for this particular entry for historical reasons.
(Recognizing that the SIP URI parameter registry is messed up, also for
"historical reasons".)
And by the current SIP rules, I suspect (not sure) that an update to
4458 would also have to be PS. So really not sure how one gets around
this not being PS.
I think this is the important decision to make. Setting the draft status
based on the registration policy is an exercise in dog-wagging.
Yours,
Joel
On 12/15/16 11:51 PM, Ben Campbell wrote:
On Dec 15, 2016, at 10:35 PM, Joel M. Halpern <jmh(_at_)joelhalpern(_dot_)com>
wrote:
I see your point about this adding a value to the entry created by
RFC 4458.
Is there a reason this can not simply be PS? The fact that 4458 is
Informational does not, as far as I can tell, justify continuing
the error. While this is for a 3GPP usage, it appears to have been
reviewed by the Dispatch WG sufficiently to justify PS.
One could argue that there is a down-ref issue,
but the fact that the field is in a standards-track required
registry would seem to make that a moot point.
Do you think it makes sense to make some new values for “cause”
into a proposed standard when “cause” itself is informational?
That seems like a pretty big downref issue, as such issues go. (For
the record, I could be convinced to re-run this LC as PS, but I
suspect that would lead to objections in the opposite direction.)
Right now, the situation is a standards-action registry with a
informational entry. That’s clearly broken, but I’m not sure
that _this_ draft is the place to fix it.
Also, if it makes any difference—even there there was discussion
in dispatch, this is not a dispatch work item.
Yours,
Joel
PS: It would seem that WG discussion of that sort is something we
would like to see in Shepherd writeups.
There’s two paragraphs on the subject in section (1) of the
shepherd writeup :-) (but it wasn’t a working group discussion
per se.)
Thanks!
Ben.
On 12/15/16 11:28 PM, Ben Campbell wrote:
Hi Joel,
Thanks for the comments. There has been a fair amount of
discussion
about the status of the draft. The situation is clearly not
optimal, and
I welcome input on how to straighten it out.
The rational so far has been that this draft updates RFC 4588,
which is
informational. It adds some additional values and related
semantics for
the "cause" parameter from 4588. It does not register new
parameters;
rather it adds itself as a reference in the existing "cause"
registration. This is mainly a courtesy to readers. (There is no
sub-registry for "cause" parameter values.) We might could get by
without that change, since in a perfect world people following the
IANA
reference to 4588 would notice the "Updated by..." tag.
The gotcha is that RFC 4588 would not be possible as an
informational
today; it would not have standing to register the "cause"
parameter. But
at the time it was published, there was a lack of clarity around
the
"standards action" policy for the SIP URI parameters registry.
Making
the new values from _this_ draft standards track, when the
parameter
itself is not, doesn't seem appropriate. We had some discussion
about
whether we should promote 4588 to PS, but there was not consensus
to do
so when it was published, and I don't see reason to expect that to
have
changed.
This draft is primarily intended to meet a need in 3GPP, where I
understand they are effectively already doing this. Would it help
to
more tightly scope this as "Here's something 3GPP is doing..."
rather
than as a general mechanism?
Thanks!
Ben.
On 15 Dec 2016, at 21:57, Joel Halpern wrote:
Reviewer: Joel Halpern
Review result: Ready with Issues
Major:
This document defines a new code for use in SIP, and specifies
new
behavior both for the code itself and for its use in
history-info. I
am thus confused as to how this can be an informational RFC. It
looks
like it either Proposed Standard or experimental. Yes, I see
that RFC
4458, which this updates is Informational. But just because we
did it
wrong before does not make that behavior correct now. In
addition to
my understanding of the roles of different RFCs, I note that RFC
3969
and the IANA registry both state that this assignment must be
made by
a standards track RFC.
Minor:
Given our emphasis on IPv6 over IPv4, would it not make sense
for
the examples to use IPv6 addresses? (Inspired by the Id-Nits
alert.)
|
|