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

From: Raja Narayanan <[email-masked]>
Date: Tue, 14 Dec 1999 13:49:14 -0800

Charlie,

Leaving the reserved bits aside for the moment, am I
right is gathering from your last posting that you
have no problems with making MIER extension format
binding on _all_ future extensions for Mobile IP.

I hope you agree with me that not having such a
requirement would defeat the very purpose of the
draft.

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

The fact that we cannot aniticipate all of them is
also exactly the reason why we would like to leave it
open for _future_ standardization.

After all, if the original mobile IP extension had
some reserved bits, then we could have easily used
them today for subtypes today -- could we not ? It is
a question of simply whether you want to design _just
for today_ or prudently leave some room for some
expansion.

--Raja

ps: Apologize for having to use a diff email account.
Am having difficulty in using my work email at the
moment.

__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

---

From: "D. Reese/C. Perkins" <[email-masked]>
Date: Tue, 14 Dec 1999 20:17:05 -0800

Hello Raja,

> binding on _all_ future extensions for Mobile IP.

I do not think this restriction is necessary.  I am not in favor
of making this restriction.  I think that future extensions may
well be defined that would not fit within the MIER framework.

> requirement would defeat the very purpose of the

Why is this?  Why shouldn't we allow future use of the
other type numbers for extension formats that are not
easily described by the layouts given in MIER?

> open for _future_ standardization.

You can leave it open for future standardization by using
different types better than by leaving reserved flag bits.

> for today_ or prudently leave some room for some

My suggestion does not qualify as designing only just
for today.  I already said that one could design several
extensions, some with more or less (or zero) flag bits.
We can use a few extensions for this purpose.

I do not think this has to be so hard!

Regards,
Charlie P.