Subject: [urn] Expert review needed

From: R Atarius <[email-masked]>
Date: Sun, 14 Jan 2018 03:43:49 +0000 (UTC)

Hello all,
The following drafts have been approved, however, an expert review for the new URN is needed. Could you please review the following drafts and comment?

https://www.ietf.org/id/draft-atarius-dispatch-meid-urn-15.txt

https://www.ietf.org/id/draft-atarius-dispatch-meid-urn-as-instanceid-07.txt
ThanksRoozbeh Atarius

---

From: Ben Campbell <[email-masked]>
Date: Sun, 14 Jan 2018 00:37:02 -0600

To clarify: Only draft-atarius-dispatch-meid-urn registers a namespace. IIUC, that’s the only one that needs a URN namespace registration expert review. The IESG approval of that draft is pending the expert review.

Thanks!

Ben (as sponsoring AD).

> On Jan 13, 2018, at 9:43 PM, R Atarius <[email-masked]> wrote:
> 
> Hello all,
> 
> Thanks
> Roozbeh Atarius

---

From: "Svensson, Lars" <[email-masked]>
Date: Tue, 16 Jan 2018 12:37:05 +0000

Dear Roozbeh,

On Sunday, January 14, 2018 4:44 AM, urn [mailto:[email-masked]] On Behalf Of R Atarius wrote:

> The following drafts have been approved, however, an expert review for the new URN
> is needed. Could you please review the following drafts and comment?
> 
> 

I have had a look at https://www.ietf.org/id/draft-atarius-dispatch-meid-urn-15.txt and I don't think the document is quite ready for publication yet.

* The references section has a normative reference to draft-atarius-dispatch-meid-urn-as-instance-id. I don't think it appropriate to have a normative reference to a draft document.

* The URLs for the references [S.R0048-A], [SC.R4002-0] and [X.S0008-0] do not resolve. Also, in the URL for [SC.R4002-0] the protocol should be added: <http://www.3gpp2.org/...>

* §3, sec "rules for lexical equivalence" say that MEID URNs are equal if they have the same meidval and the same parameter values but the syntax doesn't define parameter values for meidval. Also, the rules say that the NSS can be compared "using the normal mechanisms for percent-encoded UTF-8 strings", but the syntax doesn't allow any characters outside ASCII. To me, those two parts seem unnecessary and perhaps you can simply delete them

* §4.2.1 Manufacturer Code. It would be interesting to know if there is a publicly available registry of manufacturer codes. The answer might be in [S.R0048-A] but since the URL in the reference doesn't resolve, I could not check that.

Best,

Lars

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Jan 2018 10:08:09 -0600

> On Jan 16, 2018, at 6:37 AM, Svensson, Lars <[email-masked]> wrote:
> 
> Dear Roozbeh,
> 

I’ll let Roozbeh respond to theo other comments, but the document you mention is being published in tandem with this one. The reference will be to an RFC in the final published version.

Thanks!

Ben.

> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: R Atarius <[email-masked]>
Date: Tue, 16 Jan 2018 22:33:25 +0000 (UTC)

Hello Lars,
Please see the responses inline:
ThanksRoozbeh

      From: Ben Campbell <[email-masked]>
 To: "Svensson, Lars" <[email-masked]> 
Cc: R Atarius <[email-masked]>; "[email-masked]" <[email-masked]>
 Sent: Tuesday, January 16, 2018 8:08 AM
 Subject: Re: [urn] [Marketing Mail] Expert review needed

Thanks!

Ben.

> * The URLs for the references [S.R0048-A], [SC.R4002-0] and [X.S0008-0] do not resolve. Also, in the URL for [SC.R4002-0] the protocol should be added: <http://www.3gpp2.org/...>
<Roozbeh>
[S.R0048-A] the error was that "s" in "specs" within the URL should be capitalized.http://www.3gpp2.org/Public_html/Specs/S.R0048-A_v4.0_050630.pdf

[SC.R4002-0]: I think the document was replaced by the following in 2016. There is not much activity in 3GPP2 currently so I am not following it 
http://www.3gpp2.org/Public_html/Specs/SC.R4002-0_v12.0_GHA_%20Guidelines_for_MEID_December_2016.pdf

[X.S0008-0]: The same as above that "s" in "specs" within URL should be capitalized. however, I realized there is a newer document that we can use

