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

[<[e-mail]>]

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?

Thank you and Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Adam Roach <[e-mail]>
> Gesendet: Mittwoch, 13. März 2019 06:51
> An: Jesske, Roland <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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
> 
> On 3/11/19 3:23 AM, [e-mail] wrote:
> > 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.
> >>