Subject: Re: [MOBILE-IP] MIER V01

From: Raja Narayanan <[email-masked]>
Date: Wed, 8 Dec 1999 10:47:24 -0600

Hello Pat,

o.k., let me try and outline what we are after with some examples:-

Let us say extension type=102 is NAIs.
Sub types could be something like
0     MN-NAI
1     FA-NAI
2     HA-NAI
3     Previous FA-NAI Extension
...etc

At some point we could standardise use the flags to further qualify the
type, sub type tuple:-
[the following are purely examples at this point in time and not a part of
the current MIER draft]
If flag 0 is set then the extension MUST be processed in a specific way
If flag 1 is set then the extension is encrypted
If flag 2 is set then the extension has some vendor specific information
etc.
..etc

Use of flags MUST be defined and standarised for each type, subtype tuple
before future use.

Agreed that we do know a priori what type =102 and subtype =1 is... however
the use of the bit field gives some additional flexibility in further
qualifying it. Maybe reserving 4 bits is too much & we should consider 2.

Anyone else in the WG have any opinion ?

--Raja

-----Original Message-----
From: Patrice Calhoun [mailto:[email-masked]]
Sent: Tuesday, December 07, 1999 4:05 PM
To: [email-masked]
Subject: Re: [MOBILE-IP] MIER V01

>Hello,
>
>Responses prefixed by >>>
>
>--Raja
>
>---------------------------------------------------------------------------
-
>---
>
>All,
>
>Although this draft is better than its predecessor, I REALLY don't like the
>way that the one octet is split up into a sub-type and flags.
>
>I really don't see why a reserved bit field is necessary, and this limits
>the
>number of sub-types to 16.
>
>>>> Well, the reserve bits are a nice way to facilitate some future
>standization efforts for types that have already been used. Surely, we
>REALLY don't have to just address problems that are at the tip of the nose.
>Who knows, at some point someone may choose to add a flag to a type to mean
>something.

This I really don't get. Let us say that a specific extension (101) is for
authentication extensions. So we KNOW a priori what 101 really is.

Then we have another extension (102), which contains NAIs. Well we KNOW a
priori that this contains an NAI because it has a type of 102.

So, I really don't see why a bit field could be used to represent the
object type. I don't think that we are really trying to achieve a self
defining type, right?

>
>>>> Having said that, we are open to the sentiments of the WG. If the
>consensus is that reserve bits are useless then we would be more than happy
>to take it out.
>
>This seems to conflict with the statement in
>the abstract "MIER describes a new extensions structure to Mobile IP to
>make the extensions truly extensible." I think that truly here is a little
>mis-leading since it is not infinitely extensible. We still have a maximum
>number of extensions, and what we now have is 254 * 16, which should
>give us a little longer, but it's hardly "truly extensible".
>
>>>> Our original draft had a general extension which would have made it
>truly extensible. I agree that 'truly' in the context of this version can
be
>reworded. We can reword it or re-introduce the general extension concept
now
>or at a later stage -- which ever the WG desries. Don't agree with the
>comment that 254 * 16 would give us a 'little longer' ... 16 times what we
>have today is non trivial.

I wan't saying that it wasn't enough, simply that truly was too strong a
word.