|
I still think the shepherd's writeup caught this correctly:
draft-mohali-dispatch-service-number-translation
does not register a URI parameter; it just adds a reference
to an existing registration. The decision to keep these
documents informational is not intended to set precedent;
RFC 5727 remains the BCP for the SIP change process.
I personally see no win in trying to force this document to be PS
(and fixing the things in it, and in what 3gpp plans to do with it
to let it fly as PS) or in changing the registry at this point. This
has an odor, but it is not really making the world worse, and the
energy that it would require from ours and the 3gpp communities to
remove the odor does not strike me as the right place to make our
investements.
Hold your noses and let this go please.
One more general comment inline below:
RjS
On 12/20/16 5:03 PM, Ben Campbell
wrote:
On 20 Dec 2016, at 16:49, Adam Roach wrote:
On 12/15/16 22:28, Ben Campbell wrote:
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.
I don't think that's true. We're talking about a registry
established by RFC 3969, which says:
"SIP and SIPS URI parameters and values for these parameters
MUST be
documented in a standards-track RFC in order to be registered
by
IANA."
...and...
"For the purposes of this registry, the parameter for which
IANA
registration is requested MUST be defined by a
standards-track RFC."
These are not ambiguous statements. We just botched our
communication with IANA.
For the record, I did not say the RFC was ambiguous. I said "we
had a lack of clarity". I think having one policy listed in IANA
and another in the RFC counts. I offer as evidence of said lack of
clarity the fact that RAI got things wrong with 4458 (My typo of
it as 4588 above upthread couldn't help, either) :-)
But I think we can do the right thing here without going back
and fixing all of the issues with our ancestral documents. I
mean, sure, maybe we should clean that up too, but I don't see
the value in blocking new work on doing so.
In terms of publishing
draft-mohali-dispatch-cause-for-service-number, I think there
are two reasonable paths forward:
The first would be forming consensus that the two statements I
quote from 3969 above -- and the reinforcing statement in 5727
-- were all incorrect, and that we want to explicitly (i.e., in
a new document) reverse those statements and update the
corresponding registration policy. Then, we publish -mohali- as
informational.[1]
The second would be implicitly accepting established consensus
around this registry, and consequently changing -mohali- to PS.
I think a potential third option is to consider whether -mohali-
really needs to modify the registry. (I'm not saying it
doesn't--I'm saying we should think about it.)
Rather than figuring out which of these is easier (clearly, the
second is less work), I think the real question here is: do we
think we got the registration policy for SIP URI parameters
wrong?
Keep in mind that the registry is not the only concern mentioned
so far. Both 4458 and -mohali- define protocol. Reviewers have
objected to that as well.
We have _MANY_ Informational documents that define protocol. That,
by itself, is not the metric for "not Informational".
|