ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field
draft-ietf-sipcore-reason-q850-loc-07

[Ballot discuss]
I support Adam's Discuss.

I also think that the Section 4 text:

  The use of the location parameter is restricted to Q850 cause values.
  Other values MUST be ignored if present.

needs to be clear about whether it is intended to limit to the exact 16 strings
listed above, or whether the intent is to update with Q850 if new values are
allocated.  Are string aliases allowed for the "national-use" codepoints
if allocated within a given nation?

[Ballot comment]
Section 1

  the reason of release.  The reason of release does indicate why a SIP
  Dialog or an PSTN call, in case where the call was interworked to the

nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/

Section 3

  The primary intent of the parameter defined in this specification is
  for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP but
  also open to be used by any other network that includes ISUP

nit: s/also/it is also/

Section 4

  Depending on whether the message is a request or a response the UAC
  or UAS SHALL include the location parameter when setting up the
  Reason header field with a [Q.850] cause.  This approach is only
  possible in cases when the ISUP [Q.850] location is available.

I don't understand what depends on whether the message is a request or a
response.

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3825



COMMENTS

> 
>      The SIP Reason header field is defined for carrying ISDN User Part
>      (ISUP) cause values as well as SIP response codes.  Some services in
>      SIP networks may need to know the ISUP location where the call was
>      released in the PSTN network to correctly interpret the reason of
>      release.  This document will update RFC3326.

"release" appears to be a technical PSTN term. Please provide a
citation the way that 3226 does.

[Ballot comment]
* I was trying to read up on the Q.850 spec and I found out there was a much newer version (20 years newer) that has superseded the referenced version. Is there a particular reason to refer to the 1998 spec instead of the 2018 spec?

* I have a hard time seeing why this document needs to define names for the spare codepoints (LOC-6,8,9,11). Either they won't be used (in which case we do not need to define them) or they will be defined in a future revision of Q.850 (in which case they will most likely get a different name).

[Ballot 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 ;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.

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

[Ballot 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 ;tag=1234567

Please remove the blank line between the response code 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.

[Ballot comment]
I don't know if this will ever matter, but I wasn't getting "release location" out of the title and most of the text, that just says "location". Perhaps that could be clearer?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-sipcore-reason-q850-loc-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Header Field Parameters and Parameter Values registry on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a single new registration will be made as follows:

Header Field: Reason
Parameter Name: location
Predefined Values: yes
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-02-13):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, br@brianrosen.net, Brian Rosen
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ISUP Cause Location Parameter for the SIP Reason Header Field) to Proposed Standard


The IESG has received a request from the Session Initiation Protocol Core WG
(sipcore) to consider the following document: - 'ISUP Cause Location
Parameter for the SIP Reason Header Field'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-02-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The SIP Reason header field is defined for carrying ISDN User Part
  (ISUP) cause values as well as SIP response codes.  Some services in
  SIP networks may need to know the ISUP location where the call was
  released in the PSTN network to correctly interpret the reason of
  release.  This document will update [RFC3326].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/ballot/


No IPR declarations have been submitted directly on this I-D.

Hi,

This is my AD evaluation of draft-ietf-sipcore-reason-q850-loc-04. I have some substantive and editorial comments that I would like to resolve prior to IETF last call.

Thanks!

Ben.
--------------------------

*** Substantive Comments ***

§3: “open to be used by any other network”
That would really mean “any other network that includes ISUP interworking gateways and uses Q.850 reason codes”, right?

§4:
- Figure 1: Is it possible the Q.850 location code list will ever change? if so, how will this list stay in sync? 3326 just referenced Q.850 for the reason codes; can this do the same?

- “Thus other values are not within the scope of this document.”
I’m not sure what that means. Are non-listed values forbidden? Undefined? Are they defined in _other_ documents?

- "Depending on the direction the UAC or UAS shall include the location...”
I’m not sure what that means. Does it mean “Depending on whether the message is a request or a response”?

