From: Ben Campbell <ben@nostrum.com>
Message-Id: <0446BC26-28C3-42B7-8DD6-F8D054883DAF@nostrum.com>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_5890187D-E9A0-448F-959C-A776BB3A2E8B";
 protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 19 Mar 2019 21:30:34 -0500
In-Reply-To: <20190318140358.GB80498@kduck.mit.edu>
Cc: =?utf-8?Q?Michael_T=C3=BCxen_via_Datatracker?= <noreply@ietf.org>,
 draft-ietf-sipcore-reason-q850-loc@ietf.org,
 SIPCORE <sipcore@ietf.org>, IESG <iesg@ietf.org>,
 sipcore-chairs@ietf.org, Benjamin Kaduk <kaduk@mit.edu>
To: "<R.Jesske@telekom.de>" <R.Jesske@telekom.de>
References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com>
 <FRXPR01MB01350BEB15B22E9E5FFB936AF9480@FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE>
 <20190318140358.GB80498@kduck.mit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/aOX9wn8Pyb_MzpJG3p-Jfa4wt2A>
Subject: Re: [sipcore] Benjamin Kaduk's Discuss on
 draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT)
Precedence: list


--Apple-Mail=_5890187D-E9A0-448F-959C-A776BB3A2E8B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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 <kaduk@mit.edu> wrote:
>=20
> 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.
>=20
> I do not mind the extra mail, and I must apologize myself for the =
slowness
> of the reply.
>=20
>>=20
>> 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=3D"Q.850"/> =
as location. Thus other values are not within the scope of this =
document.
>=20
> 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...
>=20
>> 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.
>=20
> .... 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=3D*' 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.
>=20
> (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.)
>=20
>> Comments on Section 1,3 and 4
>> Nits on Section 1+3 corrected.
>>=20
>> Section 4:
>> I try to reformulate the sentence.
>> Proposal:
>>=20
>>   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.
>=20
> That helps a lot, thank you.
>=20
>> If you are OK with these changes I will produce a new draft and =
upload it.
>=20
> 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.
>=20
> Thanks,
>=20
> Benjamin
>=20
>> Thank you and Best Regards
>>=20
>> Roland
>>> -----Urspr=C3=BCngliche Nachricht-----
>>> Von: sipcore <sipcore-bounces@ietf.org> Im Auftrag von Datatracker =
on
>>> behalf of Benjamin Kaduk
>>> Gesendet: Donnerstag, 7. M=C3=A4rz 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)
>>>=20
>>> Benjamin Kaduk has entered the following ballot position for
>>> draft-ietf-sipcore-reason-q850-loc-06: Discuss
>>>=20
>>> 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.)
>>>=20
>>>=20
>>> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>=20
>>>=20
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/
>>>=20
>>>=20
>>>=20
>>> =
----------------------------------------------------------------------
>>> DISCUSS:
>>> =
----------------------------------------------------------------------
>>>=20
>>> I support Adam's Discuss.
>>>=20
>>> I also think that the Section 4 text:
>>>=20
>>>   The use of the location parameter is restricted to Q850 cause =
values.
>>>   Other values MUST be ignored if present.
>>>=20
>>> 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?
>>>=20
>>>=20
>>> =
----------------------------------------------------------------------
>>> COMMENT:
>>> =
----------------------------------------------------------------------
>>>=20
>>> Section 1
>>>=20
>>>   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
>>>=20
>>> nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/
>>>=20
>>> Section 3
>>>=20
>>>   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
>>>=20
>>> nit: s/also/it is also/
>>>=20
>>> Section 4
>>>=20
>>>   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.
>>>=20
>>> I don't understand what depends on whether the message is a request =
or a
>>> response.
>>>=20
>>>=20
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>=20
>=20


--Apple-Mail=_5890187D-E9A0-448F-959C-A776BB3A2E8B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyRpcoACgkQgFZKbJXz
1A2Jmw//az96D64JoxO31D1JAdCEMxqQLqXIdT5tXe2h8XA40P3gbz0BHpT3N6ee
QBczr9hv4y9TWJmwe2h8JitUhvzUvMJszE0PjTKyJwBLKvoUCLOmkUX3s3fNQtxb
Vbi4JUvoVD7DpiQYec8HpuJvNhXodkrCkkbRiiXyTO9oozoR6KfC9inFqAnJBOYw
pZTi5QR8bycBUr14PIK6RJ+oOSzrWzYBW5uxHTdXiErWVhbL4qsji/Mxw7sAYPRR
t65Fo0VCj0dvKpbzJIrYjxK+fVeY0X2DLYcRE/0YGsPCKGyk8ZZuB/Ja4b0sLeuc
axjxJ1W5ez+g9E3cVOeWfDGeBRSfRDYY5ALt5zE00/SuNDyQf/0LirVQpHUzIxFt
QGJkg5+8aS5/4g/noKRcRvb0BHNorXgmslzofBdqP1fb9dXy6ltJlFeGe5yvFE9h
rnz+hsLNsbzoLZuU3wGqetth5xUFUA6OR9LF+1kdHJvEC0XT99gQh3hVZMWN1AD3
viTnJWXcKHIUTI6XUtuUU/NFXmSEOYtUzPfFoaafmZYCNjymsZK2adNjpdWy2qLv
GXNgZ/VppMwK5LThxbjeL1WO9dkGa18iZe3blHRNStWo1oqKQ+9YHG4KvTXMfc0T
TYfaW3WBL7P4CWcORl6b4frWwN/+5Hq/wPu1IYfYUZWSOtKTJHk=
=qloe
-----END PGP SIGNATURE-----

--Apple-Mail=_5890187D-E9A0-448F-959C-A776BB3A2E8B--