Subject: draft-dupont-destoptupd-00.txt

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 20 Nov 2000 09:40:31 -0800 (PST)

Francis,

In section 4, you tried giving names to the various option
headers and i think it can be a bit more clearer. How about
the following :

1) The option header before routing header (called as
   destination options (1) in rfc2460) can be called
   as routing option header as this appears only with
   routing header.

2) The new place that occurs between routing header and
   fragment header can be called as Intermediate option
   header.

3) The final one that appears after IPsec can be called
   as Destination option header.

They all can have different types assigned by IANA to
keep it simple.

In section (5), you have argued that mutable options
existing after the routing header does not make sense.
But with tunnel encapsulation limit present in the
intrmediate position, the limit needs change as it
passes through tunnels. So, it is mutable. Could
you clarify ?

-mohan
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Fri, 24 Nov 2000 15:21:24 +0100

In your previous mail you wrote:

   
=> I am afraid that people will be confused by routing header
and routing option header names.

=> I'd like to keep the destionation option header name and
(more important) type for this.

=> 3) options are mobility new options (others are 2), there is
no defined 1) option) then a new type for this will minimize the
impact on interoperability.

=> this is the important point. Implementors at the ETSI bake-off
*required* this.

=> yes, the argument is nobody should change them...

=> tunnel encapsulation limit is not mutable, the option is copied
and the limit decremented in the new encapsulation stuff, the old
option is kept as it until it is decapsulated.
This option is not commonly used because most implementors don't want
to chase for it in all packets (this is an expensive operation,
and in some cases impossible). But this option is still a good
solution to a very common configuration error and I'd like to
make this alive again...

Thanks

[email-masked]