On 2011-05-11 00:38, Ran Atkinson wrote: > Earlier, Brian Carpenter wrote: >> I suggest squaring this circle by retaining the MUST NOT (which IMHO >> is the present consensus) but making it clear in the security >> considerations that there will be exceptions. The problem here is that >> the RFC 2119 language doesn't provide MUST NOT UNLESS..., which is >> what we really need. SHOULD NOT is not perceived as strong enough. > > My understanding is that the "...MUST NOT..., unless ..." language > is acceptable procedurally -- PROVIDED the unless is crisply and > narrowly defined. RFC-2119 does not prohibit that language. > Certainly I understand that language has been used in the past > by this community, albeit not frequently. I've checked with a few > other folks, who have the same view on that language being > acceptable (provided the exceptions are crisply/narrowly defined), > if infrequent, usage. > > I'm quite happy with the compromise you put forward above, > and since the exceptions are quite narrow and precise, > I propose that the I-D(s) use the "MUST NOT ... unless" construct. > > Here is a starting point on some text. Please edit to taste: > > The Flow Label MUST NOT be changed in transit, unless > (a) a router is changing a zero value Flow Label to > a non-zero value Flow Label compliant with this RFC > or (b) a security gateway for operational security > reasons changes a non-zero value Flow Label to a > different non-zero value Flow Label compliant with this RFC. > > I believe that security gateways overtime will become compliant > with this new specification if we provide them the instructions > above.
Ran, this looks fine to me, subject to wordsmithing when I see it in context, and to adding a real discussion of covert channels in the Security Considerations. Of course I will have to seek the agreement of my co-authors and resolve the other recent comments (mainly from Thomas), so expect a few more days before we have a new draft. Thanks for your help in getting this right. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------