Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]