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

Reply via email to