Subject: Re: [urn] Expert review needed

From: R Atarius <[email-masked]>
Date: Thu, 5 Apr 2018 23:38:27 +0000 (UTC)

Hi Dale,
Thanks for reviewing this and please see my inline comments.
thanks againRoozbeh

      From: Dale R. Worley <[email-masked]>
 To: R Atarius <[email-masked]> 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
 Sent: Tuesday, March 27, 2018 7:50 PM
 Subject: Re: [urn] Expert review needed
   
R Atarius <[email-masked]> writes:
> The new revision (16) is now available.
> https://www.ietf.org/id/draft-atarius-dispatch-meid-urn-16.txt

The new version looks quite good.  I've a few comments, listed in text
order:

Abstract

  This document defines a Uniform Resource Name (URN) namespace for the
  Third Generation Partnership Project (3GPP2) and a Namespace Specific
  String (NSS) for the Mobile Equipment Identity (MEID).

I may have the terminology wrong, but comparing to the next sentence,
you might want to change "Third Generation Partnership Project (3GPP2)"
to "Third Generation Partnership Project 2 (3GPP2)".
[Roozbeh] OK and thanks!
****************************************************************************************
3.  Namespace Registration Template

  Registration organization:

  Name: 3GPP2

You might want to spell this out as "Third Generation Partnership
Project 2 (3GPP2)".
[Roozbeh]: OK!

****************************************************************************************

  future-pp2-specifier = future-specifier *( ":" 1*( pchar / "/" ))

This ABNF is correct, but somewhat obscure.  Looking at it quickly, it
appears to specify a sequence of "words" separated by ":", where each
word contains at least one character which is not ":".  But in fact,
<pchar> can be ":", so this has the same effect as

  future-pp2-specifier = future-specifier [ ":" 1*( pchar / "/" ) ]

That is, the <future-specifier> (which cannot contain ":") can be followed
by ":" and then by one or more (pchar / "/"), with the latter containing
":" in arbitrary places.

So if the ABNF specifies what you want, you might consider the latter
formulation as being more expressive of your intentions.
[Roozbeh] OK, I can write this as the one you suggested which is
 future-pp2-specifier = future-specifier [ ":" 1*( pchar / "/" ) ]

****************************************************************************************

  <future-pp2-specifier> can comprise any ASCII characters compliant
  with URN syntax in [RFC8141].

Actually, there are sequences of ASCII characters compliant with URN
syntax in [RFC8141] which cannot be <future-pp2-specifier> -- RFC 8141
prescribes that the NSS is "pchar *(pchar / "/")", but
<future-pp2-specifier> can only start with <pp2-char>, which does not
include "~", <sub-delims>, ":", or "@", which are all included in
<pchar>.

You might want to omit this sentence.  Alternatively, it is true that
the part of <future-pp2-specifier> after ":" can be any NSS string.
Though that part is slightly more general than NSS, since it can start
with "/", and NSS cannot.  But it's not clear to me that anything you
can say along these lines is both completely accurate and easier to
understand than the ABNF.

[Roozbeh] I choose to omit the sentence then.
****************************************************************************************
  Rules for Lexical Equivalence:

  Two 3GPP2 MEID URNs are equivalent if they have the same 'meidval' in
  the same sequential order.  Two future 3GPP2 MEID URNs are equivalent
  if they have the same 'meidval'and 'future-pp2-specifier' in the same
  sequential order.

The second sentence needs to be rewritten, because of course, no URN
contains both <meidval> and <future-pp2-specifier>.  Indeed, it seems
like you can get the effect you want by simply saying:

  Two 3GPP2 MEID URNs are equivalent if they have the same character
  string as <pp2-NSS>.

4.2.3.  Check Digit

  This is a single hexadecimal digit (bits 1-4 of octet 8) and is used
  as assurance of integrity in error-prone operations, e.g. when used
  with certain types of readers during inventory management operations.
  The check digit is not transmitted by the mobile equipment and are
  not used in the MEID URN.

