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

"Ben Campbell" <ben@nostrum.com> Mon, 19 December 2016 18:22 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5EC1295A2; Mon, 19 Dec 2016 10:22:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLQG1RGuMw2h; Mon, 19 Dec 2016 10:22:40 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E026129583; Mon, 19 Dec 2016 10:22:40 -0800 (PST)
Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBJIMcKF051215 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 19 Dec 2016 12:22:39 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39]
From: "Ben Campbell" <ben@nostrum.com>
To: marianne.mohali@orange.com
Subject: Re: Review of draft-mohali-dispatch-cause-for-service-number-12
Date: Mon, 19 Dec 2016 12:22:38 -0600
Message-ID: <F61F905C-1E6D-44E8-80E9-191088FF7DA3@nostrum.com>
In-Reply-To: <26405_1482168677_58581965_26405_11893_1_8B970F90C584EA4E97D5BAAC9172DBB81C884468@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> <f0e5f66a-a7be-8d4e-a865-2ba4a27d6a3a@joelhalpern.com> <EF7BE2FF-410D-4C4A-8CAC-2282726E1B5E@nostrum.com> <50a163d3-0ca0-fdd0-7cb8-b09de0a5a5e2@joelhalpern.com> <1BDDB9BA-E712-4DC8-9194-A16DF97F84D1@iii.ca> <26405_1482168677_58581965_26405_11893_1_8B970F90C584EA4E97D5BAAC9172DBB81C884468@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.6r5318)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/VPBCX3clw1ZfU68obsYPU-PmwCo>
Cc: DISPATCH <dispatch@ietf.org>, IETF <ietf@ietf.org>, Cullen Jennings <fluffy@iii.ca>, "draft-mohali-dispatch-cause-for-service-number.all@ietf.org" <draft-mohali-dispatch-cause-for-service-number.all@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2016 18:22:42 -0000

Hi,

Am I correct in assuming that you would intend the merged draft as PS? 
If so, there's no _functional_ difference between that and promoting 
4458 to PS. It seems to me that a key issue in this discussion is about 
whether it would be _necessary_ and _reasonable_ to promote 4458 (or the 
mechanism therein) in order to make this draft PS.

Given that this draft depends on the mechanism in RFC 4458, promoting it 
to PS and not also promoting 4458 would create a downref. While the IESG 
can approve downrefs, I'm not sure it would make sense to approve this 
particular downref unless people already think 4458 is mature enough to 
promote. (I have my doubts that they do, based on the comment from Mary 
and offline comments from others.)

Thanks,

Ben.


On 19 Dec 2016, at 11:31, marianne.mohali@orange.com wrote:

> Hi,
>
> If I can suggest an alternative: to make this document obsolete 
> RFC4458 (adding RFC4458 content) with the argument that RFC4458 was 
> informational but because it defined SIP protocol element and 
> procedures, it is obsoleted to align with IETF rules and IANA 
> registration of this parameter with no technical modification. The 
> justification is not really strong but it would correct the current 
> situation.
>
> BR,
> Marianne
>
> -----Message d'origine-----
> De : Cullen Jennings [mailto:fluffy@iii.ca]
> Envoyé : lundi 19 décembre 2016 18:11
> À : Joel Halpern
> Cc : Ben Campbell; DISPATCH; IETF; 
> draft-mohali-dispatch-cause-for-service-number.all@ietf.org
> Objet : Re: Review of 
> draft-mohali-dispatch-cause-for-service-number-12
>
>
>> On Dec 15, 2016, at 10:07 PM, Joel M. Halpern <jmh@joelhalpern.com> 
>> wrote:
>>
>> At this point I will defer to the relevant ADs.
>
> +1 on that :-)
>
>> 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 :-)
>
> So the registry takes PS to change it. And by the current SIP rules, I 
> suspect (not sure) that an update to 4458 would also have to be PS. So 
> really not sure how one gets around this not being PS.
>
>
>>
>> Yours,
>> Joel
>>
>> On 12/15/16 11:51 PM, Ben Campbell wrote:
>>>
>>>> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern <jmh@joelhalpern.com> 
>>>> 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.)
>>>
>>>
>>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, 
> deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.