Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx 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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]