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

[Datatracker on behalf of Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk 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:
----------------------------------------------------------------------

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?


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