http://www.3gpp2.org/Public_html/Specs/X.S0008-0_v3.0_090130.pdf

> * §3, sec "rules for lexical equivalence" say that MEID URNs are equal if they have the same meidval and the same parameter values but the syntax doesn't define parameter values for meidval. Also,…
<Roozbeh>
Please see the following modification and thereby the reference for RFC 3629 will be deleted.
Rules for Lexical Equivalence:
   Two 3GPP2 MEID URNs are equivalent if they have the same 'meidval'.   The comparisons are to be case-insensitive.
   Conformance with URN Syntax:
   The string representation of the '3gpp2' NID and of the MEID NSS is   fully compatible with the URN syntax (see [RFC8141]).
   Validation Mechanism:
   The MEID can be validated using the mechanism defined in [S.R0048-A].
   Scope:
   3GPP2 URN is global in scope.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 19 Jan 2018 22:24:40 -0500

Comments on draft-atarius-dispatch-meid-urn-14:

Summary:  This draft is useful and sensible and supplies a known need.
However, it needs a careful editing to get it cleaned up for
publication.

Possible major or global items:

As far as I can tell, the MEID check digit is "not transmitted" in the
sense that it's not part of the URN itself.  You should tidy up the
language used in this document.  In particular, you have to decide
whether the MEID contains or does not contain the check digit, and get
all the wording aligned.  E.g., the MEID is 15 hex digits, of which
only the first 14 are used in the URN (the check digit not being
transmitted), OR the MEID is 14 hex digits, of which all are used in
the URN, and the check digit is not transmitted as it isn't part of
the MEID.

If you allow that future changes will only be done via RFC, then you
can omit all mention of future-pp2-specifier in this RFC, as they will
be defined in later RFCs.  That could allow you to simplify this RFC
considerably (especially the ABNF), as it would only have to deal with
the one identifier class ("meid") that has already been defined.

Minor items:

Abstract

   The structure
   of an MEID is 15 hexadecimal encoded digits long and ...

s/hexadecimal encoded digits/hexadecimal digits/

1.  Introduction

   Document [RFC7254] defines a URN Namespace and an NSS for the IMEI.

I think the usual usage is to allow an RFC reference to be a noun, so
"Document" is redundant.

   For cases where the mobile equipment uses decimal values (i.e., IMEI)
   as an identity ...

The phrase "decimal values (i.e., IMEI)" is the wrong way around --
the important thing is that the identifier is an IMEI, it's just a
consequence that that the identifier is composed of decimal digits.
So s/decimal values (i.e., IMEI)/IMEI/.

   Whilst
   this specification currently specifies only the MEID NSS under the
   '3gpp2' NID, additional NSS under the '3gpp2' NID may be specified in
   the future by the 3GPP2.

This isn't particularly clear at this point in the document.  A fuller
explanation would be clearer as part of the introduction:

   This specification defines only NSSs constructed from MEIDs under
   the '3gpp2' NID.  These NSSs start with "meid:" in order to
   identify them as such.  Additional types of NSS under the '3gpp2'
   NID may be specified in the future by the 3GPP2 via additional
   specifications.

--

   The hexadecimal MEID is 15 hexadecimal digits long ...

s/The hexadecimal MEID/The MEID/

3.  Namespace Registration Template

   pp2-urn-char         = ALPHA / DIGIT / "-" / "." / "_" / "%" / ":"

% is not allowed as an independent character.  Looking at the
definition of URN (RFC 8141), an NSS is composed of pchar's and "/".
But "%" can only be a pchar as a percent-encoding (pct-encoded).

You probably want

   pp2-urn-char         = ALPHA / DIGIT / "-" / "." / "_" / pct-encoded / ":"

You may want to allow the value part of a future-param to be empty:

   future-param         = par-name [ EQUAL [ par-value ] ]

--

   <future-pp2-specifier> and <pp2-defined-nonempty> can comprise any
   ASCII characters compliant with URN syntax in [RFC5234].

This is not correct, as the URN syntax allows any pchar, whereas the
pp2-defined-nonempty does not allow the sub-delims "!", "$", "&", "'",
"(", ")", "*", "+", and ",", which are all valid pchars.

   Identifiers in the '3gpp2' NID are defined and assigned by the 3GPP2
   or an agency appointed by 3GPP2 after ensuring that the URNs to be
   assigned are unique.  Uniqueness is achieved by checking against the
   IANA registry of previously assigned names.

