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

Wed May 10 16:33:22 UTC 2017

This is a topic that lawyers love to discuss as well (which may be why
other people don't love having discussions with lawyers...).  There are a
number of lawyers who write about drafting contracts who have covered this
ad nauseum.  I won't go and dig those up, since they don't constitute
anything official.  Having read a number of these articles, blog posts,
presentations, etc., my understanding of the usage of these words in
contract drafting is:

If you want to indicate that something is a requirement (i.e., mandatory),
use MUST or SHALL ("Shall" used to be favored, and is now less favored,
while "must" has become more popular in legal drafting -- but that's a
rabbit hole we don't need to go down).

If you want to indicate that something is recommended (i.e., it is the
favored outcome and not doing it requires an explicit decision based on
good reasons), use SHOULD.  (SHOULD doesn't show up in contracts very often
in my experience -- lawyers tend to dislike using "should" in most
contractual contexts, because it is vague and ambiguous, and gives the
other party plenty of wiggle room to avoid doing the thing. In other words,
anything less than a requirement is not a requirement at all.  Any party
who doesn't want to do a "SHOULD" action will be able to come up with good
enough reasons not to do it (and if they can't come up with good enough
reasons, they need a better lawyer).  "Should" statements are often
dismissed as "mere hortatory statements" -- words of encouragement rather
than requirement.  In a contract dispute, I would not want to be the lawyer
trying to prove that the other party was in breach when they didn't do a
"SHOULD"....)

If something is truly optional (either outcome is acceptable -- basically a
fork in the road) use MAY.  It can also be used to indicate several choices
for meeting a requirement (You *must* submit document x, and *may* use
email, fax, overnight courier or hand delivery)

I think the RFC 2119 sense of SHOULD is virtually identical (and it misses
the nuance to simply say that a SHOULD statement "can be ignored", since
turning away from a "should" requires a process, stated in the final clause
of the excerpt below):

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.

However, on the theory that contracts primarily set out requirements,
and that SHOULD does not state a requirement, I would recommend
staying away from SHOULD if we are trying to discuss things that will
end up in contracts.

So, while RFC 2119 is sensible, I would not use it as a license to
freely use "SHOULD" in contractual contexts within policy-making.  I
would also say that lawyers use MUST or SHALL a lot more often than
Section 6 (quoted by Andrew) would indicate.  In part this is because
contracts are often used to specify a single, agreed course of action,
even when other courses of action could be reasonable choices.  In
other words, contracts are often used to reduce choice in order to
reduce ambiguity and provide clarity about contractual compliance.

Greg (Shatan)

*Greg Shatan *C: 917-816-6428
S: gsshatan
gregshatanipc at gmail.com

On Wed, May 10, 2017 at 11:14 AM, Greg Aaron <gca at icginc.com> wrote:

> 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
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170510/1e9a11e3/attachment-0001.html>