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

"Ben Campbell" <ben@nostrum.com> Fri, 16 December 2016 04:28 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 BC892129522; Thu, 15 Dec 2016 20:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 UlQMtzjaj_UX; Thu, 15 Dec 2016 20:28:55 -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 1910C129458; Thu, 15 Dec 2016 20:28:55 -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 uBG4SrRl049861 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 15 Dec 2016 22:28:54 -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: "Joel Halpern" <jmh@joelhalpern.com>
Subject: Re: Review of draft-mohali-dispatch-cause-for-service-number-12
Date: Thu, 15 Dec 2016 22:28:53 -0600
Message-ID: <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com>
In-Reply-To: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com>
References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5310)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/mdcc0mmH9xYiszRGBPBjWoV8IlE>
Cc: gen-art@ietf.org, dispatch@ietf.org, ietf@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: Fri, 16 Dec 2016 04:28:57 -0000

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