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

On Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de 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.

I do not mind the extra mail, and I must apologize myself for the slowness
of the reply.

> 
> Discuss on Section 4
> Do you want to see something beyond the Note I put in?
> Note: These are the values defined  within <xref target="Q.850"/> as location. Thus other values are not within the scope of this document.

The main thing I wanted to be clarified was that the string name is the
actual codepoint used on the wire (as opposed to some encoding of the
four-bit value).  Changing to use ABNF for the specification os
isup-location-value is sufficient to clarify that point; the only remaining
potential issue would be regarding potential future changes/allocations...

> The last try to change these values in ITU-T was around 2001/2002 for some mobile network code points. This was rejected since operators said that there is willingness to change ISUP for such coding points. The values are stable since 20 years so there will be no change of these values in future, since invest will go into IP based networks like IMS. 

... and it sounds like the expected chances of any such changes are very
low.  I would still ask you to consider adding a note to the effect of
"Note that the 'LOC=*' names are the wire codepoints for the values
currently left as 'spare' or 'reserved' in [Q.850]; these will continue to
be the wire codepoints in the case of future allocation or national
usage."  I am happy to listen to some reasoning about why even that
statement is not needed, though.

(BTW, given the presence of all 16 possible 4-bit values, I don't think the
current Note about "other values are not within the scope" is adding much
value, and potentially could be replaced by my suggested note above.)

> Comments on Section 1,3 and 4
> Nits on Section 1+3 corrected.
> 
> Section 4:
> I try to reformulate the sentence.
> Proposal:
> 
>    UAC  or UAS SHALL include the location parameter in a request or response   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.

That helps a lot, thank you.

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

That would work, but it's also fine if you want to wait until the issue
Adam raised comes to a complete resolution on the list.

Thanks,

Benjamin

> Thank you and Best Regards
> 
> Roland
> > -----Ursprüngliche Nachricht-----
> > Von: sipcore <sipcore-bounces@ietf.org> Im Auftrag von Datatracker on
> > behalf of Benjamin Kaduk
> > Gesendet: Donnerstag, 7. März 2019 06:22
> > An: The IESG <iesg@ietf.org>
> > Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; sipcore-chairs@ietf.org;
> > sipcore@ietf.org
> > Betreff: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-
> > q850-loc-06: (with DISCUSS and COMMENT)
> > 
> > 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.
> > 
> > 
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> 