The last sentence of this paragraph makes no sense.  It seems to me
that it could be safely omitted.  OTOH, replacing "IANA" with the name
of the correct organization may also work.

   As the NID sought is '3gpp2', and 3GPP2 is the long standing acronym
   for the standards organization which includes the mobile phone
   operators, the URN should also persist indefinitely (at least as long
   as there is a need for its use).  The assignment process guarantees
   that names are not reassigned.  The binding between the name and its
   resource is permanent.

The phrase "3GPP2 is the long standing acronym for the standards
organization which includes the mobile phone operators" doesn't seem
to be useful -- the connection between the NID "3gpp2" and the 3GPP2
organization is assured to be permanent due to IANA procedures.  The
important part of the paragraph is that 3GPP2 has procedures to ensure
assignments within the NID are unique and persistent.

   The 3GPP2 or its approved agency will manage the <NSS> (including
   '3gpp2') and <future-pp2-specifier> identifier resources to maintain
   uniqueness.  The process for MEID assignment is documented in
   [SC.R4002-0].

I think you mean "'meid'" instead of "'3gpp2'" -- 3GPP2 does not
manage the "3gpp2" part of the URN itself.

   Two 3GPP2 MEID URNs are equivalent if they have the same 'meidval'
   and the same parameter values in the same sequential order.  All of
   these comparisons are to be case-insensitive.

This rule does not specify how future-pp2-specifier's are to be
compared.

   Any identifier in '3gpp2' NSS can be compared using the normal
   mechanisms for percent-encoded UTF-8 strings (see [RFC3629]).

RFC 3629 only describes the UTF-8 encoding itself, not how
percent-encoding of it is to be handled.  Perhaps you meant a
different RFC?

4.1.  MEID Parameters

   Any future change to the format of the 'meid' NSS requires the use of
   the procedure for URN NSS changes (currently through the publication
   of a future Informational RFCs approved by IETF consensus).

You have a choice here.  If you allow that future changes will only be
done via RFC, then you can omit all mention of future-pp2-specifier in
this RFC, as they will be defined in later RFCs.  That could allow you
to simplify this RFC considerably, as it would only have to deal with
identifier classes that have already been defined.

4.2.4.  Hexadecimal Encoding

This section is interesting but irrelevant.  As it says, "the
actual storage format in memory is implementation specific".  As such,
the only storage format that is relevant to this document is how the
abstract MEID (a sequence of 14 or 15 elements drawn from the set of
hex digits) is represented in the URN.

8.  Security and privacy considerations

I haven't checked, but I assume that you've constructed this section
to closely parallel section 8 of RFC 7254 (the IMEI URN).  That will
ensure that privacy concerns are satisfied.  (RFC 7253 was delayed
considerably due to privacy concerns.)

10.1.  Normative References

   [draft-atarius-dispatch-meid-urn-as-instanceid]
              Atarius, R., "S.R0048-A: Using the Mobile Equipment
              Identity (MEID) Uniform Resource Name (URN) as an Instance
              ID", Internet Draft draft-atarius-dispatch-meid-urn-as-
              instanceid, January 2018.

This isn't a normative reference -- this draft does not normatively
depend on "MEID as Instance ID".  (Contrarily, that draft *does*
normatively depend on this draft.)

Also, its title does not start with "S.R0048-A:".

Dale

---

From: "Svensson, Lars" <[email-masked]>
Date: Tue, 23 Jan 2018 16:14:08 +0000

Hi Rozbeh,

Thanks, that answers my concerns. I saw that Dale had comments on some other items so I’ll look at the draft again when you’ve published a new version (-16).

Best,

Lars

From: R Atarius [mailto:[email-masked]]
Sent: Tuesday, January 16, 2018 11:33 PM
To: Ben Campbell <[email-masked]>; Svensson, Lars <[email-masked]>
Cc: [email-masked]
Subject: Re: [urn] [Marketing Mail] Expert review needed

Hello Lars,

Thanks
Roozbeh

