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

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 2 Feb 2017 05:09:34 +0000

Thank you Dale for a great review.

Charlie/Authors - Can you please respond to Dale and address these
comments.

Regards
Sri

On 1/31/17, 11:34 AM, "dmm on behalf of Dale Worley" <[email-masked]
on behalf of [email-masked]> wrote:

>Reviewer: Dale Worley
>Review result: Ready with Issues
>
>I am the assigned Gen-ART reviewer for this draft.  The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed
>by the IESG for the IETF Chair.  Please treat these comments just
>like any other last call comments.
>
>For more information, please see the FAQ at
><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>Document:  draft-ietf-dmm-4283mnids-04
>Reviewer:  Dale R. Worley
>Review Date:  31 Jan 2017
>IETF LC End Date:  2 Feb 2017
>IESG Telechat date:  16 Feb 2017
>
>Summary:
>
>       This draft is on the right track but has open issues,
>described
>       in the review.
>
>Technical issues:
>
>1. The Introduction states
>
>   Other types of identifiers are in
>   common use, and even referenced in RFC 4283.
>
>For the reader's sanity, some sort of accounting needs to be made of
>these "other types of identifiers", especially because each type of
>identifier needs an identifier type number.  The text in 4283 is
>
>   Some examples of identifiers
>   include Network Access Identifier (NAI), Fully Qualified Domain
>Name
>   (FQDN), International Mobile Station Identifier (IMSI), and Mobile
>   Subscriber Number (MSISDN).
>
>Are there any other types "in common use"?
>
>- NAI (type 1) is defined by 4283.
>- Fully Qualified Domain Name (FQDN) seems not to be specified
>- International Mobile Station Identifier (IMSI) (type 3) is defined
>in
>  this draft
>- Mobile Subscriber Number (MSISDN) seems not to be specified
>
>2. Is it intended to have an IMEI identifier type?  The introduction
>mentions an IMEI type, but there is no specification for it, nor is
>there an identifier type number assigned for it.
>
>   ... types for IMSI
>   [ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and
>GUTI
>   [ThreeGPP-IDS].
>
>Initially I suspected it was it was present in an earlier revision
>and
>then later deleted without this reference being updated.  But all
>versions of draft-ietf-dmm-4283mnids and its predecessor
>draft-perkins-dmm-4283mnids mention IMEI in this way as one
>identifier
>type, but none specify it in any way.  The only discussion I can find
>on the DMM mailing list of IMEI is:
>
>   
>https://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk/?qid
>=d29575f767ce67a1e67a7767008ee6af
>
>    From: Marco Liebsch <[email-masked]>
>    To: DMM
>    Date: Wed, 10 September 2014 13:29 UTC
>    Re: [DMM] regarding the re-chartering..
>
>    It seems the MNID is somehow overloaded to carry both,
>node-specific
>    IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI.
>    There may be value in adding the IMEI to the list of possible
>types of
>    node-specific IDs.
>
>Either the presence of IMEI in this list is a simple mistake that has
>persisted in all versions of the draft, or specifying IMEI has always
>been intended but has always been overlooked.
>
>3. The definition of identifier types for both EUI-48 and EUI-64
>suggests that it might be desirable to define an identifier type for
>arbitrary hardware (link-level) addresses.  It seems that the natural
>differentiator for that purpose is the "hardware type" used in ARP,
>so
>a EUI-48 address would be represented as
>
>    MN identifier type (one octet) 5 (say)
>    hardware type (two octets) 1
>    EUI-48 (six octets)
>
>and an EUI-64 similarly, with hardware type 27.
>
>Although with only two subtypes in common use, generalizing this
>might
>not be worth the effort.
>
>4. Several of the identifier types can be represented as URNs:
>
>- IMEI can be represented as a URN as urn:gsma:imei:...
>- all of the RFID types have a URN representation (called the
>  "pure-identity URI" in the RFID specifications), which starts
>  urn:epc:id:...
>
>Since all URN types are ensured of being unique and persistent, it
>seems that we could define a MNID type for URNs generally, and then
>any RFID URI or an IMEI (as a URN) could be used as a value of that
>type.
>
>If this idea is adopted, it seems that the other 3GPP types (IMSI,
>P-TMSI, and GUTI) should be given defined encodings as URNs in new
>sub-namespaces of the "gsma" URN namespace, to parallel the encoding
>of IMEIs defined in RFC 7254.
>
>This consolidation could be significantly beneficial.  It allows MNID
>to use any URN scheme as an identifier.  It reduces the three
>different RFID representations to one.  It incorporates any future
>expansion of RFID schemes (because all schemes will have a
>pure-identity URN representation).  A disadvantage is that the URN
>encodings are long, but the security considerations section states
>that MNIDs are used only on the first registration at the home agent,
>so there isn't much need for brevity.
>
>Similarly, this approach incorporates any future expansion of mobile
>identifiers that GSMA decides to define, as long as GSMA provides a
>URN representation for it.
>
>The most significant disadvantage is that some URN schemes allow
>several character strings to "mean" the same URN.  In most URN
>schemes, the allowed variation is limited to the case of letters, and
>the common convention is to always use lower-case when there is a
>choice, leading to a unique conventional canonical form for the URN.
>
>5. Regarding the encoding of a string of digits into octets, it is
>stated that "The last digit MUST be zero padded, if needed, for full
>octet size."  This seems very unwise unless there is a 3GPP decree
>that if a zero is appended to a valid IMSI, the resulting string is
>never a valid IMSI.  Instead, I would specify that padding is by
>filling the low-order 4 bits of the final octet with 0xF.  That
>ensures that the encoding can be uniquely decoded into an IMSI.
>
>6. There are four types of DUID specified, each with a distinct MNID
>value.  However, DUIDs contain an initial two-octet type field which
>distinguishes the various types of DUID, so providing them with
>distinct MNID values is redundant.
>
>Distinguishing the types and allowing only four of them to be used as
>MNIDs seems to be contrary to the philosophy of DUID construction
>(RFC
>3315 section 9):
>
>   Clients and servers MUST treat DUIDs as opaque values and MUST
>only
>   compare DUIDs for equality.  Clients and servers MUST NOT in any
>   other way interpret DUIDs.  Clients and servers MUST NOT restrict
>   DUIDs to the types defined in this document, as additional DUID
>types
>   may be defined in the future.
>
>Of course, MNID isn't a DHCP operation, so it isn't subject to those
>requirements, but I expect that devices will use the same DUID for
>both mobile identification, and we don't want mobile identification
>to
>restrict future developments of DHCP.
>
>I think this specification must treat DUIDs as opaque and use only
>one
>MNID type that allows all types of DUIDs as values.
>
>Editorial issues:
>
>Abstract
>
>   Additional Identifier Types are proposed for use with the Mobile
>Node
>   Identifier Option for IPv6 (RFC 4283).
>
>s/proposed/defined/
>This document will define the new types (once it is approved)!
>
>1.  Introduction
>
>   ... types for IMSI
>   [ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and
>GUTI
>   [ThreeGPP-IDS].
>
>There is no description of P-TMSI identifiers, although it is
>assigned
>identifier type 4.
>
>There is no description of GUTI identifiers, although it is assigned
>identifier type 7.
>
>3.  New Mobile Node Identifier Types
>
>   The following types of identifiers are commonly used to identify
>   mobile nodes.  For each type, references are provided with full
>   details on the format of the type of identifier.
>
>   The Tag Data standard promoted by Electronic Product Code(TM)
>   (abbreviated EPC) supports several encoding systems or schemes
>   including
>
>   o  RFID-GID (Global Identifier),
>   o  RFID-SGTIN (Serialized Global Trade Item Number),
>   o  RFID-SSCC (Serial Shipping Container),
>   o  RFID-SGLN (Global Location Number),
>   o  RFID-GRAI (Global Returnable Asset Identifier),
>   o  RFID-DOD (Department of Defense ID), and
>   o  RFID-GIAI (Global Individual Asset Identifier).
>
>   For each RFID scheme except GID, there are two variations: a
>64-bit
>   scheme (for example, SGLN-64) and a 96-bit scheme (SGLN-96).  GID
>has
>   only a 96-bit scheme.  Within each scheme, an EPC identifier can
>be
>   represented in a binary form or other forms such as URI.
>
>   The following list includes the above RFID types as well as
>various
>   other common identifiers and several different types of DUIDs.
>
>The organization of the text here seems to be poor -- section 3
>enumerates the new identifier types, but much of the text at the
>beginning of the section is about the RFID-EPC set of types.  It
>seems
>like a better organization is to use just paragraph 1 followed by
>table 1, and move paragraphs 2-5 into section 4.9.
>
>   The Tag Data standard promoted by Electronic Product Code(TM)
>   (abbreviated EPC) supports several encoding systems or schemes
>   including
>
>The text is using "Tag Data", "EPC", and "RFID" in a way that is
>intertwined but not explained.  I can see that it might be useful to
>use all of the terms if they commonly used in the field (don't forget
>to make them keywords for the RFC!), but you need to explain their
>connection and distinction to the reader or make it clear that the
>reader does not need to understand the differences among the terms.
>E.g., this formulation ties all three terms together
>
>   The Tag Data standard promoted by Electronic Product Code(TM)
>   (abbreviated EPC) supports several encoding systems or schemes
>   which are commonly used in RFID (radio-frequency identification)
>   applications, including
>
>--
>
>   For each RFID scheme except GID, there are two variations: a
>64-bit
>   scheme (for example, SGLN-64) and a 96-bit scheme (SGLN-96).  GID
>has
>   only a 96-bit scheme.  Within each scheme, an EPC identifier can
>be
>   represented in a binary form or other forms such as URI.
>
>The text uses "scheme" to mean the distinction between encoding
>systems (GID, SGTIN, etc.) and and also to mean the distinction
>between the 64-bit and 96-bit variations.  This ambiguity is unwise.
>It matters here, because you say "within each scheme ... can be
>represented in a binary form or ... URI".  Which meaning of "scheme"
>are you using here?  I thought you meant the second meaning when I
>first read the paragraph, but after reading external documents about
>EPC, I now understand that that last sentence uses "scheme" to in the
>first sense.
>
>You need to be clearer here that there are three representations
>used,
>64-bit binary, 96-bit binary, and URI (URN, actually), and
>representation is orthogonal to the seven RFID schemes, with the
>exception that RFID-GID does not have a 96-bit binary representation.
>
>I'm assuming that the Tag Data standard unambiguously defines the
>serialization of the binary representations as a sequence of octets.
>If it does not, this document MUST do that, or you will have an
>endless nightmare of byte-order problems.
>
>4.  Descriptions of MNID types
>
>Identifier ownership is a general concern -- it's worth mentioning
>for
>each type of identifier where the assigner of the identifier obtains
>delegation.  For an EUI, I expect the reader will assume that it's an
>EUI assigned to the device under IEEE rules, and similarly for RFID
>and 3GPP identifiers.  But for DUID identifiers, it's less clear.
>I'm
>guessing that the DUID is one that is, or could be, used by the
>device
>for DHCP purposes.  For IPv6 addresses, it's even less clear, since
>the IPv6 architecture doesn't assume that the association of
>addresses
>with devices is permanent.
>
>4.1.  Description of the IPv6 address type
>
>It would be good if the document described what the semantics of this
>ID are.  Yes, it's a unicast IPv6 address, but what is the connection
>between that address and the device?  I suspect the connection is
>"the
>device has been configured to expect that it will be assigned this
>address as a long-term interface address", but there are other
>possibilities.  E.g., I can imagine a mobile carrier obtaining a /64
>prefix (there are plenty of them!) and then assigning addresses out
>of
>it simply to create a sequence of unique identifiers for devices, but
>not using those addresses on packets.
>
>Then again, perhaps you want to allow flexibility.  But in any case,
>I
>think you need to specify what the rules are for what address is
>associated with what device.
>
>4.2.  Description of the IMSI MNID type
>
>What does "in network order" mean here?  As far as I know, there is
>no
>defined "network order" for 4-bit quantities, only for dividing
>integers into octets and placing sequences of bits into octets.  I
>assume you mean that in any octet, the high-order 4 bits are the
>first
>digit and the low-order 4 bits are the second digit, but I think you
>need to state that explicitly.
>
>4.3.  Description of the EUI-48 address type
>
>   The IEEE EUI-48 address [IEEE802-eui48] is encoded as a 6 octet
>   string containing the IEEE EUI-48 address.
>
>Is "string" the correct word, this not being a sequence of
>characters?
>I would say "sequence of 6 octets" or simply "encoded as 6 octets".
>
>4.9.  Description of the RFID types
>
>This section needs to be revised.  It provides a lot of detail about
>the RFID types, but it's not enough detail for a reader who doesn't
>understand RFID to learn how any particular RFID scheme works.  E.g.,
>the first paragraph says that GID contains three fields in the first
>sentence, and that it contains four fields in the third sentence.
>Despite this, the description isn't enough to allow the reader to
>construct GID identifiers manually.
>
>On the other hand, readers who already understand the RFID schemes
>will find this text redundant.
>
>I think that almost all of this text can be replaced by references to
>the EPC documents, since these identifiers are opaque from the point
>of view of mobile identification.
>
>5.  Security Considerations
>
>The base MNID specification, RFC 4283, gives these security
>considerations (sec 4), which ought to be referenced and probably
>summarized in this section:
>
>   Moreover, MNIDs containing sensitive identifiers might only be
>used
>   for signaling during initial network entry.  Subsequent binding
>   update exchanges might then rely on a temporary identifier
>allocated
>   during the initial network entry, perhaps using mechanisms not
>   standardized within the IETF.  Managing the association between
>long-
>   lived and temporary identifiers is outside the scope of this
>   document.
>
>What is the meaning of the word "might" in paragraph 3?  I suspect
>that the purpose is to qualify this paragraph with "One way to
>address
>these vulnerabilities is to only use MNIDs containing ...".  But if
>that is the meaning, that expanded wording should be used.  Otherwise
>the text reads as if it is hypothetical.
>
>[END]
>
>
>_______________________________________________
>dmm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmm

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 1 Feb 2017 22:10:06 -0800

Hello Sri,

The review was indeed super.  I'll respond sometime in the next few days.

Regards,
Charlie P.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 10 Feb 2017 14:17:13 +0000

Hi Charlie,
  I have not yet seen a response to this review. Do you think you will be able to get to this in the next day or two? The document is on the February 16 2017 telechat and I would like to see resolution to these issues in time for the other ADs to ballot.

Thanks
Suresh

On 2/2/17, 1:10 AM, "Charlie Perkins" <[email-masked]> wrote:

    Hello Sri,

    Regards,
    Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 10 Feb 2017 07:30:01 -0800

Hello folks,

The last two days have been crammed full with other urgent work 
requirements.  I will respond to these comments today.

Suresh, do you mean to ask if I can submit a revised document before Monday?

Regards,
Charlie P.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 10 Feb 2017 15:35:04 +0000

Hi Charlie,

> On Feb 10, 2017, at 10:30 AM, Charlie Perkins <[email-masked]> wrote:
> 
> Hello folks,
> 
> The last two days have been crammed full with other urgent work requirements.  I will respond to these comments today.

Great.

> Suresh, do you mean to ask if I can submit a revised document before Monday?

No. If you can agree on the changes to be applied with Dale by Monday/Tuesday I think it would be great. If there are other comments in IESG eval, you can address them as well in a new revision.

Thanks
Suresh

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 10 Feb 2017 14:28:45 -0800

Hello Dale,

Thanks for the thorough review.  My follow-up comments are inline below.

> Are there any other types "in common use"?

I will add some text according to your suggestion.  My criterion for 
whether the identifier type was included in the document was whether or 
not anyone had asked for it to be included.

> - Mobile Subscriber Number (MSISDN) seems not to be specified

It is not the jurisdiction of the MNIDs document to specify these 
identifiers, but citations for the specifications are located elsewhere 
in the document.  I will also include those citations here.

> https://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk/?qid=d29575f767ce67a1e67a7767008ee6af
>

I don't know why this happened, but I am happy to include an identifier 
type for IMEI as well as a citation for it.  Thanks for catching this 
and looking through the archives!

> Although with only two subtypes in common use, generalizing this

Actually, I am O.K. either way on this matter.  However, at this point 
in time it does not seem that we are likely to see any other link 
hardware address types to be used as MNIDs.

> choice, leading to a unique conventional canonical form for the URN.

There is a sort of "hidden" disadvantage to long names, especially for 
tiny devices using constrained link layers.  Namely, a longer name makes 
it more likely to require lower-layer fragmentation.  I'm not sure that 
it should be the job of a layer-3 mobility entity to parse URNs and 
determine if two different flavors are supposed to be equivalent.

Other than that, I don't have any real objection to reorganizing the 
namespace, but I'd like some additional confirmation that it's a good idea.

> ensures that the encoding can be uniquely decoded into an IMSI.

I am O.K. with this.  I need to go find out where I got that language 
from, because I don't think I was the person who crafted it.

> MNID type that allows all types of DUIDs as values.

Thanks for this observation.  I will make the corresponding revisions to 
the text.

> This document will define the new types (once it is approved)!

O.K. with your modification.  The document just defines numbers for the 
types, not the types.

> There is no description of GUTI identifiers, although it is assigned

I will insert text from the relevant 3GPP documents to describe these 
identifiers.

> table 1, and move paragraphs 2-5 into section 4.9.

O.K.  Thanks for the suggestion.

>     which are commonly used in RFID (radio-frequency identification)

Thanks for the text.  I will use it.

This is a good idea.  How about the following:

>    For each RFID scheme except GID, there are three representations:
>     - a 64-bit binary representation (for example, SGLN-64)
>     - a 96-bit binary representation (SGLN-96).
>     - a representation as a URI

I didn't originate the use of URI for the non-binary representation. The 
EPC document has the following language:

> All categories of URIs are represented as Uniform Reference Names 
> (URNs) as defined by [RFC2141], where the URN Namespace is epc.
>

If I were to change it to URN, then I would have to go into some detail 
about why this document somehow disagrees with the EPC-Tag-Data 
document.  Do you think that is necessary?

> endless nightmare of byte-order problems.

I read through some relevant text in the EPC-Tag-Data document and it 
seems O.K. to me, but nontrivial and it relies on digging through other 
even more arcane documents to be absolutely sure.  I am pretty sure that 
the IETF document should not get into the business of augmenting the 
standards already in place from the external SDOs.

> with devices is permanent.

I hope that this document does not have to specify allocation procedures 
for the MNIDs.  It seems to me that if a system designer wants to use 
one of the MNID types, that person will already know about how to 
request the allocation and would not need to rely on the MNIDs document 
for that information.  Plus it's really out of scope.  This document was 
always intended to be a simple tabulation of types already in use 
elsewhere and enabling IETF mobility management protocols to use the 
most natural identifier available for a mobile node.  I hope that citing 
the defining documents for the identifier types will be enough to 
satisfy that.

> associated with what device.

As far as I have understood, the unicast IPv6 address in use as a MNID 
is already assigned to the device.  I have not heard anyone asking for 
this to be an address for future assignment.  I'll try to make that 
clear in the text.

> need to state that explicitly.

I probably lifted that language directly from the IMSI spec, but I can 
make further clarification according to your suggestion.

> I would say "sequence of 6 octets" or simply "encoded as 6 octets".

O.K.  I also lifted that language from elsewhere.
> of view of mobile identification.

Here I am at a loss, because I was specifically requested to insert some 
descriptive but not normative text.  I will ask the person who made the 
request to provide their feedback on the mailing list.  For myself, I am 
more than happy to delete the text.

> the text reads as if it is hypothetical.

This text was meant to be generally descriptive, so that people wanting 
to include the Mobile Node Identifier Option with the relevant MNIDs 
could understand how the identifiers are actually used in various 
circumstances.  I could replace constructions using "might" with "in 
some specifications" or "in some situations" if needed.  Is it also 
necessary to include citations to the relevant documents of the external 
SDO?

Regards,
Charlie P.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 13 Feb 2017 00:52:42 +0000

Hi Charlie,

Please see inline.

From: dmm <[email-masked]<mailto:[email-masked]>> on behalf of Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 10, 2017 at 2:28 PM
To: Dale Worley <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[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]>>
Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

> Here I am at a loss, because I was specifically requested to insert some descriptive but not normative text.  I will ask the person who made the request to provide their feedback on the mailing list.  For myself, I am more than happy to delete the text.

When we discussed this issue in the past, the general feedback from the WG was that the draft should provide some minimal amount of details on the new identifier types, what the identifier is, how the identifier is constructed, what is the access technology and a reference to the specification that provides that definition. The idea is NOT TO provide extensive details on the spec, but to enable a reader with some high level details and a pointer to the specification. I tend to think the text in the current specification just does that. If the text is seen as redundant text, we can certainly add a statement saying that the definition for the identifier is provided in spec-XYZ and is repeated here for convenience. May be other folks in the WG have some views on this.

Comments from 10/11/2015 email:

"Some text on the motivation for defining new Types may be helpful. Document is not just standardizing the currently in-use/popular identifier types, its also introducing new types are not in use. The reasons/interest for defining identifiers that are tied to the physical elements of the device (RFID, MAC address ..etc) and how it helps in deployment of the technology may be useful. Few lines of text will really help."

"I was hoping to see a sub-section for each of the types. We cannot standardize a identifier type without providing any explanation on the identifier type or the references to the base definitions. This can be painful, but I'd have a small section for each of the types. It can be 3 line text on the a.) Definition b.) Format c.) Example format d.) Reference to the base spec that defines those identifiers."

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 12 Feb 2017 22:13:16 -0500

> not anyone had asked for it to be included.

A good criterion -- if it's commonly used, likely someone would have
asked.

> >   in this draft

What I was noting was that 4283 says:

   Mobile IPv6
   nodes need the capability to identify themselves using an identity
   other than the default home IP address.  Some examples of identifiers
   include Network Access Identifier (NAI), Fully Qualified Domain Name
   (FQDN), International Mobile Station Identifier (IMSI), and Mobile
   Subscriber Number (MSISDN).

but that taking 4283 and this document together, there is no way to
specify FQDN or MSISDN as MN identifiers.  If in practice, people don't
use either of those, then the situation is OK, though 4283 is
inaccurate.  But if people do use FQDNs or MSISDNs as MN identifiers,
should those be added to this document?  (I can't find them specified
elsewhere.)

> and looking through the archives!

I'm not saying, "Add it because I think it's a good idea to use IMEIs.",
I'm saying, "Your introduction says that you define an MNID type for
IMEIs, but you don't."  Perhaps there is no need for IMEIs, but in that
case, the introduction needs to be edited.

> hardware address types to be used as MNIDs.

I agree with you there, although I wouldn't be entirely surprised if a
new mobile network introduced a new link-layer address.  But there
doesn't seem to be much value in making the change I suggested, other
than for generality.

> namespace, but I'd like some additional confirmation that it's a good idea.

There are a couple of reasons I like this idea.

One is that EPC seems to have a policy of providing a URN form for all
of the identifier classes it defines.  Making a single URN MNID type
means that you've incorporated all future classes of identifier that EPC
defines.

A single URN MNID type would incorporate any of the defined URN
namespaces that turn out to be useful for anybody.  This isn't so
interesting for really large deployments, since they could ask for a new
MNID type, but experimental or small-scale deployments may want to
define their own identifiers, and URNs provide several convenient ways
to do that.

It removes a certain amount of redundancy, in that each RFID class now
has three representations, for a total of 20 MNID types, whereas they
could all be collapsed into one MNID type.

The negatives I see are:

Some URN schemes do not have a unique representation as a character
string.  In practice, this is combated by either (1) Code that handles
URNs of arbitrary namespace copies and compares them as character
strings.  Users of such systems know to write URNs that have multiple
representations in a canonical form.  Or, (2) Code that handles one or a
small fixed set of URN namespaces knows the canonicalization/comparison
rules for those namespaces.  Generally, using these processes doesn't
cause problems in practice.  I expect that whatever receives the MNID
and looks it up in appropriate databases would not be a constrained
device, so it could process URNs carefully.

If the link layer is constrained, longer identifiers may require
fragmentation.  Changing a 96-bit binary representation into a URN seems
to add something like 40 octets, given the examples I've found online.
OTOH, it seems that the MNID is only transmitted when attaching to a
network, and so having that one packet require extra work doesn't seem
to be much of a penalty.

The all-URN ides envisions embedding IMSI and possibly MSISDN into the
gsma URN namespace.  (IMEI is already embedded as urn:gsma:imei:...)
That would take additional specification, although I don't see that
being controversial.  (Andrew Allen <[email-masked]> would be a
good contact for doing this.)

> from, because I don't think I was the person who crafted it.

I suspect this is really an editorial mistake, but I had to treat it as
technical because I couldn't rule out that it was a design question.

> > MNIDs seems to be contrary to the philosophy of DUID construction (RFC
> > 3315 section 9):
> >
> >     Clients and servers MUST treat DUIDs as opaque values and MUST only
> >     DUIDs to the types defined in this document, as additional DUID types
> > both mobile identification, and we don't want mobile identification to

Give that there has been only 4 types of DUID defined in 13 years, I
don't expect much need for extensibility, but it seems to me that if
devices take their MNID from their platform's DHCP implementation,
there is a risk that the protocol will fail if someone uses a
proprietary/experimental DUID type.

> O.K. with your modification.  The document just defines numbers for the 

True...  So really "Additional Identifier Type Numbers are defined for
use ..."

> > --
> >
> >     For each RFID scheme except GID, there are two variations: a 64-bit
> >     scheme (for example, SGLN-64) and a 96-bit scheme (SGLN-96).  GID has
> >     only a 96-bit scheme.  Within each scheme, an EPC identifier can be

That's close, but it doesn't assert the representations for GID.
Better:

    For each RFID there are three representations:
     - a 64-bit binary representation (for example, SGLN-64)
       (except for GID)
     - a 96-bit binary representation (SGLN-96).
     - a representation as a URI (a URN, actually)

(Though all of this discussion can be removed of the binary
representations are removed in favor of the URN representation.)

> document.  Do you think that is necessary?

We do want to stay aligned with EPC, otherwise there would be chaos.
And technically, all URNs are URIs.  But approaching the subject from
the IETF, it makes a lot more sense that RFID schemes are represented as
URNs rather than general URIs.  It seems to me to be quite sufficient to
notify the reader in some appropriate place that these URIs are URNs.
See the last line of the text I suggested above for one way to do it.

> standards already in place from the external SDOs.

Oh, yes, we don't want to duplicate EPC's work.  I just wanted to know
that you've checked that EPC does define a sequence of octets, rather
than only a sequence of *bits*, which would leave the ordering of the
bits within the octets unspecified.

> the defining documents for the identifier types will be enough to 

OK, I can agree with you there.  The only identifier which doesn't seem
to have a "natural" ownership scheme is IPv6 addresses; I think of IPv6
addressed as being assigned to a device every time it is initialized,
rather than being a way to identify the device.  But you address that in
the item below.

> this to be an address for future assignment.  I'll try to make that 

OK, if that's the case, then the usage is clear, as is how the device
obtains ownership of an address.

> make further clarification according to your suggestion.

It's likely that in the context of the IMSI spec that "network order"
means high-to-low for all sizes quantities, but I've not seen that used
in IETF context, so it's probably worth clarifying just to be thorough.

> more than happy to delete the text.

OK, if people have asked for descriptions, I can see the value in that.
But you might want to check that your phrasing makes sense to someone
who isn't already familiar with the EPC schemes.

> >     Moreover, MNIDs containing sensitive identifiers might only be used
> >     update exchanges might then rely on a temporary identifier allocated
> >     standardized within the IETF.  Managing the association between long-

I'd definitely prefer some other term than "might".  I'm not sure why,
but I think that it's because "might" isn't used much in specifications

If the external documents show how MNIDs will be used, and if that
context shows why the security problems are small, then I'd definitely
reference them.

One point that is not clear to me.  The above quoted paragraph suggests
that MNIDs are only transmitted during initial network entry.  But
reading it again, I'm led to guess that they are currently also used for
"binding update exchanges".  And you are suggesting that their use in
binding update exchanges could be eliminated by using temporary
identifiers?

If the first case is true, you can make the statement more definitive
as simply:

     Currently, MNIDs are only be used for signaling during initial
     network entry. [external reference]

If the second case is true, you want to make it clearer that the current
risks are (slightly) higher:

     Currently, MNIDs are only be used for signaling during initial
     network entry and binding update exchanges. [external reference]
     Future work could ensure that MNIDs are only be used for signaling
     during initial network entry by having subsequent binding update
     exchanges rely on a temporary identifier allocated during the
     initial network entry, perhaps using mechanisms not standardized
     within the IETF.  [perhaps delete that last phrase as not really
     adding anything?]  Managing the association between long-lived and
     temporary identifiers is outside the scope of this document.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 13 Feb 2017 11:55:48 -0500

"Sri Gundavelli (sgundave)" <[email-masked]> writes:
> When we discussed this issue in the past, the general feedback from
> the WG was that the draft should provide some minimal amount of
> details on the new identifier types, what the identifier is, how the
> identifier is constructed, what is the access technology and a
> reference to the specification that provides that definition. The idea
> is NOT TO provide extensive details on the spec, but to enable a
> reader with some high level details and a pointer to the
> specification. I tend to think the text in the current specification
> just does that. If the text is seen as redundant text, we can
> certainly add a statement saying that the definition for the
> identifier is provided in spec-XYZ and is repeated here for
> convenience. May be other folks in the WG have some views on this.

I take it that the following are typical comments from the WG:

> "Some text on the motivation for defining new Types may be
> helpful. Document is not just standardizing the currently
> in-use/popular identifier types, its also introducing new types are
> not in use. The reasons/interest for defining identifiers that are
> tied to the physical elements of the device (RFID, MAC address ..etc)
> and how it helps in deployment of the technology may be useful. Few
> lines of text will really help."
>
> "I was hoping to see a sub-section for each of the types. We cannot
> standardize a identifier type without providing any explanation on the
> identifier type or the references to the base definitions. This can be
> painful, but I'd have a small section for each of the types. It can be
> 3 line text on the a.) Definition b.) Format c.) Example format d.)
> Reference to the base spec that defines those identifiers."

