[gnso-pro-wg] proposals chart - Peter Olson comments in blue
All,
With apologies for my belated request (and realization), I
propose that we use in our recommendations and discussion the IETF
MUST-SHOULD-MAY conventions set forth in RFC 2119. The GNSO Council has
been using them of late and it would likely be helpful for us to use
them too.
Here's a link to the RFC http://www.ietf.org/rfc/rfc2119.txt
<http://www.ietf.org/rfc/rfc2119.txt> , but I copy below the relevant
text.
-*-
In many standards track documents several words are used to
signify the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document: The
key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Note that the force of these words is modified by the
requirement level of the document in which they are used.
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that
the definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
that there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed before
implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item
is truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that it
enhances the product while another vendor may omit the same item. An
implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does include
the option, though perhaps with reduced functionality. In the same vein
an implementation which does include a particular option MUST be
prepared to interoperate with another implementation which does not
include the option (except, of course, for the feature the option
provides.)
6. Guidance in the use of these Imperatives Imperatives of the
type defined in this memo must be used with care and sparingly. In
particular, they MUST only be used where it is actually required for
interoperation or to limit behavior which has potential for causing harm
(e.g., limiting retransmisssions) For example, they must not be used to
try to impose a particular method on implementors where the method is
not required for interoperability.
-*-
Many thanks.
Kristina
Attachment:
05132007 PRO WG Proposals Chart (2) - PGO.DOC |