[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: opsec and 2119 keywords
Thanks for the input. A couple observations:
1. To date, every attempt has been made to use
the keywords consistenly with RFC2119.
2. There is recent precident for INFOs using
2119 terminology. See 3628, 3604, 3583, etc.
3. From 2119:
2119> 7. Security Considerations
2119>
2119> These terms are frequently used to specify behavior with security
2119> implications. The effects on security of not implementing a MUST
2119> or SHOULD, or doing something the specification says MUST NOT or
2119> SHOULD NOT be done may be very subtle. Document authors should take
2119> the time to elaborate the security implications of not following
2119> recommendations or requirements as most implementors will not have
2119> had the benefit of the experience and discussion that produced the
2119> specification.
This is exactly what the justications section of each requirement is
intended to do.
4. Also from 2119:
2119> 6. Guidance in the use of these Imperatives
2119>
2119> Imperatives of the type defined in this memo must be used with care
2119> and sparingly. In particular, they MUST only be used where it is
2119> actually required for interoperation or to limit behavior which has
2119> potential for causing harm (e.g., limiting retransmisssions) For
2119> example, they must not be used to try to impose a particular method
2119> on implementors where the method is not required for
2119> interoperability.
I believe the draft's usage of the terms is consistent with this
section of 2119. The actual requiements, where the keywords are
used take pains to avoid specifying particular implementations.
The reqs are not so much about interoperability in the classic
protocol sense as about features that are needed to maintain
operations *at all*. The absence of these features has the
potential to "cause harm" in the sense without them it may
not be possible to maintain operations, or maintain operations
securely.
From my reading of 2119, the usage of the keywords in the draft is
consistent and should not introduce confusion. If you think that's
not true, let me know where....in general or in particular places
in the draft.
Thanks,
---George
On Mon, 8 Mar 2004, Harrington, David wrote:
> Hi,
>
> I have a concern about keeping the keywords in. Either MUST means MUST
> or it doesn't. RFC2119 identifies what MUST means in an IETF standard
> (and in a BCP, I believe).
>
> Using MUST in a different sense in an informational document, especially
> one that claims to espouse best current practice or is expected to
> espouse best current practice in the future, introduces ambiguity - is
> this necessary for interoperability or not?
>
> I think it would simply be WCP - worst current practice - to
> deliberately introduce ambiguity into these guidelines.
>
> I work in the Office of the CTO for Enterasys, and part of my job is to
> educate engineers and others and to convince them they should develop
> products that comply with standards requirements. If you develop a
> document that makes "compliance" to this sort-of-best current practice
> ambiguous, it makes it harder to sell compliance in the long run. It
> will be much easier for me to maintain the need to comply to real
> standards and BCPs by telling my engineers that YOUR "compliance"
> language really doesn't count, which signals to the engineers that your
> document can effectively be ignored. I think that is counter-productive.
>
> Either use MUST/SHOULD/etc. as would be required for a BCP compliant to
> RFC2119, or don't use them in your document, or qualify them in your
> document to indicate what they REALLY mean in your context. I prefer
> that you make them standards-compatible or don't use them at all.
>
> dbh
>
> > -----Original Message-----
> > From: George Jones [mailto:gmj@pobox.com]
> > Sent: Monday, March 08, 2004 9:53 AM
> > To: black_david@emc.com
> > Cc: opsec@ops.ietf.org
> > Subject: opsec and 2119 keywords
> >
> > Dave, in the opsec BoF you (I think) said:
> >
> > [18:42:46] <smb> db: with suitable disclaimers it's okay to use RFC
> > 2119.
> > [18:42:55] <smb> db: with a little more soak time this could be a BCP
> > [18:43:17] <smb> db: on RFC 2119, add some words to get an
> > informational out, and then remove them when it goes BCP
> >
> > Could you elaborate, esp. since the consensus of the BoF seemed
> > to be to take it INFO now. My tendancy will be to leave the
> > keywords mostly as-is unless there is a strong argument...or
> > IESG input to change. Thoughts ?
> >
> > Thanks,
> > ---George Jones
> >
> >
> >
> >
>
>