Subject: RE: [mobile-ip] FW: draft-ietf-mobileip-mier-07.txt

From: Phil Roberts <[email-masked]>
Date: Tue, 4 Sep 2001 11:30:07 -0400

I've received zero feedback on this.  Let me try another tack.

I propose we integrate this document into 2002bis.  It would allow
us to have a normative reference for all future documents using
extensions, 2002bis will be the primary standards document going forward,
and is in the process of being revised now.

Is the WG okay with this?  Please post comments to the list.

Thanks,
Phil

> -----Original Message-----
> From: Phil Roberts [mailto:[email-masked]]
> Sent: Thursday, August 23, 2001 4:34 PM
> To: [email-masked]'
> Subject: [mobile-ip] FW: draft-ietf-mobileip-mier-07.txt
> 
> 
> Hi folks,
> 
>     we've received this feedback from the IESG on the MIER draft.
> Please provide comments, especially on the first set of options.
> 
> Phil
> 
> 
> --------------------
> General comment. This ID seems to be of rather limited usefulness as a
> standalone RFC. Is it really needed? This document seems to update RFC
> 2002, but is informational. This can be remedied by:
> 
>   - making this standards track (seems overkill, since it doesn't
>     actually define an option, and hence, doesn't define anything
>     anyone needs to implement, from what I can tell)
>   - merge it in with 2002bis (which is being revised right now anyway)
>   - merge this document with GNAI, since the GNAI document is a
>     specific case where use of MIER might make sense. 
>   - take out the MUST/SHOULDs and make it clear that this document is
>     only proposing an approach to encoding options, and that future
>     options writers should consider the issues raised when designing
>     their options. NOte: if this approach is used, other documents
>     (e.g., draft-ietf-mobileip-gnaie-04.txt) shouldn't have normative
>     references to this document. At present, gnai appears to do just
>     that.
> 
> For example:
> 
> > MIER describes a new extension 
> >     structure to Mobile IP to make the extensions far more 
> >     extensible.     
> 
> Could be rewritten as:
> 
>      MIER describes a way of encoding extensions that make it possible
>      to conserve MIP options in some cases. Authors of future options
>      should consider the issues raised in this document when designing
>      new options.
> 
> There are several other places in the document where the langauge
> could be toned down and made more neutral.
>      
> >     It is in the interest of the Mobile IP WG to conserve the 
> >     usage of the type field since we see many drafts proposing 
> >     new extensions for Mobile IP. Therefore there is a real 
> 
> There is an alternate approach, one that seems to be working in
> practice, and has other benefits. Don't allow IANA to assign options
> until there is significant support for an option, i.e, via something
> like "IETF consensus" [RFC 2434].  This approach also has the
> advantage that it discourages the use of many options anyway, a
> generaly desirable feature.  Usage of many options tends to negatively
> impact interoperability.
> 
> Finally, looking at the IANA pages, it does not appear that options
> are being used at a significant rate and that exhaustion of the space
> is serious issue at present.
> 
> 
> > 1.0 Introduction
> > 
> >     The type field in the Mobile IP extension structure can support
> >     upto 255 (skippable and not skippable) uniquely identifiable
> >     extensions. With new developments/additions to Mobile IP
> >     there is a strong possibility that the available space will 
> >     run out.
> 
> What  evidence is there that this is true at present?
> 
> >     Mobile IP Extensions Rationalization (MIER) describes a 
> >     new extension structure to solve this problem. MIER strategy
> >     is to initially aggregate certain types of extensions (e.g,
> >     NAI) and sub types to identify the precise extension (example
> >     MN/User NAI, HA NAI etc). This will greatly reduce the usage
> >     of the type field. 
> 
> Last sentence seems a bit too strong. Better to say "This may reduce
> the usage of the type field in some cases".
> 
> > 2.2 New Mobile IP Extension format
> > 
> >     This draft proposes the following  two structures for Mobile IP
> >     extensions to be carried in the Mobile IP control messages.
> >     Since the new extension structures will cause an efficient
> >     usage of the extension type space, it is strongly recommended
> >     that all the new proposals for the Mobile IP WG that have new 
> >     extensions SHOULD follow this format. 
> 
> SHOULD wording seems a bit strong. Encoding options in this way makes
> sense in *some* cases, but it is not clear (to me) that it does so in
> even the majority of cases. It would be sufficient to say option
> writers should consider whether the structure defined here makes sense
> when a new option is defined. Saying they SHOULD follow it is too
> strong.
> 
> > 2.2.1 Long Extension Format
> 
> In the absence of a specific proposed need for a long option, I don't
> see the value in defining it. Moreover, will MIP *ever* define any
> more non-skippable options? Seems like doing so would be bad for
> interoperating with the installed base (which won't understand any
> newly defined options) . If that is the case, why define now? One can
> always define a long format later should it be deemed necessary.
> 
> > 2.2.2 Short Extension Format
> 
> This format makes sense for some types of options (GNAI would seem to
> be one). It does not make sense for others. For example, of the
> existing MIP options, how many would it actually make sense to encode
> in this fashion?
> 
> >     Sub-Type  is a unique number given to each member in the
> >               aggregated type.  Sub-Type values between of 
> 200 through
> >               255 are reserved for future use and standardization.
> 
> The semantics of this field are dependent on the actual option; it
> make no sense to say anything about reserving values in the general
> case. It *might* make sense to say something like that in the case of
> a specific option, but that would be the job of that specific option.
> 
> If this document is to be published as a standalone document:
> 
> Needs security considerations section.
> 
> Would be good to have an IANA considerations section; I would expect
> it to say "There are no IANA Actions in this document", but that sort
> of depends on resolution of the first point.
>

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 6 Sep 2001 07:32:02 -0700

yes, I'm ok with that.

PatC