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

[Andrew Sullivan]

Hi,

On Wed, May 10, 2017 at 02:28:47AM +0000, Greg Aaron wrote:
> Also, please note that the poll options use the term "should" -- but I think the  word "must" was meant instead.   "Must" indicates something mandatory, a requirement.   "Should" does not mean a thing is required or mandatory - it is a recommendation or opinion that can be ignored.
> 
> There is a standard reference we can use.  The terms MAY, MUST, MUST NOT, REQUIRED, SHALL,  SHOULD and SHOULD NOT are defined in RFC 2119.  ( https://www.ietf.org/rfc/rfc2119.txt )   RFC 2119 defined those terms for use in all subsequent RFCs.  The EWG was careful to use the above terms according to RFC 2119 (see Final Report, page 18). ICANN registry contracts, the TMCH RPM Requirements, and other ICANN efforts have also used RFC 2119 as a definitional document.
> 

There are two problems with using RFC 2119 for this.  The first is
that, alas, people almost never seem actually to read that document.
In 2119, SHOULD does _not_ indidate "a recommendation or opinion that
can be ignored."  What it means is that, unless you are really really
sure the condition doesn't apply in your case, you need to do the
SHOULDed thing.  That's because, if you don't, there is a high
probability your implementation won't work the way others expect.

And that brings us to the real problem with 2119 language for our
purposes.  Those terms are so defined because they're about protocol
interoperation.  When a protocol document says you SHOULD do _x_, it
is acknowledging that maybe you have some special corner case just for
your restricted use that means that all the downside of not
implementing _x_ will be ok, but that you're almost certainly wrong
about that and interoperation will fail if you have overlooked
something.  In recent years, therefore, it has been fashionable among
protocol geeks to write down what happens if you don't follow the
SHOULD.  But in our case, we're not designing for voluntary
interoperation.  We're designing for contractual specification.

None of this is to say that Greg is wrong about using "must" here.
But RFC 2119 will cloud the waters, and I think the occasional ICANN
embrace of it is actually often an error.

(Note that, for the purposes of the poll, I mostly said I could live
with the various options, but the lack of "must" was one of my worries.)

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com