________________________________
From: Ben Campbell <[email-masked]<mailto:[email-masked]>>
To: "Svensson, Lars" <[email-masked]<mailto:[email-masked]>>
Cc: R Atarius <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 16, 2018 8:08 AM
Subject: Re: [urn] [Marketing Mail] Expert review needed

> On Jan 16, 2018, at 6:37 AM, Svensson, Lars <[email-masked]<mailto:[email-masked]>> wrote:
>
> Dear Roozbeh,
>
> On Sunday, January 14, 2018 4:44 AM, urn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of R Atarius wrote:
>

Thanks!

Ben.

<Roozbeh>

[S.R0048-A] the error was that "s" in "specs" within the URL should be capitalized.
http://www.3gpp2.org/Public_html/Specs/S.R0048-A_v4.0_050630.pdf

<Roozbeh>

   Two 3GPP2 MEID URNs are equivalent if they have the same 'meidval'.
   The comparisons are to be case-insensitive.

   The string representation of the '3gpp2' NID and of the MEID NSS is
   fully compatible with the URN syntax (see [RFC8141]).

   Validation Mechanism:

   Scope:

> [email-masked]<mailto:[email-masked]>

---

From: R Atarius <[email-masked]>
Date: Tue, 23 Jan 2018 16:16:06 +0000 (UTC)

OK!
We are working on Dale's comments.
ThanksRoozbeh

      From: "Svensson, Lars" <[email-masked]>
 To: R Atarius <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; Ben Campbell <[email-masked]>
 Sent: Tuesday, January 23, 2018 8:14 AM
 Subject: RE: [urn] [Marketing Mail] Expert review needed
   
#yiv5518601694 #yiv5518601694 -- _filtered #yiv5518601694 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv5518601694 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5518601694 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv5518601694 {font-family:Verdana;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv5518601694 #yiv5518601694 p.yiv5518601694MsoNormal, #yiv5518601694 li.yiv5518601694MsoNormal, #yiv5518601694 div.yiv5518601694MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5518601694 a:link, #yiv5518601694 span.yiv5518601694MsoHyperlink {color:blue;text-decoration:underline;}#yiv5518601694 a:visited, #yiv5518601694 span.yiv5518601694MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv5518601694 p.yiv5518601694msonormal0, #yiv5518601694 li.yiv5518601694msonormal0, #yiv5518601694 div.yiv5518601694msonormal0 {margin-right:0cm;margin-left:0cm;font-size:12.0pt;}#yiv5518601694 span.yiv5518601694E-MailFormatvorlage18 {color:#44546A;}#yiv5518601694 .yiv5518601694MsoChpDefault {font-size:10.0pt;} _filtered #yiv5518601694 {margin:70.85pt 70.85pt 2.0cm 70.85pt;}#yiv5518601694 div.yiv5518601694WordSection1 {}#yiv5518601694 Hi Rozbeh,    Thanks, that answers my concerns. I saw that Dale had comments on some other items so I’ll look at the draft again when you’ve published a new version (-16).    Best,    Lars       From: R Atarius [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2018 11:33 PM
To: Ben Campbell <[email-masked]>; Svensson, Lars <[email-masked]>
Cc: [email-masked]
Subject: Re: [urn] [Marketing Mail] Expert review needed    Hello Lars,    Please see the responses inline:    Thanks Roozbeh    From: Ben Campbell <[email-masked]>
To: "Svensson, Lars" <[email-masked]>
Cc: R Atarius <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Tuesday, January 16, 2018 8:08 AM
Subject: Re: [urn] [Marketing Mail] Expert review needed    

> I have had a look athttps://www.ietf.org/id/draft-atarius-dispatch-meid-urn-15.txtand I don't think the document is quite ready for publication yet.
>

Thanks!

Ben. 

