[sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT)

Adam Roach <adam@nostrum.com> Tue, 05 March 2019 05:15 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CBC1200D7; Mon, 4 Mar 2019 21:15:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, Brian Rosen <br@brianrosen.net>, sipcore-chairs@ietf.org, br@brianrosen.net, sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.92.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com>
Date: Mon, 04 Mar 2019 21:15:28 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/4vTO3aJcBLIIRN0raqVnNma9o08>
Subject: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2019 05:15:28 -0000

Adam Roach has entered the following ballot position for
draft-ietf-sipcore-reason-q850-loc-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for taking on the task of adding this value. I have a handful of
comments, one of which really needs clarification prior to publication.

---------------------------------------------------------------------------

This issue is a discuss because the lack of formal language for values and the
lack of clarity around case sensitivity has interoperabilty implications.

§4:

>  The Augmented
>  BNF (ABNF) [RFC5234] for this parameter is shown in Figure 1.

Figure 1 is not valid ABNF. It contains ABNF, and then has a whole bunch of
other stuff. I suspect you wanted to have something more like this, using RFC
7405 extensions:

   reason-extension =/ isup-cause-location

   isup-cause-location =  "location" EQUAL isup-location-value

   isup-location-value =
      %s"U" /      ; for 0 0 0 0 user
      %s"LPN" /    ; for 0 0 0 1 private network serving the local user
      %s"LN" /     ; for 0 0 1 0 public network serving the local user
      %s"TN" /     ; for 0 0 1 1 transit network
      %s"RLN" /    ; for 0 1 0 0 public network serving the remote user
      %s"RPN" /    ; for 0 1 0 1 private network serving the remote user
      %s"LOC-6" /  ; for 0 1 1 0 spare
      %s"INTL" /   ; for 0 1 1 1 international network
      %s"LOC-8" /  ; for 1 0 0 0 spare
      %s"LOC-9" /  ; for 1 0 0 1 spare
      %s"BI" /     ; for 1 0 1 0 network beyond interworking point
      %s"LOC-11" / ; for 1 0 1 1 spare
      %s"LOC-12" / ; for 1 1 0 0 reserved for national use
      %s"LOC-13" / ; for 1 1 0 1 reserved for national use
      %s"LOC-14" / ; for 1 1 1 0 reserved for national use
      %s"LOC-15"   ; for 1 1 1 1 reserved for national use

If you choose to instead keep the current formulation, please:

 - Move the list of valid values out of the figure, and
 - Add text clarifying whether the values are case-sensitive.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

ID Nits reports:

  == Unused Reference: 'RFC3261' is defined on line 245, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3323' is defined on line 251, but no explicit
     reference was found in the text

---------------------------------------------------------------------------

§1:

>  [RFC3326] specifies that a ISUP [Q.850]
>  cause code can be carried within a SIP response

This isn't quite right -- interpreted carefully, RFC 3326 specifically does
*not* allow this: it envisions specific future response codes (in theory used
to help with HERFP) that opt-in to allowing the Reason header field.  When
speaking of the general use case of sending Q.850 codes in arbitrary SIP
response messages, you need to cite RFC 6432 instead of RFC 3326.

---------------------------------------------------------------------------

§4:

>  As defined by [RFC3326] a Reason header field MAY appear in any
>  request in a dialog, in any CANCEL request and in any response whose
>  status code explicitly allows the presence of this header field.

As above, I think we're talking about the more general case (rather than the
"explicitly allows" case); if so, this text should cite RFC 6432 and
clarify that "Any SIP Response message, with the exception of a 100 (Trying),
MAY contain a Reason header field with a Q.850 [Q.850] cause code."

---------------------------------------------------------------------------

§5:

>        SIP/2.0 404 Not Found
>
>        From: Alice <sips:alice@atlanta.example.com>;tag=1234567

Please remove the blank line between the response line and the first header
field.

Please add at least one "Via" header field, or add text indicating that Via
header fields have been removed for concision.