Also, is that “shall” intended as normative?  (I suggest it not, since I assume inserting the location is optional.) Would it make sense to just say “... the UAC or UAS includes the location...”?

§6 and §7:

Unfortunately, RFC 3326 contains no privacy considerations at all, so we really can’t say that this doesn’t change them. The expectation for privacy considerations has changed since that RFC was published. I think this document does need to describe any privacy considerations that  the combination of a Q.850 reason code and location might have.

For example, can an intermediary learn anything about the end user behavior by examining them that it couldn’t learn otherwise? The answer might well be “no”, but the draft should explain the reasoning behind that.

Similarly unfortunately, the security considerations in RFC 3326 did not address ISUP interworking. Could an attacker do anything destructive or useful to the attacker by monitoring or tampering with Q.850 location information in a SIP message?

§9.1: The Header Fields Parameter sub registry also needs the “Predetermined Values” and “Reference” column filled in . I assume those values are “Yes”, and “RFCXXXX” (with XXXX replaced with the assigned RFC number), respectively.


*** Editorial Comments ***

- Header: The Updates field should just say “Updates: 3326”.

- Abstract: Please mention the update in the abstract.

§1:
- Please add a sentence of two to explain what “reason of release” means. (Should that be “reason for release”?) I know that’s in 3326--it doesn’t need detail here, but it needs enough for people to realize what you are talking about.

- 2nd sentence: The antecedent of “It” is ambiguous.

- “does specify” -> “specifies”

- The last sentence seems like a non sequitur, since this is the first mention of location. Perhaps the previous sentence could say''..., but not the Q.850 location information.

- The draft needs to elaborate on the what Q.850 represents. Otherwise, reviewers are going to assume location in the geolocation sense, and get really worried about privacy issues.

§2: Please use the new boilerplate from RFC8174, unless there is a specific reason not to.

§4:
- 2nd paragraph: s/“The mechanism employed”/“This specification “

- The second sentence has redundant Q.850 citations.

-2nd to last paragraph, "This approach is only valid in cases when the ISUP [Q.850] ocation is available.” I suspect “invalid” should be “possible” or something to that effect.

- last paragraph, “in other cases the location, if present, MUST be ignored”: I suggest “Other values MUST be ignored if present."

§5:
- First paragraph:
s/“... set up... ”/ “...sent...”
s/“... set to 1 meaning ...”/“... set to 1, meaning ..."

1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Proposed Standard.  This document updates RFC3326 and adds new parameters to a header so it is properly standards track.  Standards Track is indicated in the document header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
  The SIP Reason header field is defined for carrying ISDN User Part
  (ISUP) cause values as well as SIP response codes.  Some services in
  SIP networks may need to know the ISUP location where the call was
  released in the PSTN network to correctly interpret the reason for
  release.
Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
This document has struggled to get adequate reviews.  Chairs (which in include the shepherd) believe review is barely adequate, but the mechanism is so simple, and needed by 3GPP, that we feel advancing the document is appropriate

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
3GPP has indicated they will incorporate this document in their documents and some implementations very likely.  One of the significant sip experts has reviewed the document and provided minor comments which have been incorporated.  No special reviews have been conducted or are needed. 

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Brian Rosen is the Document Shepherd, Ben Campbell is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has reviewed the current version of the document as well as the original draft.  The document is short, the mechanism it adds is simple, and there are few concerns anyone has registered in any form about the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The shepherd would have liked to see more reviews, but considers the document to have barely adequate review, but good enough.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No special reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
The shepherd and chairs believe this document has decent consensus.  There have been NO negative voices, not even a "do we have to do this?" negative.  It is yet one more piece of ISUP that apparently needs a SIP transport to adequately handle calls originating from legacy systems. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
RFC3261 is in the reference section but is not used.  That reference could be deleted.  There are some minor typos that will need to be fixed.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
None needed

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
This document updates RFC3326.  The header correctly notes this and the update is discussed in the Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
The document adds one entry to an existing registry.  The IANA section is clear and concise.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
The document contains two lines of ABNF which have been reviewed.