>     <Roozbeh>    [S.R0048-A] the error was that "s" in "specs" within the URL should be capitalized. http://www.3gpp2.org/Public_html/Specs/S.R0048-A_v4.0_050630.pdf    [SC.R4002-0]: I think the document was replaced by the following in 2016. There is not much activity in 3GPP2 currently so I am not following it     http://www.3gpp2.org/Public_html/Specs/SC.R4002-0_v12.0_GHA_%20Guidelines_for_MEID_December_2016.pdf       [X.S0008-0]: The same as above that "s" in "specs" within URL should be capitalized. however, I realized there is a newer document that we can use    http://www.3gpp2.org/Public_html/Specs/X.S0008-0_v3.0_090130.pdf          
> * §3, sec "rules for lexical equivalence" say that MEID URNs are equal if they have the same meidval and the same parameter values but the syntax doesn't define parameter values for meidval. Also, the rules say that the NSS can be compared "using the normal mechanisms for percent-encoded UTF-8 strings", but the syntax doesn't allow any characters outside ASCII. To me, those two parts seem unnecessary and perhaps you can simply delete them    <Roozbeh>    Please see the following modification and thereby the reference for RFC 3629 will be deleted.    Rules for Lexical Equivalence: 

    Validation Mechanism: 

    Scope: 

    3GPP2 URN is global in scope.    >

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Jan 2018 22:07:18 -0500

> the one identifier class ("meid") that has already been defined.

Thinking about this more, it seems to me that it might be better to
modify the grammar in this way:

[as before]
   pp2-NSS              = meid-specifier / future-pp2-specifier
   meid-specifier       = "meid:" meidval

[changed]
   future-pp2-specifier = future-specifier [ ":" 1*( pchar / "/" ) ]
   future-specifier     = 1*pp2-char
   pp2-char             = ALPHA / DIGIT / "-" / "." / "_" / "%"
                                           
[unchanged]
   ALPHA                = %x41-5A / %x61-7A; A-Z / a-z
   DIGIT                = %x30-39; 0-9

[removed]
   future-param         = par-name [ EQUAL par-value ]
   par-name             = pp2-defined-nonempty
   par-value            = pp2-defined-nonempty
   EQUAL                = "="
   pp2-defined-nonempty = 1*pp2-urn-char

This is more general than the current grammar regarding the format of
<future-pp2-specifier>, it's only slightly stricter than RFC 8141's
generic rules for NSSs.  But it allows you to call out that
<future-ppp2-specifier> starts with <future-specifier> (up to the first
":", or if no ":", to the end), and in the text you can say that
<future-specifier> can't be "meid".  That preserves the nice
"sub-namespace" structure that you've defined, without restricting the
syntax of the latter part of the NSS for non-meid sub-namespaces.  (Any
actual sub-namespace will be defined by a later document which will give
the (likely narrower) grammar for the sub-namespace.)

----------

I think these sections need work:

   4.1.  MEID Parameters

   ...

It's not clear what "MEID parameters" are, since the grammar explicitly
forbids parameters in the MEID sub-namespace.  And the first paragraph
of 4.1 simply says that any change to what is specified in this document
must be via an RFC -- which is true anyway because this will be any RFC.

The first paragraph of "Rules for Lexical Equivalence" talks of
parameter values for 3gpp2:meid URNs, but there are no such parameters.

The first paragraph of "Rules for Lexical Equivalence" also says that
3gpp2:meid URNs are to be compared case-insensitively, but the grammar
allows no variance of case within the NSS:  "meid" is lower case and
<meidval> is upper case.

The second paragraph of "Rules for Lexical Equivalence" says that all
3gpp2 URNs can be compared "using the normal mechanisms for
percent-encoded UTF-8 strings", which is implicitly case-sensitive.

Dale

---

From: R Atarius <[email-masked]>
Date: Tue, 30 Jan 2018 04:45:08 +0000 (UTC)

Hi Dale,
I have segmented your comments by adding
******************************************************* line
and the second comment that you had on the first comment, is marked by 
---------------------------------------------------------------- line

My comments and proposed text are marked by <Roozbeh>
ThanksRoozbeh

Dale Wrote:
Comments on draft-atarius-dispatch-meid-urn-14:
Summary:  This draft is useful and sensible and supplies a known need.However, it needs a careful editing to get it cleaned up forpublication.
Possible major or global items:

********************************************************************
As far as I can tell, the MEID check digit is "not transmitted" in thesense that it's not part of the URN itself.  You should tidy up thelanguage used in this document.  In particular, you have to decidewhether the MEID contains or does not contain the check digit, and getall the wording aligned.  E.g., the MEID is 15 hex digits, of whichonly the first 14 are used in the URN (the check digit not beingtransmitted), OR the MEID is 14 hex digits, of which all are used inthe URN, and the check digit is not transmitted as it isn't part ofthe MEID.
<Roozbeh> How about having this in two sections:

