Subject: Re: [MOBILE-IP] MIER V01 [actually V02]

From: Raja Narayanan <[email-masked]>
Date: Tue, 14 Dec 1999 11:34:31 -0600

Hello Charlie,

My comments prefixed by RN >>
thanks,

--Raja

----------------------------------------------------------------------------
----------------------------------------------------

The test of naturalness will be in how many extensions are handled
well by MIER.  But no matter how good MIER is, I can't believe that
it would be appropriate for ALL future extensions.

RN >> Why would it not be approrpiate for ALL future extensions ? After all
the intent of creating subtypes is to make sure that future extensions that
are similar to [or variations of the theme if you will] a new extension
being
defined, do not eat up type space.

> 3. If MIER is accepted by the WG, then _all_ future extensions will be
>    defined according to the MIER style.  So all new extensions, regardless
>    of whether they have subtypes or not, will be able to use any flags
>    defined by MIER.

Accodring to my above idea, I am not in agreement with this statement.
Maybe the authors could clarify their intention.  This should also be
understood before the draft is taken as a working group item.

RN >> The intention of the authors was exactly as stated in 3. above except
for the fact that the precise use of flags have been left open for future
standardization
efforts. We are in some ways defeating the purpose of the draft if all
future
extensions are not defined in MIER style. I am very interested in rationale
behind why they should not be ?

> Having said that, the only example of item 1 above I know so far is the
> optional inclusion of an SPI in the case of the Generic NAI extension.
> (This is to support the possibility of doing some security enhancement on
> the NAI -- including, but not limited to, "encryption").

Until the flag handling is understood better, I'd be more in favor
of just defining a new subtype for encryption variations, and leaving
the entire 8 bits for the subtype range.  Or, alternatively, we could
have the following:
1. Type A, no flag bits, 256 subtypes
2. Type B, 1 flag bit, 128 subtypes
3. Type C, 2 flag bits, 64 subtypes
4. Type D, 3 flag bits, 32 subtypes

RN >> There you go.... what has been defined above is _one_  potential
good use of the 'reserved' space. It is best to leave the use of 'reserved'
space
for future standadization efforts by WG members and not let it hold up MIER.

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 14 Dec 1999 10:23:01 -0800

> Raja Narayanan wrote:
        [..]

[charlie wrote..]
> for future standadization efforts by WG members and not let it hold up MIER.

MIER could be simplified further by removing the 'rsv' and 'ST'
semantics entirely from the additional octet. Treat this octet
as the LSByte of a new 16 bit 'extended type' field (with the existing
Type field the MSByte). Leave the type/subtype/flag breakdown to later
WG standardization efforts.

This way you can get two important things immediately - expanded
'type' space, and the longer length field - without having to also
nail down the boundaries within this new 16 bit type.

cheers,
gja
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 14 Dec 1999 11:04:13 -0800

Hello Raja,

Thanks for your note.

> == me

> it would be appropriate for ALL future extensions.

RN == Raja

> RN >> Why would it not be approrpiate for ALL future extensions ?
>       After all the intent of creating subtypes is to make sure that
>       future extensions that are similar to [or variations of the
>       theme if you will] a new extension being defined, do not eat
>       up type space.

What's the point of having type space, if there aren't any future
extensions that could use it?

>> == Asokan

>> 3. If MIER is accepted by the WG, then _all_ future extensions will
>>    be defined according to the MIER style.  So all new extensions,
>>    regardless of whether they have subtypes or not, will be able to
>>    use any flags defined by MIER.

> == me

> According to my above idea, I am not in agreement with this statement.
>
> RN >> The intention of the authors was exactly as stated in 3. above
>       except for the fact that the precise use of flags have been left
>       open for future standardization efforts. We are in some ways
>       defeating the purpose of the draft if all future extensions are
>       not defined in MIER style. I am very interested in rationale
>       behind why they should not be?

I'd suggest instead that the scope of the MIER draft be limited to the
things we can understand about today, and that future extensions be
_allowed_ to do crazy things like have a 16-bit subtype field or
a 2-bit length field if someone finally knows that such an idea
absitively is the coolest thing since sliced tomatoes.

Furthermore, I do not see any downside in eliminating this restriction.

>       good use of the 'reserved' space. It is best to leave the use of
>       'reserved' space for future standadization efforts by WG members
>       and not let it hold up MIER.

Exactly.  It's _one_ potential use.  There might be others.  And, there
is no way you can anticipate all of them with a single extension now.
And you can't be sure that all future developers could live comfortably
with the remaining subtype space if you use some of it for flags.

Regards,
Charlie P.