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

[Greg Aaron]

Dear Andrew:

I think we agree that terms need to be defined and used clearly.

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 .    (Maybe it would be a good t-shirt?: "RFC 2119: Not Just for Protocol Geeks Anymore".)   I think it's a decent option.  In any case, the WG needs something to rely upon.

It is true that people in the community sometimes don't read documents.  We can't do anything about that.  People in the community sometimes have different ideas about what a word may mean.  It is the job of any PDP WG to define its terms, write them down in the reports, and use the terms consistently.  That way the policies that result have the intended effect.

All best,
--Greg

 

-----Original Message-----
From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Andrew Sullivan
Sent: Wednesday, May 10, 2017 10:01 AM
To: gnso-rds-pdp-wg at icann.org
Subject: [gnso-rds-pdp-wg] RFC 2119 use (was Re: IMPORTANT: Invitation for Poll from 9 May Meeting)

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
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg