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

Robert Sparks <> Tue, 20 December 2016 23:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26BD2129694; Tue, 20 Dec 2016 15:27:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.999
X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HBZKXcM4hV5H; Tue, 20 Dec 2016 15:27:47 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DAF73129437; Tue, 20 Dec 2016 15:27:46 -0800 (PST)
Received: from unnumerable.local ([]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id uBKNRjXp009257 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 20 Dec 2016 17:27:46 -0600 (CST) (envelope-from
X-Authentication-Warning: Host [] claimed to be unnumerable.local
Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12
To: Ben Campbell <>, Adam Roach <>
References: <> <> <> <>
From: Robert Sparks <>
Message-ID: <>
Date: Tue, 20 Dec 2016 17:27:45 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------94E9583D5F35954B6EB6B176"
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Dec 2016 23:27:48 -0000

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:


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