I want to reinforce this.
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.
o We could say "MUST NOT unless some other standards track RFC says it
is okay" which is technically correct but confusing.
o We can say "SHOULD NOT unless ..." as long as we can write a clear
description of the conditions under which it is safe.
o We can say "AMY< but note that doing so has the following risks" if
that is the IETF rough consensus.
But leaving it ambiguous ought to be a non-starter.
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.
Yours,
Joel
On 2/11/17 2:24 PM, Brian E Carpenter wrote:
On 12/02/2017 01:36, otroan(_at_)employees(_dot_)org wrote:
Brian,
If people who were not involved in the 6man debate have opinions, it
would be useful to hear from them. I agree that there is no point in
the same people repeating the same arguments.
in the absence of a (somewhat unbiased) summary of the critical
issues(s), what do you suggest?
I was going to say this off list, but what the heck?
To be honest I'm trying to stay quiet. I think I've made my opinion
plain, and although I am of course the only human being alive who doesn't
suffer from confirmation bias, I'd *really* like to hear what people
think whose opinion I haven't already heard 20 times.
I try not to be a purist. If the right answer is to allow packet
modifications that break PMTUD and IPsec/AH, let's do it, but let's
also say we're doing it. (I happen to think it's the wrong answer,
but that's my problem.) Leaving the text open to interpretation
would make a mockery of promoting it to Standard.
This is really not the discussion we ought to be having.
"Allowing" or in any way specifying how header insertion could possibly be made
to work is far outside of the scope of advancing 2460 to Internet standard.
If so, how can it be OK to leave the text ambiguous?
Brian