[gnso-rds-pdp-wg] RFC 2119 use (was Re: IMPORTANT: Invitation for Poll from 9 May Meeting)

Andrew Sullivan ajs at anvilwalrusden.com
Wed May 10 16:19:30 UTC 2017


On Wed, May 10, 2017 at 03:14:56PM +0000, Greg Aaron wrote:
> I think we agree that terms need to be defined and used clearly.

Yes, unreserved agreement here.
 
> Like I said, the RFC 2119 definitions have been used successfully for ICANN policy work for at least the last ten years, such as by the EWG and the GNSO.  Here's another example: The GNSO's final report on the introduction of new gTLDs https://gnso.icann.org/en/drafts/pdp-dec05-draft-fr.htm .

Actually, that was very much one of the reports I'm thinking about
where the use of SHOULD is not the sort of SHOULD that 2119 ought to
be.  (Note that the IETF gets this wrong all the time, too -- 2119's
SHOULD is quite unnatural in English.)

For instance, "ICANN should take a consistent approach to the
establishment of registry fees."  What does that "should" entail?  If
it doesn't happen, what breaks?  Or worse, "The base contract should
balance market certainty and flexibility for ICANN to accommodate a
rapidly changing market place."

These certainly _seem_ like they match 2119, which defines SHOULD thus:

   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.

The problem comes in 2119's section 6, which says this:

   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.

The "shoulds" in ICANN documents are mostly about expressing very
strong preferences.  I have no objection to doing that.  I just don't
want us to be pointing to 2119 and using those definitions as though
they're uncontroversial for these purposes; they aren't.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


More information about the gnso-rds-pdp-wg mailing list