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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
