Re: [urn] Expert review needed

[[e-mail] (Dale R. Worley)]

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