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

Joel,

> Ole, it is true that we write in English, and there is always room for
> "interpretation", sometimes reasoanble room, sometimes not.
>
> But in this case we have a demonstrated difference in how people
> understand the existing text.  When we have such a demonstrated
> difference, we have an obligation to address it.
This particular issue has caused no interoperability issue, and only a single 
question to the working group 20 years ago.
The current debate has been caused by a set of new proposals, independently of 
2460, where the authors have in a creative reading of the current text figured 
out that they can shoe-horn header insertion in without actually violating the 
specification. Now, if clarifying the text was done, then I presume these 
proposals would just adapt to update 2460bis instead. The real battle would in 
any case have to be over those documents, not this one.

Now for the snarkiness; an issue that has created real problems is both IETF 
specifications (although experimental) and implementations of address rewriting 
by intermediate boxes. And there isn't a explicit ban on address rewriting in 
2460. Should we add that? Would it help?

> PS: The ability to do ECMP is why I helped with and supported the effort to 
> get the flow label use for ECMP entropy documented.  That would ameliorate a 
> number of problems.  I do not expect this revision of 2460 to fix that, 
> particularly since there seems to be little adoption.  I try not to get 
> distracted looking for perfection.
Yes, and that's greatly appreciated!

Best regards,
Ole

signature.asc
Description: Message signed with OpenPGP