Re: [DMM] MNID Types

[Charlie Perkins <[e-mail]>]

Hello Hakima,

I'm putting in the RFID as a selection in the draft.  I have two
questions:

- Do we need to include various types of RFIDs?
- Can you send good citations for the Normative References?

I have 
http://www.acq.osd.mil/log/sci/ait/DoD_Suppliers_Passive_RFID_Info_Guide_v15update.pdf 
but I am not sure if that's the correct normative reference.

Regards,
Charlie P.

On 9/21/2014 8:11 AM, Hakima Chaouchi wrote:
> Hello Folks,
>
> Do you think that considering specific but needed technologies for 
> moving objects in  Internet of Things  such as RFID (Radio Frequency 
> Identifier) with 96 bits identifiers will be also relevent to 
> Charlie's current draft and the efforts related to MNID?
>
> Regards,
>
> Hakima
>
>
> ------------------------------------------------------------------------
> *De: *"Sri Gundavelli (sgundave)" <[e-mail]>
> *À: *"Charlie Perkins" <[e-mail]>, "Marco 
> Liebsch" <[e-mail]>, [e-mail], "Vijay Devarapalli" 
> <[e-mail]>
> *Envoyé: *Jeudi 11 Septembre 2014 23:57:11
> *Objet: *Re: [DMM] MNID Types
>
> Hi Charlie,
>
> Few more reviews/discussions and capturing the consensus in the base 
> version will help. But, I'm ok either way …
>
>
> Regards
> Sri
>
> From: Charlie Perkins <[e-mail] 
> <mailto:[e-mail]>>
> Date: Thursday, September 11, 2014 2:46 PM
> To: Sri Gundavelli <[e-mail] <mailto:[e-mail]>>, 
> Marco Liebsch <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Vijay 
> Devarapalli <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [DMM] MNID Types
>
>
> Hello folks,
>
> I propose to submit the ....-00.txt document as it is to the Internet
> Drafts directory, and then to go about making updates according to
> the discussion on this list.  Do you think this is reasonable?
>
> Regards,
> Charlie P.
>
>
> On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote:
>
>     <Changing the subject line to reflect the MNId discussion>
>
>
>     Marco,
>
>
>     Thinking further on the complementary identifier option.
>
>     - There is already the link-layer identifier option that can be used for
>     carrying the Mac address
>     - IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's
>
>     In some sense, the complementary identifiers are already present.
>
>     Sri
>
>
>
>
>
>     On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)"<[e-mail]>  wrote:
>
>         I do not see a reason why multiple MN-Id instances need to be present in a
>         single message ? In my experience, this is strictly a deployment
>         consideration, when to use what type of identifiers.
>
>         Assuming the backend system can tie all the MN-Id's to a single
>         subscription, any presented identifier can be sufficient for the gateway
>         to do the BCE lookup.
>
>         If multiple instances can be present, then we need to deal with more error
>         cases. Is that really needed ?
>
>
>             I am wondering if it would not be more appropriate to go for a different
>             container option to carry such information. Something like a
>             complementary identifier option.
>
>         Sounds interesting. Are you suggesting we leave the current MN-ID as it
>         is, but use a new complementary option ? But, if the requirement is for a
>         Mac based identifiers, what will be there in the current MN-Id option ? We
>         still need to have identifier there ?
>
>
>
>
>         Sri
>
>
>
>
>
>         On 9/11/14 2:03 AM, "Marco Liebsch"<[e-mail]>  wrote:
>
>             No issue with logical vs. physical ID. But I am wondering about two
>             things:
>
>             Operation is clear to me in case a single MNID is present in a message
>             and I see the value in being
>             flexible to choose from different sub-types. If multiple MNIDs with
>             different sub-types are present in
>             a single message, which one should e.g. the LMA take for the BC lookup..
>             No big problem to solve, but
>             to be considered in implementations.
>
>             If the reason for multiple present MNIDs with different sub-types is to
>             do other things than identifying
>             the node or using the ID as key for a lookup, I am wondering if it would
>             not be more appropriate
>             to go for a different container option to carry such information.
>             Something like a complementary
>             identifier option.
>
>             marco
>
>                 -----Original Message-----
>                 From: Sri Gundavelli (sgundave) [mailto:[e-mail]]
>                 Sent: Donnerstag, 11. September 2014 00:42
>                 To: Charlie Perkins; Marco Liebsch;[e-mail]
>                 Cc: Vijay Devarapalli
>                 Subject: Re: [DMM] regarding the re-chartering..
>
>                 Hello Charlie,
>
>                 Agree with that. MN-Id as its defined today is a logical identifier. It
>                 does not
>                 require the identifier to be bound to a physical device or a interface
>                 identity.
>                 But, we have clearly seen requirements where the need is for generating
>                 identifiers based on some physical identifiers. Those physical
>                 identifiers include
>                 IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
>                 source
>                 and the rules for generating MN-ID based using those sources, the sender
>                 and
>                 receiver will have clear guidance on how to use the spec. Some pointers,
>                 explanation and examples for each of those identifiers will greatly help
>                 avoid
>                 inter-op issues.
>
>
>                 Regards
>                 Sri
>
>
>
>
>
>
>
>                 On 9/10/14 3:21 PM, "Charlie Perkins"<[e-mail]>
>                 wrote:
>
>                     Hello folks,
>
>                     I think it's best to consider the MNID as simply living in a space of
>                     identifiers, and not worry too much about whether it's a logical
>                     identifier or a physical identifier.  If the former, then somewhere
>                     (perhaps below the network layer) the logical identifier has been bound
>                     to something in the physical interface, but that's not our problem.
>
>                     The number space for types of MNIDs is likely to stay pretty empty, so
>                     I'd say we could add as many types as would be convenient for the
>                     software designers.  So, we could conceivably have several MNIDs
>                     defined that all "looked like" NAIs (which, themselves, "look like"
>                     FQDNs).
>
>                     Regards,
>                     Charlie P.
>
>
>
>                     On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:
>
>                         Yes. Currently, the MNID is if the nai format and is overloaded. The
>                         MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
>                         IMSI. Ex:
>                         "<IMSI>@epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org²
>
>                         We also have MAC48@REALM;
>
>                         We also have approaches to transform MAC to Pseudo IMSI, and then
>                         carry IMSI-NAI as the MN-ID.
>
>
>                         So, we need unique sub-types for each of the types/sources.
>
>                         MN-Id based on IMSI, MSISDN, IMEI, MAC ..
>
>                         Also, do we need to distinguish between IMSI and IMSI-NAI ?
>
>                         Sri
>
>
>
>                         On 9/10/14 6:29 AM, "Marco Liebsch"<[e-mail]>  wrote:
>
>                             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.
>
>                             marco
>
>                                 -----Original Message-----
>                                 From: dmm [mailto:[e-mail]] On Behalf Of Sri Gundavelli
>                                 (sgundave)
>                                 Sent: Dienstag, 9. September 2014 23:30
>                                 To: Sri Gundavelli (sgundave); Charlie Perkins;[e-mail]
>                                 Cc: Vijay Devarapalli
>                                 Subject: Re: [DMM] regarding the re-chartering..
>
>                                 Two more comments.
>
>
>
>                                 4.) I'd also use sub-type value of (2) for IMSI. Just to align with
>                                 the  sub-types  defined for MN Id defined for ICMP. I suspect there
>                                 are some  implementations  already using sub-type (2). Please see
>                                 the other thread.
>
>
>                                 5.) For each of the sub-types, we need text including examples and
>                                 some
>                                 explanation on how they are used.
>
>
>                                 Sri
>
>
>
>                                 On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)"<[e-mail]>
>                                 wrote:
>
>                                     Hi Charlie,
>
>                                     This is good. Thanks.
>
>
>                                     1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE
>                                     802.2
>                                     address, why do we need to two sub-types ? Why not have just one
>                                     sub-type for mac based identifiers ?
>
>                                     2.) Sub type value (1) is currently used. Its currently overloaded
>                                     for
>                                     IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
>                                     definition of new sub-types, we need some text explaining the
>                                     motivation
>
>                                     3.) Proposed Sub-type value of (2) for IPv6 address. What exactly
>                                     is
>                                     this ? Are these CGA-based IPv6 addresses ?
>
>
>
>
>                                                           New Mobile Node Identifier Types
>
>                                                     +-----------------+------------------------+
>                                                     | Identifier Type | Identifier Type Number |
>                                                     +-----------------+------------------------+
>                                                     | IPv6 Address    | 2                      |
>                                                     |                 |                        |
>                                                     | IMSI            | 3                      |
>                                                     |                 |                        |
>                                                     | P-TMSI          | 4                      |
>                                                     |                 |                        |
>                                                     | EUI-48 address  | 5                      |
>                                                     |                 |                        |
>                                                     | EUI-64 address  | 6                      |
>                                                     |                 |                        |
>                                                     | GUTI            | 7                      |
>                                                     +-----------------+------------------------+
>
>
>
>
>
>
>
>                                     Regards
>                                     Sri
>                                     PS: Good to see Vijay back
>
>
>                                     On 9/9/14 1:28 PM, "Charlie Perkins"
>                                     <[e-mail]>
>                                     wrote:
>
>                                         Hello folks,
>
>                                         Here's the last Internet Draft that we did, long ago expired:
>
>                                         http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt
>
>                                         I'll resubmit it with a few updates as a personal draft to dmm.
>
>                                         Regards,
>                                         Charlie P.
>
>                                     _______________________________________________
>                                     dmm mailing list
>                                     [e-mail]://www.ietf.org/mailman/listinfo/dmm
>
>                                 _______________________________________________
>                                 dmm mailing list
>                                 [e-mail]://www.ietf.org/mailman/listinfo/dmm
>
>         _______________________________________________
>         dmm mailing list
>         [e-mail]://www.ietf.org/mailman/listinfo/dmm
>
>     _______________________________________________
>     dmm mailing list
>     [e-mail]://www.ietf.org/mailman/listinfo/dmm
>
>
>
> _______________________________________________
> dmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
> -- 
> ---------------------------------
> Hakima Chaouchi
> Professor
> Telecom Sud Paris
> Institut Mines Telecom
> 9 rue Charles Fourier
> 91011 Evry
> 0160764443
>
>
>
> Email secured by Check Point
>