[gnso-pro-wg] MUST-SHOULD-MAY Conventions

["Rosette, Kristina" <krosette@xxxxxxx>]

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