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

"Ben Campbell" <ben@nostrum.com> Tue, 20 December 2016 23:49 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681261296A9; Tue, 20 Dec 2016 15:49:04 -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 0_ohmhOv4LKd; Tue, 20 Dec 2016 15:49:03 -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 4BEDC12960E; Tue, 20 Dec 2016 15:49:03 -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 uBKNn21r011135 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Dec 2016 17:49:02 -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: Robert Sparks <rjsparks@nostrum.com>
Date: Tue, 20 Dec 2016 17:49:01 -0600
Message-ID: <A515D837-3755-4522-905B-12189615A446@nostrum.com>
In-Reply-To: <df5b8104-bd88-41c2-0ad7-1333075738de@nostrum.com>
References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> <67748928-2d86-58d7-0cff-919470b67815@nostrum.com> <DDFC7716-A511-4B2D-B2F6-A39B2EF54F36@nostrum.com> <df5b8104-bd88-41c2-0ad7-1333075738de@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5318)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/tb3ZJ6K2awHy4qGzZWpHVIqeBJw>
Cc: gen-art@ietf.org, dispatch@ietf.org, ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org
Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2016 23:49:04 -0000

On 20 Dec 2016, at 17:27, Robert Sparks wrote:

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

In case it has been unclear from my other comments, this is my 
preference as an individual as well.

One thing for people to keep in mind is that, as mentioned in the quote 
above, all the registration change does is add this draft to the 
references for the entry that 4458 originally registered. Given that 
this draft updates 4458, that seems appropriate. The fact that 4458 
registered that incorrectly is a problem we might fix someday, but that 
doesn't mean _this_ draft has to fix it.


>
> One more general comment inline below:
>
> RjS
>


[...]

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

Would people find the informational status more palatable if the draft 
clarified that this is for 3GPP, and that we don't endorse it for other 
contexts?