First in the introduction 
"1.  Introduction
.....
   The hexadecimal MEID is 15 hexadecimal digits long and includes a   manufacturer code of 8 hexadecimal digits and the serial number of 6   hexadecimal digits plus a hexadecimal digit as a check digit.
   The manufacturer code identifies the mobile equipment manufacturer.   A manufacturer can be assigned more than one manufacturer code.  The   serial number uniquely identifies each mobile equipment within the   manufacturer code.  The check digit 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. Thus the first 14 of the 15 dexadecimal digits are    solely used for defining the MEID as a URN. 
   .... "
and in the section 4.2.3

"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."
********************************************************************
Dale's INITIAL COMMENT:
If you allow that future changes will only be done via RFC, then youcan omit all mention of future-pp2-specifier in this RFC, as they willbe defined in later RFCs.  That could allow you to simplify this RFCconsiderably (especially the ABNF), as it would only have to deal withthe one identifier class ("meid") that has already been defined.
<Roozbeh>:This draft was initially written to be aligned with the text inRFC 7254. In that document the future changes  were introduced and that is the reason this document also contains those. ------------------------------------------------------------------------
Dale's SECOND COMMENT:
Thinking about this more, it seems to me that it might be better tomodify the grammar in this way:
[as before]  pp2-NSS              = meid-specifier / future-pp2-specifier  meid-specifier      = "meid:" meidval
[changed]  future-pp2-specifier = future-specifier [ ":" 1*( pchar / "/" ) ]  future-specifier    = 1*pp2-char  pp2-char            = ALPHA / DIGIT / "-" / "." / "_" / "%"                                          [unchanged]  ALPHA                = %x41-5A / %x61-7A; A-Z / a-z  DIGIT                = %x30-39; 0-9
[removed]  future-param        = par-name [ EQUAL par-value ]  par-name            = pp2-defined-nonempty  par-value            = pp2-defined-nonempty  EQUAL                = "="  pp2-defined-nonempty = 1*pp2-urn-char
This is more general than the current grammar regarding the format of<future-pp2-specifier>, it's only slightly stricter than RFC 8141'sgeneric rules for NSSs.  But it allows you to call out that<future-ppp2-specifier> starts with <future-specifier> (up to the first":", or if no ":", to the end), and in the text you can say that<future-specifier> can't be "meid".  That preserves the nice"sub-namespace" structure that you've defined, without restricting thesyntax of the latter part of the NSS for non-meid sub-namespaces.  (Anyactual sub-namespace will be defined by a later document which will givethe (likely narrower) grammar for the sub-namespace.)
<Roozbeh>: With the previous comment you gave about replacing "%" withpct-encoded, then the text is modified to 
   pp2-urn              = "urn:" pp2-NID ":" pp2-NSS   pp2-NID              = "3gpp2"   pp2-NSS              = meid-specifier / future-pp2-specifier   meid-specifier       = "meid:" meidval   future-pp2-specifier = future-specifier [ ":" 1*( pchar / "/" ) ]   future-specifier     = 1*pp2-char   pp2-char             = ALPHA / DIGIT / "-" / "." / "_" / pct-encoded   ALPHA                = %x41-5A / %x61-7A; A-Z / a-z   DIGIT                = %x30-39; 0-9
********************************************************************
Minor items:
Abstract
  The structure  of an MEID is 15 hexadecimal encoded digits long and ...
s/hexadecimal encoded digits/hexadecimal digits/
<Roozbeh> OK!
********************************************************************
1.  Introduction
  Document [RFC7254] defines a URN Namespace and an NSS for the IMEI.
I think the usual usage is to allow an RFC reference to be a noun, so"Document" is redundant.
<Roozbeh> How about 

A URN Namespace and an NSS for the IMEI are defined in [RFC7254].
********************************************************************
  For cases where the mobile equipment uses decimal values (i.e., IMEI)  as an identity ...

The phrase "decimal values (i.e., IMEI)" is the wrong way around --the important thing is that the identifier is an IMEI, it's just aconsequence that that the identifier is composed of decimal digits.So s/decimal values (i.e., IMEI)/IMEI/.
<Roozbeh> OK!
********************************************************************
  Whilst  this specification currently specifies only the MEID NSS under the  '3gpp2' NID, additional NSS under the '3gpp2' NID may be specified in  the future by the 3GPP2.
