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

[Gomes, Chuck]

I suspect that we could end up with a statement to poll next week something
like this:  " Anonymity of thin data requesters must be required to the maximum extent possible."  I am not suggesting that everyone will agree with this but we can test it with a poll if we so decide.

Chuck

-----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: [EXTERNAL] [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