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

[Charlie Perkins <[e-mail]>]

Hello Dale,

O.K.  I will take a crack at making this reorganization.  If you have 
text of course that will be appreciated.  Right now I don't see why 
anyone in the WG would object, but I hope at least some people will take 
a look.

I can have the revised draft ready in a few days.  I think this resolves 
the last point of discussion that has been raised about the draft.

Regards,
Charlie P.


On 2/14/2017 5:04 PM, Dale R. Worley wrote:
> 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
>