Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, V

Joel,

> There are two separate but related issues here.  One is what behavior we want 
> to require.  The other is whether we make the document clear.
>
> I think choosing to leave a document going to Internet Standard ambiguous is 
> a serious mistake, bordering on failure.  We know that the choice of 
> permitting insertion of extension headers has interoperability implications.  
> There are weveral ways we can clarify the text.
> o We could say "MUST NOT" be added.  Preferably with explaantion of the 
> problems being avoided.
Yes.

> o We could say "MUST NOT unless some other standards track RFC says it is 
> okay" which is technically correct but confusing.
That's redundant. A new standards RFC can always be written that will override 
this.

> o We can say "SHOULD NOT unless ..." as long as we can write a clear 
> description of the conditions under which it is safe.
As the 6man chair we declared that as out of scope in the context of advancing 
2460 to Internet standard.

> o We can say "AMY< but note that doing so has the following risks" if that is 
> the IETF rough consensus.
Middleboxes live in unregulated territory, there was no support (or even 
suggestion) in the working group for explicitly permitting header insertion.

> But leaving it ambiguous ought to be a non-starter.
Why?
Leaving it as it was, including describing what we would imagine it would break 
was the preferred solution in the working group.
Note that both IPv4 and IPv6 has this so-called ambiguity, that has caused no 
known interoperability issues and has existed for decades.

This is perceived as an ambiguity only because we as a community have accepted 
layer violations for so long.
This can be exemplified by discussions on maximum extension header length in 
IPv6. The only reason that discussion happens is because middleboxes require 
access to the transport header and beyond. In a purist 2460 view a router doing 
5-tuple ECMP is not compliant with the specification. Clarifying that ambiguity 
would probably not make the operational community proud of us.

The only purpose an outright ban would achieve, would be a pre-emptive strike 
against potential future standardisation.

So when you think long enough about it, which choice you pick will unlikely 
have much consequence either way. It has no effect on implementations, it is 
not testable. In the context of 2460 this isn't a debate with many technical 
points.

Which is why the working group could not reach a consensus, and we ended up 
decided it with a poll. Do you prefer your bike shed red, yellow or green. You 
have added a couple of more colours.

> Personally, I would go with "MUST NOT", as I think that is the robust and 
> interoperable answer.  But that is MUCH less important to me than our being 
> unambiguous.
There is an infinite set of creative (ab)uses of 2460 that hasn't been banned. 
I would claim it would be impossible to write a document which would MUST NOT 
every potential abuse.

Best regards,
Ole

signature.asc
Description: Message signed with OpenPGP