On 17  Nov 2010, at 19:09 , Hagen Paul Pfeifer wrote:
> But what is the main cause to reject this I-D?

I am very very sorry, but if the issues aren't clear by now, 
with so many explanations from so many people, then I really 
don't know how to help one understand.

> There are no real disadvantage...

Untrue, see list discussion for several issues.

To pick an arbitrary note from earlier today, see Joel H's 
note about how the current I-D violates RFC-2460...

> and no overhead but opens the possibility to use the vanilla
> extension header mechanism.

We already have vanilla mechanisms in the IPv6 Destination
Options and IPv6 Hop-by-Hop Options headers.  We should 
use them.

I've already said that if folks want to define a header
for the entirely theoretical case that a new extension 
has NEITHER the Hop-by-Hop NOR the end-to-end property, 
then that proposed header and specification needs to be 
extremely narrowly scoped -- and that specification 
MUST require use of the existing two headers 
if they can *in any way* be used instead.

(I really hope we can stop looping, and instead move on
to discuss what a path forward might look like. :-)

Yours,

Ran


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to