This isn't particularly clear at this point in the document.  A fullerexplanation would be clearer as part of the introduction:
  This specification defines only NSSs constructed from MEIDs under  the '3gpp2' NID.  These NSSs start with "meid:" in order to  identify them as such.  Additional types of NSS under the '3gpp2'  NID may be specified in the future by the 3GPP2 via additional  specifications.
<Roozbeh> OK!
--

********************************************************************
  The hexadecimal MEID is 15 hexadecimal digits long ...
s/The hexadecimal MEID/The MEID/
<Roozbeh> OK!
********************************************************************
3.  Namespace Registration Template
  pp2-urn-char        = ALPHA / DIGIT / "-" / "." / "_" / "%" / ":"
% is not allowed as an independent character.  Looking at thedefinition of URN (RFC 8141), an NSS is composed of pchar's and "/".But "%" can only be a pchar as a percent-encoding (pct-encoded).
You probably want
  pp2-urn-char        = ALPHA / DIGIT / "-" / "." / "_" / pct-encoded / ":"
<Roozbeh> OK!
You may want to allow the value part of a future-param to be empty:
  future-param        = par-name [ EQUAL [ par-value ] ]
<Roozbeh> With your new comments this part has already been removed.

********************************************************************
  <future-pp2-specifier> and <pp2-defined-nonempty> can comprise any  ASCII characters compliant with URN syntax in [RFC5234].
This is not correct, as the URN syntax allows any pchar, whereas thepp2-defined-nonempty does not allow the sub-delims "!", "$", "&", "'","(", ")", "*", "+", and ",", which are all valid pchars.
<Roozbeh> Perhaps you have looked at revision 14 of this document. The refernce is RFC 8141 in revision 15 of the document, i.e.
  <future-pp2-specifier> and <pp2-defined-nonempty> can comprise any  ASCII characters compliant with URN syntax in [RFC8141].
********************************************************************
  Identifiers in the '3gpp2' NID are defined and assigned by the 3GPP2  or an agency appointed by 3GPP2 after ensuring that the URNs to be  assigned are unique.  Uniqueness is achieved by checking against the  IANA registry of previously assigned names.
The last sentence of this paragraph makes no sense.  It seems to methat it could be safely omitted.  OTOH, replacing "IANA" with the nameof the correct organization may also work.
<Roozbeh> the last sentence is already omitted in revivion 15 of the draft which is draft-atarius-dispatch-meid-urn-15
********************************************************************
  As the NID sought is '3gpp2', and 3GPP2 is the long standing acronym  for the standards organization which includes the mobile phone  operators, the URN should also persist indefinitely (at least as long  as there is a need for its use).  The assignment process guarantees  that names are not reassigned.  The binding between the name and its  resource is permanent.
The phrase "3GPP2 is the long standing acronym for the standardsorganization which includes the mobile phone operators" doesn't seemto be useful -- the connection between the NID "3gpp2" and the 3GPP2organization is assured to be permanent due to IANA procedures.  Theimportant part of the paragraph is that 3GPP2 has procedures to ensureassignments within the NID are unique and persistent.
<Roozbeh>: How about
 The NID sought is '3gpp2',  and the URN should persist indefinitely (at least as long as there is a need for its use). The standards organization  3GPP2  ensures assignments within the NID are unique and persistent.  The IANA procedures assure that the connection between the  3GPP2 and the NID '3gpp2' is permanent.
********************************************************************
  The 3GPP2 or its approved agency will manage the <NSS> (including  '3gpp2') and <future-pp2-specifier> identifier resources to maintain  uniqueness.  The process for MEID assignment is documented in  [SC.R4002-0].
I think you mean "'meid'" instead of "'3gpp2'" -- 3GPP2 does notmanage the "3gpp2" part of the URN itself.
<Roozbeh>: Yes, thanks!
********************************************************************
Dale's FIRST COMMENT:
  Two 3GPP2 MEID URNs are equivalent if they have the same 'meidval'  and the same parameter values in the same sequential order.  All of  these comparisons are to be case-insensitive. 
