Subject: [MEXT] [Fwd: New Version Notification for draft-perkins-mext-4283mnids-00]

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 19 Oct 2009 13:32:35 -0700

Hello folks,

This is a very simple draft, but could make a significant
difference in ease of standardization.  Anyway it would
avoid the need to shoehorn every possible type of identifier
into a new substructure for the MN-NAI.

Any comments will be appreciated.

Regards,
Charlie P.

-------- Original Message --------
Subject: New Version Notification for draft-perkins-mext-4283mnids-00
Date: Mon, 19 Oct 2009 13:20:49 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked]

A new version of I-D, draft-perkins-mext-4283mnids-00.txt has been 
successfuly submitted by Charles Perkins and posted to the IETF repository.

Filename:	 draft-perkins-mext-4283mnids
Revision:	 00
Title:		 MN Identifier Types for RFC 4283 Mobile Node Identifier Option
Creation_date:	 2009-10-19
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
Additional Identifier Types are proposed for use with the Mobile Node
Identifier Option for MIPv6 (RFC 4283).

The IETF Secretariat.

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 20 Oct 2009 09:08:25 -0700

Hello Charlie,

Two comments on this draft:

I'm wondering how useful it is to reserve a MNID type to encode a 3GPP IMSI [1] given that EAP-AKA [RFC4187] and the 3GPP Numbering, addressing and identification specification [TS23.003] already define means of encoding the IMSI as an NAI.

Also, w.r.t. P-TMSI and GUTI, 1) it's unclear to me whether these identifiers are going to be used to identify a MN with its HA or LMA, and 2) if it's going to be used, why not let 3GPP define in [TS23.003] their own mapping of P-TMSI, GUTI, or whatever identifier they're using, into a NAI?

Best,

--julien

[RFC4187]  Extensible Authentication Protocol Method for 3rd Generation
           Authentication and Key Agreement (EAP-AKA)
[TS23.003] 3rd Generation Partnership Project, "3GPP Technical
           Specification 23.003: Technical Specification Group Core
           Network and Terminals; Numbering, addressing and identification"

Charles E. Perkins wrote:
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 20 Oct 2009 09:34:51 -0700

Hello Julien,

Your comment actually applies to every type of
identifier.  Even MAC addresses could be written
as NAIs:
	[email-masked]
Or:
	[email-masked]
depending on preferneces for AAA administration.

I'd give 5 to 1 odds that the use of NAI as you
mentioned by 3GPP and others was predicated on
the restriction that it was the only choice
available.

It seems to me that, going into the future, we
can do better.  And there is absolutely no pressure
evident today on the MNID type registry.

Nearer term, I think the availability of appropriate
MNID types might be valuable for the work that is
ongoing for an alternate security mechanism for
MIPv6.

Regards,
Charlie P.

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 20 Oct 2009 09:45:42 -0700

The IANA considerations of RFC 4283 states:

   In addition, IANA has created a new namespace for the subtype field
   of the Mobile Node Identifier option.  The currently allocated values
   are as follows:

   NAI (defined in [RFC4282]).

   New values for this namespace can be allocated using Standards Action
   [RFC2434].
 
So I do not see what restriction made encoding the IMSI as an NAI the only choice available. If 3GPP had wanted to encode an MNID subtype to encode the IMSI, they could have get it allocated via the appropriate channel.
 
As to the lack of pressure on the MNID subtype registry, it is not IMHO a reason to reserve values before a clear requirement has been expressed, which doesn't seem to be the case yet. Until then...

--julien

Charles E. Perkins
> > I'm wondering how useful it is to reserve a MNID type to encode a
> 3GPP IMSI [1] given that EAP-AKA [RFC4187] and the 3GPP Numbering,
> addressing and identification specification [TS23.003] already define
> means of encoding the IMSI as an NAI.
> >
> > Also, w.r.t. P-TMSI and GUTI, 1) it's unclear to me whether these
> identifiers are going to be used to identify a MN with its HA or LMA,
> and 2) if it's going to be used, why not let 3GPP define in [TS23.003]
> their own mapping of P-TMSI, GUTI, or whatever identifier they're using,
> into a NAI?
> >
> > Best,
> >
> > --julien
> >

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 20 Oct 2009 10:06:01 -0700

Hello Julien,

Well, if I were a 3GPP standardization representative,
and I had the choices of (a) submitting yet another
standards document to an external SDO and attending
3 _more_ meetings per year at the additional cost of
months and many thousands of dollars or (b) encoding
my identifier as an NAI, I think the choice would be
obvious.

Of course, both choices are "available".

Regarding:

>  As to the lack of pressure on the MNID subtype registry, it
>  is not IMHO a reason to reserve values

of course we agree.  But I was responding to your
earlier suggestion about whether it was advisable
to use the type space.

Regarding:

> it is not IMHO a reason to reserve values before a clear
> requirement has been expressed, which doesn't seem to be
> the case yet.

As pointed out above, I think that as long as the identifiers
of the appropriate type cannot be easily used, we will
continue to see creative applications of the only identifier
type that _is_ easily able to be used -- namely, the NAI.

Regards,
Charlie P.

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 20 Oct 2009 10:11:46 -0700

Hello Charlie,

With my initial comment I meant I wasn't sure 3GPP is interested in using a new MNID subtype for IMSI.

In my view having a MNID subtype reserved for IMSI it is as simple as 1) writing a draft (which you did) and 2) having 3GPP reference that draft so that here in the IETF it's clear what their intent is and we can move forward and get the draft published as an RFC. 

Hope that clarifies.

--julien

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Tuesday, October 20, 2009 10:06 AM
> To: Laganier, Julien
> Cc: mext
> Subject: Re: [MEXT] [Fwd: New Version Notification for draft-perkins-
> mext-4283mnids-00]
> 
> 
> Hello Julien,
> 
> > So I do not see what restriction made encoding the IMSI as an NAI the
> only choice available. If 3GPP had wanted to encode an MNID subtype to
> encode the IMSI, they could have get it allocated via the appropriate
> channel.
> >
> > As to the lack of pressure on the MNID subtype registry, it is not
> IMHO a reason to reserve values before a clear requirement has been
> expressed, which doesn't seem to be the case yet. Until then...
> >
> > --julien
> >
> > Charles E. Perkins
> >> Hello Julien,
> >>
> >>>> Subject: New Version Notification for draft-perkins-mext-
> 4283mnids-
> >> 00