Subject: [mobile-ip] Last Call: Generalized NAI (GNAIE) Extension to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 20 Jul 2001 12:04:51 -0400

The IESG has received a request from the IP Routing for Wireless/Mobile
Hosts Working Group to consider Generalized NAI (GNAIE) Extension
<draft-ietf-mobileip-gnaie-04.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by August 17, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-04.txt

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 25 Jul 2001 07:39:33 -0700

It was removed because it conflicted with the MN NAI defined in RFC 2794.
So, instead of introducing multiple ways to encode the same thing, and
end up with possible interoperability problems, we decided to eliminate
the subtype. Perhaps one day a mobile will have a different type of
identity to add (e.g. old foreign agent's NAI), so the sentence is still
valid.

PatC

On Wed, Jul 25, 2001 at 02:15:41PM +0200, Fredrik Johansson wrote:
> In sectin 3.0, subtypes are defined.
> 
> 1. Is there a reason to why the MN_NAI has been removed as a subtype?
> 2. If there is no MN_NAI subtype, the sentence
> "When a mobile node or home agent adds a GNAI extension to a
>       registration message, the extension MUST appear prior to any
>       authentication extensions."
> doesn't make sence. Why should a mobile node add a GNAI with a subtype of
> the FA or HA?
> 
> I suggest that the MN_NAI subtype be added again.
> 
> "Sub-Type
> 
>       This field describes the type of the entity which owns the NAI.
>       The following subtypes are defined:
> 
>          1    HA_NAI
>          2    FA_NAI
> 
>       When a mobile node or home agent adds a GNAI extension to a
>       registration message, the extension MUST appear prior to any
>       authentication extensions."
> 
> /Fredrik
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]On Behalf
> >Of The IESG
> >Sent: den 20 juli 2001 18:05
> >To: IETF-Announce:
> >Cc: [email-masked]
> >Subject: Last Call: Generalized NAI (GNAIE) Extension to Proposed
> >Standard
> >
> >
> >

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 25 Jul 2001 14:15:41 +0200

"Sub-Type

         1    HA_NAI
         2    FA_NAI

/Fredrik

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 26 Jul 2001 14:38:16 +0200

Ok, sounds good to me.
Can't believe that I didn't think of the mobile sending the previous FA nai.

Just for my own curiosity, what are the rules to obsolete a rfc by another?
e.g. to obsolete rfc 2794 and use the GNAI for all nai extensions?

/Fredrik

>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Pat Calhoun
>Sent: den 25 juli 2001 16:40
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [mobile-ip] RE: Last Call: Generalized NAI (GNAIE)
>Extension to Proposed Standard
>
>

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 26 Jul 2001 12:41:20 -0700

> Can't believe that I didn't think of the mobile sending the previous FA nai.

good.

> e.g. to obsolete rfc 2794 and use the GNAI for all nai extensions?

An RFC that obsoletes another states in its header the RFCs that it 
obsoletes. Take a look at RFC 2865 for an example. When submitting an RFC
to the IESG, one has to state that it will be obsoleting another RFC. 
However, we don't just obsolete RFCs for fun. Typically it is done when
an RFC moves from PS to DS, or when a crucial fix was made and the older
RFC is no longer relevant.

In this particular case, obsoleting RFC 2794, when folks just started
shipping products supporting it, would be a very bad thing (TM).

PatC