In section 4.2, for completeness, you give a lot of information that is
not strictly required.  However you don't give the really non-trivial
bit of information:  the formula for the check digit.  After reading
this section, I was left curious what the check digit formula actually
is!

Dale

---

From: R Atarius <[email-masked]>
Date: Thu, 5 Apr 2018 23:42:16 +0000 (UTC)

<< PLEASE IGNORE THE PREVIOUS MAIL WHICH WAS INCOMPLETE!>>>

Hi Dale,

Abstract

  Name: 3GPP2

[Roozbeh] : OK!

4.2.3.  Check Digit

In section 4.2, for completeness, you give a lot of information that is
not strictly required.  However you don't give the really non-trivial
bit of information:  the formula for the check digit.  After reading
this section, I was left curious what the check digit formula actuallyis!
[Roozbeh]: OK but can I leave it as it is?

Dale

---

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 11 Apr 2018 12:28:48 +0000

Hi Rozbeh,

Just a minor comment from me (but I'll read the complete draft when the new version is published):

On Friday, April 06, 2018 1:42 AM, R Atarius [mailto:[email-masked]] wrote:

[...]

> [Roozbeh]: OK but can I leave it as it is?

I think that technically you could, but I also agree with Dale that it might be confusing to supply non-required information. Since the check digit is not used in the MEID URN, it might be better to omit this paragraph or to rephrase it as

"This is a single hexadecimal digit (bits 1-4 of octet 8). The check digit is not transmitted by the mobile equipment and is not used in the MEID URN."

Looking more closely at section 4.2, it feels a bit awkward that you first define the parts of the MEID format and then go on to put them together. You might want to consider rephrasing as follows:

4.2 MEID Format
The MEID format is 15 hexadecimal digits encoded in 8 octets as defined in [S.R0048-A]. The first eight hexadecimal digits constitute the manufacturer code, the next six hexadecimal digits the serial number within the manufacturer code. The last hexadecimal digit is a check digit. For more details on the hexadecimal encoding cf. 4.2.4.

4.2.4 Hexadecimal Encoding
The following figure ... [X.S0008-A].

Best,

Lars

---

From: R Atarius <[email-masked]>
Date: Wed, 11 Apr 2018 21:09:40 +0000 (UTC)

Hi Lars
please see below
thanksRoozbeh

      From: "Svensson, Lars" <[email-masked]>
 To: R Atarius <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "Dale R. Worley ([email-masked])" <[email-masked]>
 Sent: Wednesday, April 11, 2018 5:28 AM
 Subject: RE: << PLEASE IGNORE THE PREV. MAIL>> [urn] Expert review needed
   
Hi Rozbeh,

[...]

"This is a single hexadecimal digit (bits 1-4 of octet 8). The check digit is not transmitted by the mobile equipment and is not used in the MEID URN."
[Roozbeh] I believe that's how I started but I received comments about its functionality and that's why I added that sentence. I am good either way. If that makes you, Dale and IETF community satisfied then I can remove that sentence. Please let me know.
**********************************************************************************************************************

4.2 MEID Format

[Roozbeh] I think that is what is called a "hanging section", since there should not be any text below 4.2 when there are 4.2.1, 4.2.2, etc. I can create a new subsection as "4.2.1 Overview"  with the text you proposed and shift other subsection with 0.0.1. Will that help?

Best,

Lars

---

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 12 Apr 2018 18:43:47 +0000

Hi Roozbeh,

On Wednesday, April 11, 2018 11:10 PM, R Atarius [mailto:[email-masked]] wrote:
[...]
> 
> On Friday, April 06, 2018 1:42 AM, R Atarius [mailto:mailto:[email-masked]]
> wrote:
> 
> 
> [...]
> 
> > 4.2.3.  Check Digit
> >
> I think that technically you could, but I also agree with Dale that it might be confusing
> to supply non-required information. Since the check digit is not used in the MEID URN,
> it might be better to omit this paragraph or to rephrase it as
> 
> "This is a single hexadecimal digit (bits 1-4 of octet 8). The check digit is not
> transmitted by the mobile equipment and is not used in the MEID URN."
> 
> [Roozbeh] I believe that's how I started but I received comments about its functionality
> and that's why I added that sentence. I am good either way. If that makes you, Dale
> and IETF community satisfied then I can remove that sentence. Please let me know.

OK, so you're damned if you do and damned if you don't... I'm fine either way, too, so if not Dale or anyone else objects, you can leave the sentence as it is.

> 
> *************************************************************************
> *********************************************
> 
> Looking more closely at section 4.2, it feels a bit awkward that you first define the
> parts of the MEID format and then go on to put them together. You might want to
> consider rephrasing as follows:
> 
> 4.2 MEID Format
> The MEID format is 15 hexadecimal digits encoded in 8 octets as defined in [S.R0048-
> A]. The first eight hexadecimal digits constitute the manufacturer code, the next six
> hexadecimal digits the serial number within the manufacturer code. The last
> hexadecimal digit is a check digit. For more details on the hexadecimal encoding cf.
> 4.2.4.
> [Roozbeh] I think that is what is called a "hanging section", since there should not be
> any text below 4.2 when there are 4.2.1, 4.2.2, etc. I can create a new subsection as
> "4.2.1 Overview"  with the text you proposed and shift other subsection with 0.0.1. Will
> that help?

That's more a question of style than a technical question... I don't know what the IETF Style Guide (TM) has to say on the topic but there are quite a few RFCs that have text at the beginning of a section and then continue in subsections. RFC 8141 is one example, where section 1 [1] has a fairly long text and then continues to specify things in 1.1, 1.2 etc.

I'm fine either way.

[1] https://tools.ietf.org/html/rfc8141#section-1

Best,

Lars

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Apr 2018 13:50:11 -0500

HI Roozbeh and others,

When deciding what to fix, please remember we are late in the process for non-critical fixes. When in doubt, please lean towards leaving things is”.

Thanks!

Ben.

> On Apr 11, 2018, at 4:09 PM, R Atarius <[email-masked]> wrote:
> 
> Hi Lars
> 
> please see below
> 
> thanks
> Roozbeh
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Apr 2018 14:28:04 -0500

Oops, I meant to say “as is”.

Ben.

> On Apr 12, 2018, at 1:50 PM, Ben Campbell <[email-masked]> wrote:
> 
> HI Roozbeh and others,
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: R Atarius <[email-masked]>
Date: Thu, 12 Apr 2018 21:58:21 +0000 (UTC)

HiPlease see below
ThanksRoozbeh
[...]     > I think that technically you could, but I also agree with Dale that it might be confusing

[Roozbeh] I leave then as it is.

I'm fine either way.

[1] https://tools.ietf.org/html/rfc8141#section-1
[Roozbeh] I created an overview section and added your comment.

Best,

Lars

---

From: R Atarius <[email-masked]>
Date: Thu, 12 Apr 2018 22:00:37 +0000 (UTC)

thanks,
I added Lars's comments and if there is no more comments and everyone is satisfied, I can create a new document. 

      From: Ben Campbell <[email-masked]>
 To: R Atarius <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "Dale R. Worley ([email-masked])" <[email-masked]>; "Svensson, Lars" <[email-masked]>; "[email-masked]" <[email-masked]>
 Sent: Thursday, April 12, 2018 12:28 PM
 Subject: Re: [urn] << PLEASE IGNORE THE PREV. MAIL>> Expert review needed

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 Apr 2018 16:02:36 -0600

Please do. :-)