I can understand these desires, and I agree with following them.

In regard to the first message, it seems to request "The
reasons/interest for defining identifiers that are tied to the physical
elements of the device (RFID, MAC address ..etc) and how it helps in
deployment of the technology may be useful."  As far as I can tell, this
isn't handled in section 4.9 (which is the part I was complaining
about).  And I don't recall if the earlier parts of the draft are
specific about "the reasons/interest" for any of the new types.  I
believe from this discussion that the reason an identifier was included
is that somebody told the authors that they wanted to use the identifier
in question -- and that is quite legitimate.  Perhaps saying it
explicitly in the early parts of the draft would help.

In regard to the second message, it seems to request

    a small section for each of the types. It can be
    3 line text on the
	a.) Definition
	b.) Format
	c.) Example format
	d.) Reference to the base spec that defines those identifiers.

Of course, (d) "reference to base spec" is necessary, and the
sub-sections of 4.9 do that for each format, as does Table 1.

For (a) "definition", the texts in 4.9 proper seem to be fairly good.
E.g.,

   The EPC encoding scheme for SGTIN permits the direct embedding of
   EAN.UCC System standard GTIN and Serial Number codes on EPC tags.  In
   all cases, the check digit is not encoded.  Two encoding schemes are
   specified, SGTIN-64 (64 bits) and SGTIN-96 (96 bits).

