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".