[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: opsec and 2119 keywords
Folks,
Strangely enough, David's point is exactly what I was
trying to say at the meeting. Somebody else said that this
should be okay - provided the draft-to-be-an-RFC provided a
sufficiently clear disclaimer.
There is a (possibly) suitable disclaimer built into
RFC 2119, which says -
"Note that the force of these words is modified by the
requirement level of the document in which they are used."
However, I agree with David that using this kind of
terminology in an informational RFC is generally misleading
- even with an explicit disclaimer in addition to the one
that is already included in RFC 2119. As a general practice,
this seems to allow people to assert the definitions of a
standard, while making an end-run around the rigor of peer
review normally required of any document intended to become
a standard. No matter how carefully crafted a disclaimer is,
most people (non lawyers, anyway) typically do not apply the
terms of a disclaimer to every use for which it is intended
to apply.
Common practices among existing RFCs are that this
kind of terminology IS used - with and without a disclaimer.
This is especially true for "requirements" RFCs. This is
because "requirements" RFCs do not fit well into the various
available RFC categories. They don't work out very well as
"Proposed Standards" because there is some difficulty in
progressing them to Draft Standard and Standard except as a
result of extreme advanced age (examples RFC 1122 and 1123
combined as Standard 3 and some day - in the possibly distant
future - RFC 1812 as Standard 4). But a requirements document
_needs_ to use RFC 2119 terminology - completely unlike most
other non standards track RFCs. What is a requirement if it
does not use RFC 2119 terminology?
The problem with the terminology is actually that we
seem to be promoting publishing of an operational security
requirements as a BCP. Why are we doing that, given that
very few requirements RFCs were ever published as BCPs?
The vast majority of all requirements RFCs (well over
2/3 of all requirements RFCs - 60+ RFCs) have been published
as Informational (which - regardless of the terminology - is
what they are since they represent the author's opinion of
what is required for some application or operation).
Even in a BCP, the use of RFC 2119 terminology is only
legitimate with a bit of a stretch. A BCP SHOULD describe
what IS done (according to best common practice) - not what
SHOULD, or MUST, be done. If the purpose of a BCP is to
describe what SHOULD (NOT), MUST (NOT) or MAY (NOT) be done,
then it SHOULD perhaps have been a standard and SHOULD NOT
have been a best _current_ practices document.
However, a stretch to include BCPs is not completely
unnatural, given that RFC 2119 is itself a BCP and uses at
least the words "should" and "MUST" (albeit not consistently
in the capitalized form). Also, the intent is describing the
best common practices for some usage is to encourage people
to continue to follow the practice - so it is reasonable to
insist on certain behaviors in a BCP, even if a BCP is not
(quite) a standard.
This document should be published as an Informational
RFC. After some time and much discussion, we may decide
that it is wrong or incomplete and the IETF (or some of its
participants) will replace it with a new Informational RFC.
It does not seem to me to any make sense ever to publish
this as a BCP RFC.
--
Eric Gray
>
> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com]On Behalf Of
> Harrington, David
> Sent: Monday, March 08, 2004 12:13 PM
> To: gmj@pobox.com; black_david@emc.com
> Cc: opsec@ops.ietf.org
> Subject: RE: opsec and 2119 keywords
>
>
> 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
> >
> >
> >
> >
>
>