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

[Adam Roach <[e-mail]>]

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