Subject: Re: [MOBILE-IP] MIER V01

From: Raja Narayanan <[email-masked]>
Date: Wed, 8 Dec 1999 13:03:22 -0600

Pat,

Your comments prefix PC>
My response prefixed RN>

--Raja

>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

PC> This, IMHO, is not great protocol design. It sounds like a recipe for
disaster.

RN> I disagree. Having flags in a protocol headers is standard design
practise.

PC> If something is encrypted, then let's find a real way to encrypt,
and not rely on some bit-field in the MIER header. The problem here is
how would one encrypt a non-MIER extension? I, for one, don't want two
encryption routines, one for MIER and one for non-MIER extensions.

RN> Remember the bit field _only_ indicates encryption. The rest of the
secruity information would follow in the payload. In anycase, using a flag
bit for encryption was JUST an example -- I should have known better than to
use encryption as an example.

PC> As for vendor specific information, then let that appear in a vendor
specific extension, this sounds like it should be out of scope.

PC> Then the last example, of an extension that must be processed in a
specific way, this sounds like a new extension to me.

PC> Let's not overload MIER, please. We have an opportunity to make a very
simple draft, let's do it.

RN> ok. I quite don't understand why there is so much difficulty in finding
traction with a simple concept that has often been used. I think having any
placeholder for the future use seems to a logical thing to do. As I said
before, we are open to WG sentiments. I would like to see other opinions on
this.

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

PC> How about zero?

RN> hmmm... not very useful I would think.

PC> PatC

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