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

[Robert Sparks <[e-mail]>]

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