Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

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

Charlie Perkins <[e-mail]> writes:
> I am hesitant to replace so many MNID types by a single URN type with 
> substructure.  What would you think about replacing the existing 
> RFID-*-URI types with a single URN type, but leaving the existing binary 
> types?  This gets the benefit you suggest for future extensibility, but 
> retains the shorter forms that may often be advantageous.

Suddenly today I realized something I should have realized in the
review, which would have saved us much time in discussion.  Viz.,
consider this proposal:

- one MNID type for *all* the EPC binary schemes

- one MNID type for *all* URNs, *including* the EPC URI forms

This would work, since (1) (not surprisingly) the EPC binary schemes are
all differentiated by their first 8 bits.  (see table on page 19 of the
tag-data standard,
http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_1_rev_1_27-standard-20050510.pdf)
and (2) all URNs are differentiated by their namespace part.

(This parallels using one MNID number for all DUID types, since DUIDs
have an internal indicator for the four types.)

This approach has all the desirable properties anyone has mentioned so
far:

- includes all EPC binary and URI forms
- automatically includes all existing and future EPC binary forms
- automatically includes all existing and future URN forms *including*
  all existing and future EPC URI forms
- doesn't have a proliferation of MNID type numbers which duplicate
  information that can be fairly easily extracted from the
  identifier itself
- includes all the short EPC forms, allowing brevity when that is
  desirable

This seems to be practical, simple, and almost as elegant as possible.
What do you think?

> I changed the text as follows:
>
>>     Some MNIDs contain sensitive identifiers which, as used in protocols
>>     specified by other SDOs, are only used for signaling during initial
>>     network entry.  In such protocols, subsequent exchanges then rely on
>>     a temporary identifier allocated during the initial network entry.
>>     Managing the association between long-lived and temporary identifiers
>>     is outside the scope of this document.
>
> I can't remember exactly why this text was added - it was a long time 
> ago.  But anyway the main point is to simply mention that there may be 
> associations between some of the MNID types that might be important from 
> a security standpoint, without meaning to go into examples.

Certainly the new text is clear enough.

Dale