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

[Benjamin Kaduk <[e-mail]>]

On Wed, Mar 20, 2019 at 07:23:24PM -0500, Ben Campbell wrote:
> Here’s a proposed RFC Editor note to make the changes in section 4. I made some slight edits for clarity, and a bigger edit to include the part about the ISUP location being available as a condition of the SHALL, rather than a separate statement suggesting that the SHALL is not always possible to follow.
> 
> Benjamin and Roland, does this work for you?

Modulo typos (inline), I can clear my Discuss for that text.

-Benjamin

> Thanks!
> 
> Ben.
> 
> ---------------------------------
> 
> Please make the following edits to the first two paragraphs following Figure 1 in
> Section 4:
> 
> OLD:
> Note: These are the values defined within [Q.850] as location.  Thus
> other values are not within the scope of this document.
> 
> 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.
> 
> NEW:
> Note: These are the values defined within [Q.850] as location.  Thus
> other values are not within the scope of this document. the 'LOC=*' names

I feel like this was probably my typo originally, but capital "The" and a
hyphen in "LOC-*" (not equals).

I still am not clear that "other values are not within the scope of this
document" is saying anything helpful, but that's not a blocking comment.

> 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 of the such values.
> 
> The 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 when the
> ISUP [Q.850] location is available.
> 
> 
> > On Mar 19, 2019, at 10:20 PM, Ben Campbell <[e-mail]> wrote:
> > 
> > Signed PGP part
> > Hi Roland.
> > 
> > Benjamin tells me the remaining changes are small. Let me see if I can put them in the form of an RFC Editor note, so we can hopefully avoid a new revision.
> > 
> > Thanks!
> > 
> > Ben.
> > 
> >> On Mar 19, 2019, at 9:30 PM, Ben Campbell <[e-mail]> wrote:
> >> 
> >> Hi Roland,
> >> 
> >> Am I correct to understand that changes based on this discussion have not yet made it into a draft? If so, when do you think that could happen?
> >> 
> >> Please note that the Plenary in Prague is sort of a deadline for this; if I am not able approve it before then it will have to transition to another AD, which could add delays while they come up to speed on it.
> >> 
> >> Thanks!
> >> 
> >> Ben.
> >> 
> >>> On Mar 18, 2019, at 9:03 AM, Benjamin Kaduk <[e-mail]> wrote:
> >>> 
> >>> On Mon, Mar 11, 2019 at 08:20:34AM +0000, [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.
> >>> 
> >>> 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 <[e-mail]> Im Auftrag von Datatracker on
> >>>>> behalf of Benjamin Kaduk
> >>>>> Gesendet: Donnerstag, 7. März 2019 06:22
> >>>>> An: The IESG <[e-mail]>
> >>>>> Cc: [e-mail]; [e-mail];
> >>>>> [e-mail]
> >>>>> 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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>> 
> >>> 
> >> 
> > 
> > 
> > 
>