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.
Yours,
Joel
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.
On 2/14/17 1:59 PM, otroan(_at_)employees(_dot_)org wrote:
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