Based on that alone, I couldn't possibly construct a SGTIN-64 myself,
but I have some idea of the information it contains and the technical
terms to look up to find the real definition of the data items.

However (b) "format" seems to be missing (except in the most abstract
sense) and (c) "example format" seem to be missing entirely.  OTOH, I'm
not sure that the space needed to specify those would be worth the
effort.

Summary:  After thinking about it more, I think it's not worth the
effort to revise 4.9 heavily.  Most of that information is for the use
of people who are familiar with the RFID identifiers and their formats,
and if they are happy with it, there's no reason to change it.

Dale

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 13 Feb 2017 21:19:27 -0800

Hello Dale,

Follow-up below...

> good contact for doing this.)

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.

> ....

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.

Regards,
Charlie P.

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 14 Feb 2017 20:04:19 -0500

> 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?

> a security standpoint, without meaning to go into examples.

Certainly the new text is clear enough.

Dale

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 15 Feb 2017 16:50:35 +0000

HI Dale,

Thanks again for the comments. Please see inline.

>not sure that the space needed to specify those would be worth the

[Sri] I agree. The goal was to make the spec complete. What ever
identifiers we are carrying in this option, we provide the format,
structure and semantics of construction and not treat it like an opaque
container. But, its a delicate balance, not ending up with a lot of
duplicated text, vs incomplete specification. I agree, its not worth the
efforts doing a significant re-write. The current text is probably fine.

>and if they are happy with it, there's no reason to change it.

[Sri] I agree with your summary.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 15 Feb 2017 16:12:04 -0800

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.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Feb 2017 14:25:05 +0200

Dale:

Many thanks for this review, which indeed was exceptionally useful. (“Super” as Charlie put it.)

I have placed a no-objection position for this document for tonight’s IESG telechat. But I think your discussion on the details of changes inspired by Dale’s review probably needs to continue, and I also see that there are other points made by my AD colleagues — that is another discussion that needs to finish.

Jari