This rule does not specify how future-pp2-specifier's are to becompared.
<Roozbeh> The definition for future-pp2-specifier has now been changedand it should be OK! 
----------------------------------------------------------------------
Dale's SECOND COMMENT:
 Rules for Lexical Equivalence:
  Two 3GPP2 MEID URNs are equivalent if they have the same 'meidval'  and the same parameter values in the same sequential order.  All of  these comparisons are to be case-insensitive.
  Any identifier in '3gpp2' NSS can be compared using the normal  mechanisms for percent-encoded UTF-8 strings (see [RFC3629]).
It's not clear what "MEID parameters" are, since the grammar explicitlyforbids parameters in the MEID sub-namespace.  And the first paragraphof 4.1 simply says that any change to what is specified in this documentmust be via an RFC -- which is true anyway because this will be any RFC.
The first paragraph of "Rules for Lexical Equivalence" talks ofparameter values for 3gpp2:meid URNs, but there are no such parameters.
The first paragraph of "Rules for Lexical Equivalence" also says that3gpp2:meid URNs are to be compared case-insensitively, but the grammarallows no variance of case within the NSS:  "meid" is lower case and<meidval> is upper case.
The second paragraph of "Rules for Lexical Equivalence" says that all3gpp2 URNs can be compared "using the normal mechanisms forpercent-encoded UTF-8 strings", which is implicitly case-sensitive.
<Roozbeh> See the following suggestion

  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.    Any identifier in '3gpp2' NSS can be compared using the normal  mechanisms for percent-encoded UTF-8 strings (see [RFC3629]).

********************************************************************
  Any identifier in '3gpp2' NSS can be compared using the normal  mechanisms for percent-encoded UTF-8 strings (see [RFC3629]).
RFC 3629 only describes the UTF-8 encoding itself, not howpercent-encoding of it is to be handled.  Perhaps you meant adifferent RFC?
<Roozbeh> does the following make sense
   Any identifier in '3gpp2' NSS can be compared using the normal   mechanisms for percent-encoded UTF-8 strings, where the UTF-8   is defined in [RFC3629].

********************************************************************
4.1.  MEID Parameters
  Any future change to the format of the 'meid' NSS requires the use of  the procedure for URN NSS changes (currently through the publication  of a future Informational RFCs approved by IETF consensus).
You have a choice here.  If you allow that future changes will only bedone via RFC, then you can omit all mention of future-pp2-specifier inthis RFC, as they will be defined in later RFCs.  That could allow youto simplify this RFC considerably, as it would only have to deal withidentifier classes that have already been defined.
<Roozbeh>: This issue should have been resolved with the secondcomments.
********************************************************************
4.2.4.  Hexadecimal Encoding
This section is interesting but irrelevant.  As it says, "theactual storage format in memory is implementation specific".  As such,the only storage format that is relevant to this document is how theabstract MEID (a sequence of 14 or 15 elements drawn from the set ofhex digits) is represented in the URN.
<Roozbeh> I think this section is useful so I would like to keep it.The reason for this text is you show a digit to octets diagram but it does not mean that you have to store the digits this way
********************************************************************
8.  Security and privacy considerations
I haven't checked, but I assume that you've constructed this sectionto closely parallel section 8 of RFC 7254 (the IMEI URN).  That willensure that privacy concerns are satisfied.  (RFC 7253 was delayedconsiderably due to privacy concerns.)
<Roozbeh>: I received many commenst on this section and have made therequested changes. So, I am hoping it is good now.

********************************************************************
10.1.  Normative References

  [draft-atarius-dispatch-meid-urn-as-instanceid]
              Atarius, R., "S.R0048-A: Using the Mobile Equipment              Identity (MEID) Uniform Resource Name (URN) as an Instance              ID", Internet Draft draft-atarius-dispatch-meid-urn-as-              instanceid, January 2018.
This isn't a normative reference -- this draft does not normativelydepend on "MEID as Instance ID".  (Contrarily, that draft *does*normatively depend on this draft.)
Also, its title does not start with "S.R0048-A:".
<Roozbeh> OK! I will move this to the informative references andwill correct the title.

********************************************************************
Dale

      From: Dale R. Worley <[email-masked]>
 To: Dale R. Worley <[email-masked]> 
Cc: [email-masked]; [email-masked]
 Sent: Thursday, January 25, 2018 7:07 PM
 Subject: Re: [urn] Expert review needed

[as before]

[changed]
                                          
[unchanged]

[removed]

----------

  4.1.  MEID Parameters

  ...

Dale