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

"Joel M. Halpern" <> Fri, 16 December 2016 05:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6398129553; Thu, 15 Dec 2016 21:07:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YsEuubBB5JRT; Thu, 15 Dec 2016 21:07:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2595A129549; Thu, 15 Dec 2016 21:07:10 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF98E401ED4; Thu, 15 Dec 2016 21:07:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1.tigertech; t=1481864829; bh=WPhARhfE/nNCXhgZanIR3g9xth5XWN0+BERVhwquwTo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=RuFuhb9Z1mhczfXR6zg/IGnfJMBfssSNmrdyyg4Uo5uPNqPnRqqpoXZCwYI3gcOMl IUNeWZ0PY7XHZBZEfuqTo7gpQT2igpUvSMqfLfXJC7CbQzJRqXtLQ2Z9/25fdIl4B2 7tSZMMisg5r88b4RRwqZCPokMySWu9IOdXWSkiGY=
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C7D421C00F6; Thu, 15 Dec 2016 21:07:08 -0800 (PST)
Subject: Re: Review of draft-mohali-dispatch-cause-for-service-number-12
To: Ben Campbell <>
References: <> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Fri, 16 Dec 2016 00:07:07 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: General Area Review Team <>,,,
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: Fri, 16 Dec 2016 05:07:12 -0000

At this point I will defer to the relevant ADs.
As far as I can tell, although the entry was created by an Informational 
RFC, the registry still claims that it is standards track.
And since this document is defining behavior, it behaves more like a 
standards track document than an Informational one.

But it is up to you folks.  In teh end, all I can do is raise the 
question, not decide it :-)


On 12/15/16 11:51 PM, Ben Campbell wrote:
>> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern <> wrote:
>> I see your point about this adding a value to the entry created by RFC 4458.
>> Is there a reason this can not simply be PS?  The fact that 4458 is Informational does not, as far as I can tell, justify continuing the error.  While this is for a 3GPP usage, it appears to have been reviewed by the Dispatch WG sufficiently to justify PS.
>> One could argue that there is a down-ref issue,
>> but the fact that the field is in a standards-track required registry would seem to make that a moot point.
> Do you think it makes sense to make some new values for “cause” into a proposed standard when “cause” itself is informational?  That seems like a pretty big downref issue, as such issues go. (For the record, I could be convinced to re-run this LC as PS, but I suspect that would lead to objections in the opposite direction.)
> Right now, the situation is a standards-action registry with a informational entry. That’s clearly broken, but I’m not sure that _this_ draft is the place to fix it.
> Also, if it makes any difference—even there there was discussion in dispatch, this is not a dispatch work item.
>> Yours,
>> Joel
>> PS: It would seem that WG discussion of that sort is something we would like to see in Shepherd writeups.
> There’s two paragraphs on the subject in section (1) of the shepherd writeup :-)  (but it wasn’t a working group discussion per se.)
> Thanks!
> Ben.
>> On 12/15/16 11:28 PM, Ben Campbell wrote:
>>> Hi Joel,
>>> Thanks for the comments. There has been a fair amount of discussion
>>> about the status of the draft. The situation is clearly not optimal, and
>>> I welcome input on how to straighten it out.
>>> The rational so far has been that this draft updates RFC 4588, which is
>>> informational. It adds some additional values and related semantics for
>>> the "cause" parameter from 4588. It does not register new parameters;
>>> rather it adds itself as a reference in the existing "cause"
>>> registration. This is mainly a courtesy to readers. (There is no
>>> sub-registry for "cause" parameter values.) We might could get by
>>> without that change, since in a perfect world people following the IANA
>>> reference to 4588 would notice the "Updated by..." tag.
>>> 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. Making
>>> the new values from _this_ draft standards track, when the parameter
>>> itself is not, doesn't seem appropriate. We had some discussion about
>>> whether we should promote 4588 to PS, but there was not consensus to do
>>> so when it was published, and I don't see reason to expect that to have
>>> changed.
>>> This draft is primarily intended to meet a need in 3GPP, where I
>>> understand they are effectively already doing this. Would it help to
>>> more tightly scope this as "Here's something 3GPP is doing..." rather
>>> than as a general mechanism?
>>> Thanks!
>>> Ben.
>>> On 15 Dec 2016, at 21:57, Joel Halpern wrote:
>>>> Reviewer: Joel Halpern
>>>> Review result: Ready with Issues
>>>> Major:
>>>>    This document defines a new code for use in SIP, and specifies new
>>>> behavior both for the code itself and for its use in history-info.  I
>>>> am thus confused as to how this can be an informational RFC.  It looks
>>>> like it either Proposed Standard or experimental.  Yes, I see that RFC
>>>> 4458, which this updates is Informational.  But just because we did it
>>>> wrong before does not make that behavior correct now.  In addition to
>>>> my understanding of the roles of different RFCs, I note that RFC 3969
>>>> and the IANA registry both state that this assignment must be made by
>>>> a standards track RFC.
>>>> Minor:
>>>>   Given our emphasis on IPv6 over IPv4, would it not make sense for
>>>> the examples to use IPv6 addresses?  (Inspired by the Id-Nits alert.)