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

From: Datatracker on behalf of Benjamin Kaduk <[email-masked]>
Date: Wed, 06 Mar 2019 21:21:30 -0800

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.

---

From: <[email-masked]>
Date: Mon, 11 Mar 2019 08:20:34 +0000

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.

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

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.

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: sipcore <[email-masked]> Im Auftrag von Datatracker on
> behalf of Benjamin Kaduk
> Gesendet: Donnerstag, 7. März 2019 06:22
> An: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Betreff: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-
> q850-loc-06: (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> allocated.  Are string aliases allowed for the "national-use" codepoints if
> allocated within a given nation?
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 18 Mar 2019 09:03:58 -0500

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

> 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 codin…

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

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

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Mar 2019 21:30:34 -0500

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 <[email-masked]> wrote:
> 
> .... and it sounds like the expected chances of any such changes are very

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Mar 2019 22:20:31 -0500

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 <[email-masked]> wrote:
> 
> Hi Roland,
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Mar 2019 19:23:24 -0500

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?

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
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 <[email-masked]> wrote:
> 
> Signed PGP part
> Hi Roland.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Mar 2019 19:43:57 -0500

> Benjamin and Roland, does this work for you?

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

-Benjamin

> Ben.

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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Mar 2019 19:47:26 -0500

> On Mar 20, 2019, at 7:43 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

will fix in the actual note.

> document" is saying anything helpful, but that's not a blocking comment.

On reflection, I agree with you. I think it wants to say “other values are not possible” or something to that effect, but it’s not necessary either way.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Mar 2019 19:55:20 -0500

The RFC editor note for Benjamin’s and Adam’s points is in place at https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/writeup/

You may need to scroll down.

Thanks!

Ben.

> On Mar 20, 2019, at 7:47 PM, Ben Campbell <[email-masked]> wrote:
> 
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Mar 2019 21:02:14 -0500

> You may need to scroll down.

Thanks; I've changed my position to No Objection in the datatracker.

-Benjamin

---

From: Keith Drage <[email-masked]>
Date: Thu, 21 Mar 2019 22:45:24 +0000

I know this is part of the existing text, but Q.850 values (and 
locations) are not just used in ISUP, but also form part of DSS1 and 
indeed, also QSIG. Therefore I would regard the formulation of "ISUP 
[Q.850] location" as a little but confusing. For example does it means 
only those generated by an entity supporting ISUP, or only those coming 
from an entity supporting ISUP but relayed from other entities, or what.

Keith