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

[<[e-mail]>]

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 <[e-mail]>
> Gesendet: Dienstag, 5. März 2019 06:15
> An: The IESG <[e-mail]>
> Cc: [e-mail]; Brian Rosen
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Betreff: Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06:
> (with DISCUSS and COMMENT)
> 
> 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:[e-mail]>;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.
>