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

From: Adam Roach <[email-masked]>
Date: Mon, 04 Mar 2019 21:15:28 -0800

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:[email-masked]>;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.

---

From: <[email-masked]>
Date: Mon, 11 Mar 2019 08:23:42 +0000

Hi,
Thank you for your comments. I went through the comments and here are my answers and proposals to the comments made.
Sorry If some of you get the mail twice, since I answered in another way already.

1.  Discuss:
§4 ABNF
Have incorporated the proposal.

1.  Comments:
I have incorporated all proposed changes. 
§1 done:
Text reads now:
RFC6432 specifies that a ISUP Q.850 cause code can be carried within a SIP response, but not the Q.850 location information.

§4
So text reads now:
As defined by RFC6432 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
Done as proposed. 
Removed blank line and added two via header.

If you are OK with these changes I will produce a new draft and upload it.

Thank you and Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Adam Roach <[email-masked]>
> Gesendet: Dienstag, 5. März 2019 06:15
> An: The IESG <[email-masked]>
> Cc: [email-masked]; Brian Rosen
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Betreff: Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06:
> (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> >  [RFC3326] specifies that a ISUP [Q.850]  cause code can be carried
> > within a SIP response
> 
> "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."
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Mar 2019 00:51:11 -0500

Thanks. These resolutions look good to me; please upload a new version 
at your convenience.

/a

---

From: <[email-masked]>
Date: Thu, 14 Mar 2019 07:24:41 +0000

Thank you Adam for your Answer.
I will upload the draft as soon as the upload page opens again. i.e. 23.03.
Or is there any possibility to do it now?

Roland

> Gesendet: Mittwoch, 13. März 2019 06:51
> An: Jesske, Roland <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Betreff: Re: AW: Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-
> loc-06: (with DISCUSS and COMMENT)
> 
> Thanks. These resolutions look good to me; please upload a new version at
> your convenience.
> 
> /a
> 
> > Thank you for your comments. I went through the comments and here are
> my answers and proposals to the comments made.
> > RFC6432 specifies that a ISUP Q.850 cause code can be carried within a SIP
> response, but not the Q.850 location information.
> >
> > §4
> > So text reads now:
> > As defined by RFC6432 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
> > Done as proposed.
> >> 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
> >> 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
> >> 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:
> >>
> >> *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.
> >>
> >> 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."
> >>
> >> 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.
> >>

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Mar 2019 10:34:41 -0500

> Or is there any possibility to do it now?

Sure. Ordinarily, you'd ask the responsible AD to approve a manual 
posting; but, since Ben is on PTO at the moment, I'm happy to give 
approval. Send an email to [email-masked] with the draft 
attached, requesting manual posting. Be sure to copy [email-masked] on 
that email, and I'll send an approval message.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Mar 2019 13:23:28 -0500

> Have incorporated the proposal.

I'm going to clear my discuss, but we'll need at least one more version 
(or an RFC Editor's note) that mentions RFC 7405; for example:

OLD:

    The Augmented

NEW:

    The Augmented BNF (ABNF) [RFC5234], with case-sensitive
    extensions [RFC7405], for this parameter is shown in Figure 1.

If you want to submit a new draft with this change, I'll approve it for 
posting.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Mar 2019 13:28:39 -0500

On 3/15/19 1:23 PM, Adam Roach wrote:
> I'm going to clear my discuss
>

Based on Paul Kyzivat's comment on the SIPCORE mailing list, I'm going 
to hold off and talk to Ben before I clear. Sorry for the confusion.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Mar 2019 13:43:17 -0500

On 3/15/19 1:28 PM, Adam Roach wrote:
>>> Thank you for your comments. I went through the comments and here 
>>> are my answers and proposals to the comments made.

Based on Paul's comment and on Ben's reminder that SIP fields are 
generally case-insensitive (both on the SIPCORE mailing list), I think 
the solution here is to simply remove all of the instances of "%s" in 
the BNF I sent. Sorry for the extra round-trip here.

/a

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Mar 2019 21:20:55 -0500

> On Mar 19, 2019, at 1:43 PM, Adam Roach <[email-masked]> wrote:
> 
>> Based on Paul Kyzivat's comment on the SIPCORE mailing list, I'm going to hold off and talk to Ben before I clear. Sorry for the confusion.
>> 
> 
> Based on Paul's comment and on Ben's reminder that SIP fields are generally case-insensitive (both on the SIPCORE mailing list), I think the solution here is to simply remove all of the instances of "%s" in the BNF I sent. Sorry for the extra round-trip here.
> 

Like the following? If so, I can drop this into an RFC Editor note:

OLD:

   isup-location-value =

                       Figure 1: isup-cause-location
NEW:
reason-extension =/ isup-cause-location
isup-cause-location =  "location" EQUAL isup-location-value

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

                       Figure 1: isup-cause-location

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Mar 2019 21:26:27 -0500

> On Mar 19, 2019, at 9:20 PM, Ben Campbell <[email-masked]> wrote:
> 
> 
> 
>> On Mar 19, 2019, at 1:43 PM, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> On 3/11/19 3:23 AM, [email-masked] <mailto:[email-masked]> wrote:
>>>>> Hi,

Or do we also need to remove the double-quotes?

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Mar 2019 22:05:46 -0500

The double-quotes are fine. Your RFC editor note addresses my issue 
completely. Clearing my discuss now.

/a

On 3/19/19 9:26 PM, Ben Campbell wrote:
>
>
>> On Mar 19, 2019, at 9:20 PM, Ben Campbell <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>>>> On 3/11/19 3:23 AM,[email-masked] 
>>>>> <mailto:[email-masked]>wrote:
>>>>>> Hi,
>>>> Based on Paul Kyzivat's comment on the SIPCORE mailing list, I'm 
>>>> going to hold off and talk to Ben before I clear. Sorry for the 
>>>> confusion.
>>>>
>>>
>>> generally case-insensitive (both on the SIPCORE mailing list), I 
>>> think the solution here is to simply remove all of the instances of 
>>> "%s" in the BNF I sent. Sorry for the extra round-trip here.
>>>
>>