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.
Yours,
Ran
ran.atkin...@gmail.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
