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

From: Phil Roberts <[email-masked]>
Date: Thu, 23 Aug 2001 16:34:11 -0400

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.