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

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 18 Sep 2001 10:34:33 -0700

Hello folks,

Here are some responses to the comments below about MIER, encountered
along the way towards integrating MIER into RFC2002bis.

The revised document (draft-ietf-mobileip-rfc2002-bis-08.txt)
is available at:
	http://people.nokia.net/charliep/txt/mobileip/mobileip.txt

> --------------------
> 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.

Since I was asked to integrate MIER into RFC2002bis, I reckon
that the second alternative was selected.

> 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.

Here is the related paragraph in the new section 1.8:

   Unless additional structure is utilized for the extension types,
   new developments or additions to Mobile IP might require so many
   new extensions that the available space for extension types might
   run out.  Two new extension structures are proposed to solve this
   problem.  Certain types of extensions can be aggregated, using
   subtypes to identify the precise extension, for example as has been
   done with the Generic Authentication Keys extensions [35].  In many
   cases, this may reduce the rate of allocation for new values of the
   type field.

>>     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.

Even though there are millions of Mobile IPv4 implementations out
there, the general feeling in the working group (and outside the
working group, I believe) is that Mobile IP is still in its infancy.
Of course if Mobile IPv6 fills the Internet need for seamless
mobility, then Mobile IPv4 may not grow as much as it would if
IPv4 maintains dominance.  Anyway, there is a realistic and
reasonable chance that Mobile IPv4 could grow quite a bit more.

Furthermore, since MIER passed working group Last Call, the
inference could be taken that the people involved with creating
new extensions decided that it was better to specify a useful
type/subtype template sooner rather than later.

Lastly, I should mention that I'm not exactly the right person
to be supplying these answers.  I didn't write MIER, and I didn't
participate much in the discussion after the first few months
where we talked about flags.  Even so, in the interest of getting
some progress for RFC2002bis (which now has to include MIER),
I try to provide my best understanding of the technical
reasoning for creating MIER.  Someone else with more involvement
might easily be able to correct any misstatements I might have
made.

>> 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?

I think MIER was created in response to a perceived future
shortage, not in response to any existing current problem.

>>     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".

I hope the abovementioned paragraph from the new section 1.8
is O.K. for this.

>> 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.

Fixed, I think.

>> 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.

There are already proposals for long options that could
reasonable be expected to use a MIER-ified extension layout.
For instance, the Registration Keys draft could do so.

>> 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.

O.K.  Unless there is an objection, I will remove this sentence
about reserving values.  I agree it's better to leave this for
each specfic option.

Regards,
Charlie P.