On 4/12/18 4:00 PM, R Atarius wrote:
> ------------------------------------------------------------------------
> *From:* Ben Campbell <[email-masked]>
> *To:* R Atarius <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>;
> "[email-masked]" <[email-masked]>; "Dale R. Worley ([email-masked])"
> <[email-masked]>; "Svensson, Lars" <[email-masked]>;
> "[email-masked]" <[email-masked]>
> *Sent:* Thursday, April 12, 2018 12:28 PM
> *Subject:* Re: [urn] << PLEASE IGNORE THE PREV. MAIL>> Expert review needed
> 
>> On Apr 12, 2018, at 1:50 PM, Ben Campbell <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
>> HI Roozbeh and others,
>>
>> When deciding what to fix, please remember we are late in the process
> for non-critical fixes. When in doubt, please lean towards leaving
> things is”.
>>
>> Thanks!
>>
>> Ben.
>>
>>> On Apr 11, 2018, at 4:09 PM, R Atarius <[email-masked]
> <mailto:[email-masked]>> wrote:
>>>
>>> Hi Lars
>>>
>>> please see below
>>>
>>> thanks
>>> Roozbeh
>>>
>>>
>>> From: "Svensson, Lars" <[email-masked] <mailto:[email-masked]>>
>>> To: R Atarius <[email-masked] <mailto:[email-masked]>>
>>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>; "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>; "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>;
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>; "Dale R.
> Worley ([email-masked] <mailto:[email-masked]>)"
> <[email-masked] <mailto:[email-masked]>>
>>> On Friday, April 06, 2018 1:42 AM, R Atarius
> [mailto:[email-masked] <mailto:[email-masked]>] wrote:
>>>
>>>
>>> [...]
>>>
>>>> 4.2.3.  Check Digit
>>>>
>>> I think that technically you could, but I also agree with Dale that
> it might be confusing to supply non-required information. Since the
> check digit is not used in the MEID URN, it might be better to omit this
> paragraph or to rephrase it as
>>>
>>> "This is a single hexadecimal digit (bits 1-4 of octet 8). The check
> digit is not transmitted by the mobile equipment and is not used in the
> MEID URN."
>>>
>>> [Roozbeh] I believe that's how I started but I received comments
> about its functionality and that's why I added that sentence. I am good
> either way. If that makes you, Dale and IETF community satisfied then I
> can remove that sentence. Please let me know.
>>>
>>>
>>> Looking more closely at section 4.2, it feels a bit awkward that you
> first define the parts of the MEID format and then go on to put them
> together. You might want to consider rephrasing as follows:
>>>
>>> 4.2 MEID Format
>>> The MEID format is 15 hexadecimal digits encoded in 8 octets as
> defined in [S.R0048-A]. The first eight hexadecimal digits constitute
> the manufacturer code, the next six hexadecimal digits the serial number
> within the manufacturer code. The last hexadecimal digit is a check
> digit. For more details on the hexadecimal encoding cf. 4.2.4.
>>>
>>> 4.2..4 Hexadecimal Encoding
>>> [Roozbeh] I think that is what is called a "hanging section", since
> there should not be any text below 4.2 when there are 4.2.1, 4.2.2, etc.
> I can create a new subsection as "4.2.1 Overview"  with the text you
> proposed and shift other subsection with 0.0.1. Will that help?
>>>
>>>
>>> Best,
>>>
>>> Lars
>>
>> [email-masked] <mailto:[email-masked]>
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Apr 2018 17:23:16 -0500

Please submit a new version at your earliest convenience.

Thanks!

Ben.

> On Apr 12, 2018, at 5:00 PM, R Atarius <[email-masked]> wrote:
> 
> thanks,
>

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 13 Apr 2018 13:35:17 +0000

On Thursday, April 12, 2018 11:58 PM, R Atarius [mailto:[email-masked]] wrote:

[...]
> OK, so you're damned if you do and damned if you don't... I'm fine either way, too, so
> if not Dale or anyone else objects, you can leave the sentence as it is.
> 

OK.

> That's more a question of style than a technical question... I don't know what the IETF
> Style Guide (TM) has to say on the topic but there are quite a few RFCs that have text
> at the beginning of a section and then continue in subsections. RFC 8141 is one
> example, where section 1 [1] has a fairly long text and then continues to specify things
> in 1.1, 1.2 etc.
> 
> I'm fine either way.
> 

OK. 

Thanks,

Lars