Subject: 2119bis

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Aug 2011 15:36:58 -0600

After staring at http://www.rfc-editor.org/errata_search.php?eid=499 for
long enough, I finally decided to submit an I-D that is intended to
obsolete RFC 2119. I hope that I've been able to update and clarify the
text in a way that is respectful of the original. Feedback is welcome.

http://www.ietf.org/id/draft-saintandre-2119bis-01.txt

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Thomas Narten <[email-masked]>
Date: Mon, 29 Aug 2011 17:50:18 -0400

It would help me if you explained the diffs and the *reasons* for the
proposed changes.

E.g, the new text says:

   This term means that the feature or behavior is a limited requirement
   of the specification, so that an implementation has a conditional
   obligation to implement the feature or to behave as defined, unless
   there is a strong, explicitly described reason not to do so in
   particular circumstances.  Those who implement the specification or
   deploy conformant technologies need to understand and carefully weigh
   the full implications of violating the requirement before doing so.
   The term "RECOMMENDED" is equivalent to "SHOULD".

The wording "unless there is a strong explicitly described reason not
to do so in particular circumstances" is new wording and my first
reaction is it's not helpful. I.e., "explicitely described by who?"
Explicitely specified in the text? If so, that seems unworkable in
practice.

What problem is this bis document intended to fix?

Thomas

---

From: Eric Burger <[email-masked]>
Date: Mon, 29 Aug 2011 18:08:15 -0400

I would assume in the text of the document.  This paragraph is simply an enumeration of Burger's Axiom:
	For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a MAY.

On Aug 29, 2011, at 5:50 PM, Thomas Narten wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Eric Burger <[email-masked]>
Date: Mon, 29 Aug 2011 18:11:15 -0400

Please make my English language sensibilities and satisfy Burger's Second Law of standards documents at the same time, forbidding passive voice.  Can we have the following as the boilerplate?  Thanks.

Either:

In this document, [RFCXXXX] describes the following conformance terms: "MUST", ...

Or:

[RFCXXXX] describes the following conformance terms used in this document: "MUST", ...

Also, from a typographic point of view, why are we quoting single worlds that are already in quotes?

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 30 Aug 2011 00:15:27 +0200

On 29 August 2011 23:36, Peter Saint-Andre wrote:

> staring at http://www.rfc-editor.org/errata_search.php?eid=499 for
> obsolete RFC 2119.

There are literally thousands of documents (not only RFCs, also W3C
standards, etc.) with normative references to RFC 2119 (sic!) instead
of BCP 14, and I see no compelling reason to render these references
as "historic".

For starters simply confirm the erratum, I don't see why that caused
you headaches.

IMO it is not necessary (but allowed) to import any BCP 14 terms not
actually used in a document, i.e., I disagree with section 4 in your
draft.

How about trying an "updates 2119" and status BCP, where BCP 14 then
consists of 2119 and 2119bis, and old RFC 2119 references are still
okay "as is".

Readers with difficulties to figure out what RFC 2119 meant might
find the confirmed erratum and the "updated by 2119bis" with better
answers.  Authors could use RFC 2119, 2119bis, or even BCP 14 in
the references of new documents, where "BCP 14" would be new, IIRC
RFC 2119 did not permit this -- fearing precisely what is happening
now, somebody trying to update critical terms.  I think that your
new definitions match precisely what RFC 2119 wanted, but I'm also
almost sure that some old "2119 clients" will disagree.

-Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Aug 2011 10:16:06 +1200

> 	For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a MAY.

And there can be cases where even a MUST needs an "unless". These cases can be fixed
by using regular English in the draft.

I'm not sure this needs new legislation. There is one real bug in 2119,
which is that "NOT RECOMMENDED" is not listed in the prescribed boilerplate.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Aug 2011 18:20:31 -0400

--On Monday, August 29, 2011 17:50 -0400 Thomas Narten
<[email-masked]> wrote:

> It would help me if you explained the diffs and the *reasons*
> for the proposed changes.
> 
>...
> The wording "unless there is a strong explicitly described
> reason not to do so in particular circumstances" is new
> wording and my first reaction is it's not helpful. I.e.,
> "explicitely described by who?" Explicitely specified in the
> text? If so, that seems unworkable in practice.
> 

+1

Note that, although it has often not been understood and there
has been pushback from an occasional AD, we've traditionally
never insisted on use of the 2119 definitions but instead have
permitted individual documents to define their own conformance
norms if they could justify doing so.  I can't tell whether this
document is intended to change that or not.

In addition, if you are going to recommend alternative
terminology for situations in which conformance language is
inappropriate, it would be nice for the community (and for the
RFC Editor) if the terms suggested as examples were literate.
For example, because specifications and protocols are rarely
animate, it is not clear than one can possible "need to" do much
of anything.

   john

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 29 Aug 2011 17:29:12 -0500

Peter,

Thank you for submitting this draft. It clarifies some of the most 
consistent sources of cyclic discussion that appear on the IETF discussion 
list.

I have a couple of questions.

The most consistent source of cyclic discussion that I didn't see addressed, 
is the use of RFC 2119 conformance terms in requirements drafts, and various 
other flavors of non-standards-track drafts. The draft itself explicitly 
targets standards-track documents.

My impression is that acceptable practice varies across the IETF, so (at 
least when I was an active Gen-ART reviewer) this came up from time to time 
in cross-area reviews. Is there anything the IESG can say about this, to 
give guidance to the community?

Sections 2.3 and 2.4 leave the requirement to say why one might not 
implement a SHOULD (and SHOULD NOT) as, well, a SHOULD. To ask the 
meta-review question, is there a reason why explaining a SHOULD (and SHOULD 
NOT) is a SHOULD, and not a MUST? :D

It's fine with me if the list of reasons isn't complete (so, "SHOULD" = "do 
X unless you have a good reason; good reasons include Y, and there may be 
other good reasons" would be implicit), but a bare SHOULD (or SHOULD NOT) 
with no explanation doesn't seem helpful. I've been told by some working 
groups "we think doing it is a MUST, but some deployed implementations don't 
do it, so it's a SHOULD". If that's the reason, perhaps writing it down 
would be healthy.

And I'd really like to see discussions of consequences as a MUST, even if 
explaining a SHOULD (or SHOULD NOT) remains a SHOULD.

I hesitate to bring the last one up, but I also see drafts that use the 
formulation "MUST do X unless Y". Would it be helpful to mention this? I 
believe "MUST X unless Y" is the moral equivalent of a SHOULD - perhaps you 
don't have to do anything except say that?

Thanks again for doing the work. Any cyclic discussion we can stop cycling 
on, is a beautiful thing!

Spencer

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Aug 2011 10:08:12 +1000

Thanks for starting this, Peter. A few comments / topics for discussion:

1) I agree that the "SHOULD... UNLESS" pattern ought be documented.

2) I strongly believe that authors should be encouraged to enumerate the potential subjects of conformance terms, and to use them in every instance.

For example, a requirement like this:

"""The Foo header MUST contain the "bar" directive"""

is ambiguous; it doesn't specify who has to do what. Rather,

"""Senders MUST include the "bar" directive when producing the Foo header; recipients that receive a Foo header without a "bar" directive MUST ..."""

is unambiguous (assuming that the spec defines the terms "sender" and "recipient").

3) It may be worth further cautioning against over-use of MAY; this is the most-abused term, IME. Perhaps encouraging people to make requirements testable on the wire would help.

4) WRT to the status of the document -- if people really feel that we don't need to revise 2119, I'd define this as a superset of 2119 and NOT obsolete it; i.e., have documents opt into it. However, I'd hope that we can get consensus that it's time to build on what 2119 offers.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 29 Aug 2011 18:12:01 -0700

Hi -

> From: "Eric Burger" <[email-masked]>
> To: "Narten Thomas" <[email-masked]>; "Saint-Andre Peter" <[email-masked]>
> Cc: "IETF discussion list" <[email-masked]>
> Sent: Monday, August 29, 2011 3:08 PM
> Subject: Re: 2119bis
>

I disagree.  If the "UNLESS" cases can be fully enumerated, then
"SHOULD x UNLESS y" is equivalent to "WHEN NOT y MUST X."
(Both beg the question of whether we would need to spell out that
"WHEN y MUST NOT X" is not necessarily an appropriate inference.)

RFC 2119 SHOULD is appropriate when the "UNLESS" cases are
known (or suspected) to exist, but it is not practical to exhaustively
identify them all.

Let's not gild this lily.

Randy

---

From: Keith Moore <[email-masked]>
Date: Mon, 29 Aug 2011 21:47:11 -0400

> known (or suspected) to exist, but it is not practical to exhaustively

+1.

---

From: [email-masked]
Date: Mon, 29 Aug 2011 18:47:45 -0700 (PDT)

> I disagree.

I concur with your disagreement. SHOULD should *not* be used when the
list of exceptions is known and practically enumerable.

> If the "UNLESS" cases can be fully enumerated, then

+1

				Ned

---

From: Eric Burger <[email-masked]>
Date: Mon, 29 Aug 2011 22:44:49 -0400

Yes, and...

I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD.  In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form.  Being pedantic and pedagogic:
	SHOULD send a 1 UNLESS you receive a 0
really means
	UNLESS you receive a 0, one MUST send a 1.

My vision of the UNLESS clause is not necessarily a protocol state, but an environment state.  These are things that I can see fit the SHOULD/UNLESS form:
	SHOULD send a 1 UNLESS you are in a walled garden
	SHOULD flip bit 27 UNLESS you have a disk
	SHOULD NOT explode UNLESS you are a bomb
are all reasonable SHOULD-level statements.

I would offer that ANY construction of SHOULD without an UNLESS is a MAY.  Unless of course one considers us the Protocol Nanny's(tm) - if do not do a SHOULD, we will send you to bed without your treacle! I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Aug 2011 12:54:49 +1000

> are all reasonable SHOULD-level statements.

If this is the intent, I'd say it should (ahem) really be MUST... UNLESS. SHOULD... UNLESS will lead to people misreading it.

> Unless of course one considers us the Protocol Nanny's(tm) - if do not do a SHOULD, we will send you to bed without your treacle! I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY.

+1

---

From: Keith Moore <[email-masked]>
Date: Mon, 29 Aug 2011 23:11:23 -0400

On Aug 29, 2011, at 10:44 PM, Eric Burger wrote:

> I would offer that ANY construction of SHOULD without an UNLESS is a MAY.

The essential beauty of SHOULD is that it gets specification writers and working groups out of the all-too-common rathole of trying to anticipate and nail down every exceptional case.

Keith

---

From: HLS <[email-masked]>
Date: Mon, 29 Aug 2011 23:21:46 -0400

+1

I believe the issue is the subtle differences between:

    SHOULD for something new, i.e. no dependency
    SHOULD for something old, i.e. an enhancement or new dependency
the engineer is trying to push hard.

As much as we want to isolate protocols, in practice,  we are
integrating many protocols and in theory, it should all work. I
believe it has for the most part.  But increasingly a protocol upgrade
or new protocol here requires a "MUST USAGE" dependency of another
otherwise optional protocol there.  I believe that is what we are
seeing with this new interpretation.

New protocol X works better if existing optional (and much older)
protocol Y is applied as a SHOULD. It would like to say MUST but it
can't because Y is already optional and not required.   This new
interpretation will make software implementing X non-compliant if it
also doesn't support Y.

---
HLS
On Mon, Aug 29, 2011 at 10:44 PM, Eric Burger

-- 
hls

---

From: HLS <[email-masked]>
Date: Mon, 29 Aug 2011 23:40:49 -0400

On Mon, Aug 29, 2011 at 11:11 PM, Keith Moore
<[email-masked]> wrote:
> The essential beauty of SHOULD is that it gets specification writers and
> working groups out of the all-too-common rathole of trying to anticipate and
> nail down every exceptional case.
> Keith

+1,  and thats the problem with this new interpretation and its
unwritten form has already been used in a WG to label a group
participants as 2119 illiterates and any software that has implemented
a SHOULD as already non-compliant.

-- 
hls

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Aug 2011 21:34:20 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Nottingham
> Sent: Monday, August 29, 2011 5:08 PM
> To: Peter Saint-Andre
> Cc: IETF discussion list
> Subject: Re: 2119bis
> 

I had never thought of this before.  I kind of like the idea, especially since SHOULD has always meant "MUST unless you really know what you're doing" but that last bit, though strong, is still pretty subjective.  Having a tool to make it more explicit is a nice idea.

> 2) I strongly believe that authors should be encouraged to enumerate
> the potential subjects of conformance terms, and to use them in every
> instance.
> 
> """Senders MUST include the "bar" directive when producing the Foo
> header; recipients that receive a Foo header without a "bar" directive
> MUST ..."""
> 

...or at least say at the bottom of such a collection that fields/messages/pages/whatever that don't conform MUST be (default treatment here).

> 4) WRT to the status of the document -- if people really feel that we
> don't need to revise 2119, I'd define this as a superset of 2119 and
> NOT obsolete it; i.e., have documents opt into it. However, I'd hope
> that we can get consensus that it's time to build on what 2119 offers.

I don't see a big deal with rendering RFC2119 obsolete.  Or perhaps more accurately, I don't like the argument that we can't just because lots of outside SDOs reference it, or any similarly useful BCP we use could become set-in-stone as soon as others decide they like it.  We have a mechanism for checking whether a given RFC has been replaced or not; we all have to learn to use it, so I think others should as well.

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 30 Aug 2011 15:23:35 +0800

On 2011-08-30 at 07:36:58, Peter Saint-Andre wrote:
> for long enough, I finally decided to submit an I-D that is intended 
> to obsolete RFC 2119. 

<bike-shed>
IS THERE ANY CHANCE OF AGREEING THAT SHOUTING IS BAD?  (i.e., Burger's first anti-law.)  As opposed to mandating that requirements ought to be shouted.  Lowercase "must" can be as effective as uppercase as long as it is consistently applied.
</bike-shed>

On a more serious note, many documents lean too heavily on conformance terms.

A gentle reminder that conformance terms ought to be sparingly used might not go astray here.  It's just like the F-bomb, it's a F-ing big deal if used infrequently enough.  People are more likely to pay attention when it's rare.

--Martin

---

From: HLS <[email-masked]>
Date: Tue, 30 Aug 2011 04:00:12 -0400

On 8/30/11, Murray S. Kucherawy <[email-masked]> wrote:

>> Mark Nottingham:

> I had never thought of this before.  I kind of like the idea, especially since SHOULD
> has always meant "MUST unless you really know what you're doing"

Such an odd reading.  Does it mean you MUST because you could not
handle it otherwise?

It takes two to tango.  One side reasons can be different than the
other. If a software breaks down because it read SHOULD as a MUST and
expected the other end will also view is a MUST, then it didn't know
what it was doing.  Things break down. Implementors on either side
can't depend on it and need to function in lieu of it. There is always
the possibility one decided "Nahhhh, not needed, not worth the cost.
Its not required." etc, and no one should die because of that
decision.

I think it MUST be noted that a Minimum Implementation for a protocol
is all anyone can expect. If a SHOULD item is among the listed minimum
requirements, it MUST be removed from the list or changed to a MUST.

Maybe the term Minimum Implementation (is part of, is not part of) can
be incorporated into each of the key word text.

-- 
hls

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Aug 2011 10:05:18 +0200

Frank,

> of BCP 14, and I see no compelling reason to render these references

On the basis of this logic we wouldn't be able to supercede any of our
key RFCs.

> [...]

> consists of 2119 and 2119bis, and old RFC 2119 references are still

What ends up happening, then, is that we need Internet lawyers to
traipse through references.  I challenge you or anyone else here to list
all the process RFCs that update RFC 2026.  Let's not repeat that fiasco
with 2119.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 30 Aug 2011 12:14:02 +0300

Frank,

2119bis is going to replace RFC 2119, and "Obsoletes: 2119" header is 
fine here.  "Updates:" header means that some changes are made, and 
these specific changes are clearly indicated; 2119bis imports all the 
content of 2119 plus adding own changes, and is a significant update of 
2119, so "Updates: 2119" is inappropriate (sorry for pun).

I would rather object to making RFC 2119 Historic; I remember RFC 2026 
discusses such case (probably Section 6.3, which is also applicable to 
BCPs).  So, the following change is necessary:

Abstract and Introduction (similar text).  OLD: "If approved, this 
document obsoletes RFC 2119 and changes its status to Historic."; NEW: 
"This document obsoletes RFC 2119."

Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 30 Aug 2011 12:29:10 +0300

> 1) I agree that the "SHOULD... UNLESS" pattern ought be documented.

I think 2119bis should discuss use of the keywords in conditional 
clauses, how to interpret something like "<a> MUST be set to <b> if <c> 
is <d>", or "<a> SHOULD be <b> if <c> and SHOULD be <d> if <e>" etc.  
Defining the "<keyword> ... IF"/"<keyword> ... UNLESS" constructions for 
all of them?

+1.

> 3) It may be worth further cautioning against over-use of MAY; this is the most-abused term, IME. Perhaps encouraging people to make requirements testable on the wire would help.

My personal observation is that MAY is often used in sense of "can", 
i.e. to designate possibility rather than optionality.  So 2119bis 
should be clear that MAY is used for describing discretionary 
actions/behavior, and those authors who wish to denote "possible action" 
should use "can", which shouldn't be included in the repertoire as being 
irrelevant to conformance.

> 4) WRT to the status of the document -- if people really feel that we don't need to revise 2119, I'd define this as a superset of 2119 and NOT obsolete it; i.e., have documents opt into it. However…

See my previous message.

Mykyta Yevstifeyev

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 30 Aug 2011 09:24:47 -0400

Dear Eric;

I support adding the SHOULD ... UNLESS formalism (although maybe it should
be MUST... UNLESS). It would be useful as there will be times where the
UNLESS can be specified and has been given due consideration at the time of
writing. That, however, will not always be the case. (More inline).

On Mon, Aug 29, 2011 at 10:44 PM, Eric Burger <[email-masked]>wrote:

> Yes, and...
>
> I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X
> *are* what people usually mean when they say SHOULD.  In the spirit of Say
> What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting
> to the author to turn the statement into the if Y then MUST X or if Z then
> MUST NOT X form.  Being pedantic and pedagogic:
> My vision of the UNLESS clause is not necessarily a protocol state, but an
> environment state.  These are things that I can see fit the SHOULD/UNLESS
> form:

But how about

SHOULD do FOO UNLESS you have given serious consideration as to the
consequences of not doing FOO.

Isn't that really the original intention of SHOULD ?  Do we gain anything if
that is added every time it is used?

> I would offer that ANY construction of SHOULD without an UNLESS is a MAY.

How about this as a counterexample.

In London, you MAY use the tube for transport. Given the weather, you SHOULD
carry an umbrella.

This SHOULD and  MAY convey different things, in a way that I would argue is
useful, and enumerating a list of UNLESSes is not going to be exhaustive.

> Unless of course one considers us the Protocol Nanny's(tm) - if do not do a
> SHOULD, we will send you to bed without your treacle!

Now, now, now. This is the IETF. We use cookies for motivation.

Regards
Marshall

> I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY.
>

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Aug 2011 09:47:52 -0400

+1, too.

This goes along with my strong desire to eliminate passive voice, unless the goal is to have the actor be obfuscated (as an example).

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Aug 2011 09:49:23 -0400

On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote:
> Dear Eric;
> 
> I support adding the SHOULD ... UNLESS formalism (although maybe it should be MUST... UNLESS). It would be useful as there will be times where the UNLESS can be specified and has been given due consideration at the time of writing. That, however, will not always be the case. (More inline).
[snip]
> But how about 
> 
> SHOULD do FOO UNLESS you have given serious consideration as to the consequences of not doing FOO.
> 
> Isn't that really the original intention of SHOULD ?  Do we gain anything if that is added every time it is used?

Looking at this from a protocol perspective, SHOULD now equals MAY.  There is no objective way of deciding when to do FOO or not.

[snip]

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Aug 2011 09:51:14 -0400

I would offer that working groups that say to do something that may or may not hold in foreseen or unforeseen circumstances is most likely working on a protocol that is way too complex and is begging for interoperability problems.  What ever happened to building simple, point-solution protocols that followed the hour-glass and end-to-end principles, and then building your complex protocols out of them?

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 09:54:24 -0400

I think you're overgeneralizing.  My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 09:56:06 -0400

> I support adding the SHOULD ... UNLESS formalism (although maybe it should be MUST... UNLESS). It would be useful as there will be times where the UNLESS can be specified and has been given due con…

How would SHOULD...UNLESS or MUST...UNLESS differ from using the current 2119 definitions and just writing SHOULD...unless or MUST ... unless?

Personally I think 2119 is just fine and doesn't need to be updated.

Keith

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Aug 2011 09:56:14 -0400

This sentiment mostly makes sense.

If an endpoint expects SHOULD/MAY items implemented as MUSTs on the remote end, then one should slap the endpoint developer silly.  Read the RFC!  If it says SHOULD/MAY, then your implementation MUST be able to handle the feature present *and* absent.

Note that every SHOULD/MAY in a specification introduces cyclomatic complexity.  Every SHOULD/MAY results in at least one "if" statement, to test the presence or absence of the feature in the remote end.  Protocols will be much simpler to implement. Moreover, given the results in the software engineering literature that indicate latent defects appear super-linearly with cyclomatic complexity, protocols without (or a minimum) of SHOULD/MAY features will have fewer defects in the field.

Remember, we are working on Internet protocols, where a one-in-a-million corner case happens many times per day.

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 09:58:57 -0400

On Aug 30, 2011, at 9:56 AM, Eric Burger wrote:

>  Every SHOULD/MAY results in at least one "if" statement, to test the presence or absence of the feature in the remote end. 

false.

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Aug 2011 10:13:41 -0400

Strictly speaking, you are correct, in that if one interprets SHOULD/MAY as 'not bother', one does not need to check, unless the presence of the remote end doing the feature results in your barfing.  However, if one interprets SHOULD/MAY as 'bother', then one most likely needs to check on the capabilities of the far end or handle the varying data elements or protocol states that will or will not happen.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Aug 2011 07:14:12 -0700

On 08/30/2011 06:54 AM, Keith Moore wrote:
> I think you're overgeneralizing.  My experience is that judicious use of
> SHOULD seems to make both protocols and protocol specifications simpler;
> trying to nail everything down makes them more complex.

But using SHOULD does not make the implementation less complex, it simply
decreases the complexity for the *author* and increases the probability that two
independent implementations will have interoperability problems.

As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT RECOMMENDED.

>> I would offer that working groups that say to do something that may or may
>> not hold in foreseen or unforeseen circumstances is most likely working on
>> a protocol that is way too complex and is begging for interoperability
>> problems.  What ever happened to building simple, point-solution protocols
>> that followed the hour-glass and end-to-end principles, and then building
>> your complex protocols out of them?
>> 
>>> working groups out of the all-too-common rathole of trying to anticipate
>>> and nail down every exceptional case.
>>> 

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: HLS <[email-masked]>
Date: Tue, 30 Aug 2011 10:23:10 -0400

+1

-- 
hls

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 10:31:57 -0400

> Strictly speaking, you are correct, in that if one interprets SHOULD/MAY as 'not bother', one does not need to check, unless the presence of the remote end doing the feature results in your barfing…

SHOULD/MAY is used for many other cases than whether to implement a protocol feature that changes how the protocol works as viewed by its peer.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 10:35:19 -0400

On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

To the extent that SHOULD is causing interoperability problems, it may be that some authors are misusing SHOULD.  But it's not an inherent problem with SHOULD.

> As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT RECOMMENDED.

I'm an implementor also, and I've found SHOULD to be very helpful.  

Keith

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Aug 2011 07:54:02 -0700

> I'm an implementor also, and I've found SHOULD to be very helpful.  

Yes, it is very helpful in convincing one's PHB that one does not have to
implement something, or in convincing another company to reactivate a feature
during interop tests because one did not bother to implement it.

- -- 
Marc Petit-Huguenin

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 10:58:31 -0400

> during interop tests because one did not bother to implement it.

Rather than vaguely attacking SHOULD, maybe it would be more illuminating to cite specific examples?

Keith

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Aug 2011 08:38:56 -0700

> Rather than vaguely attacking SHOULD, maybe it would be more illuminating to cite specific examples?

It is difficult because of a mix of NDAs, employment confidentiality agreements
and desire to not single out individuals.  I'll send you an example in a private
email.

- -- 
Marc Petit-Huguenin

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 11:44:52 -0400

> and desire to not single out individuals.  I'll send you an example in a private

I look forward to seeing it.

But in general I get the impression that people are attacking SHOULD because of specific problems rather than general problems.  Since I find SHOULD very useful, to me it makes more sense to try to outline cases where SHOULD is problematic, and provide advice for those cases, than to try to get rid of it or change what it means.

e.g. For the specific case of optional features that must be negotiated, I don't think that SHOULD is the problem.  Rather I think that optional features are too common.  That's not to say that optional features and feature negotiation are never useful, particularly when extending a protocol that is already well-established in the field.  But if making features optional is seen by WGs as a way to avoid making hard decisions about what is required to interoperate, that really is a problem.  It just doesn't have anything to do with SHOULD.

Keith

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Aug 2011 11:46:55 -0400

I think you have hit the root cause on the head.

I would also offer that by removing the crutch, or raising the bar to using the crutch, will help alleviate the root cause.

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 11:58:34 -0400

e.g. 

"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED"  are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them.    However, they should not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Aug 2011 09:06:37 -0700

On 08/30/2011 08:44 AM, Keith Moore wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>> 
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>> 
>>>>>>> I think you're overgeneralizing.  My experience is that judicious
>>>>>>> use of SHOULD seems to make both protocols and protocol
>>>>>>> specifications simpler; trying to nail everything down makes them
>>>>>>> more complex.
>>>>>> 
>>>>>> But using SHOULD does not make the implementation less complex, it
>>>>>> simply decreases the complexity for the *author* and increases the
>>>>>> probability that two independent implementations will have
>>>>>> interoperability problems.
>>>>> 
>>>>> To the extent that SHOULD is causing interoperability problems, it
>>>>> may be that some authors are misusing SHOULD.  But it's not an
>>>>> inherent problem with SHOULD.
>>>>> 
>>>> Yes, it is very helpful in convincing one's PHB that one does not have
>>>> to implement something, or in convincing another company to reactivate
>>>> a feature during interop tests because one did not bother to implement
>>>> it.
>>> 
>>> 
>> It is difficult because of a mix of NDAs, employment confidentiality
>> agreements and desire to not single out individuals.  I'll send you an
>> example in a private email.
> 
> But in general I get the impression that people are attacking SHOULD because
> of specific problems rather than general problems.  Since I find SHOULD very
> useful, to me it makes more sense to try to outline cases where SHOULD is
> problematic, and provide advice for those cases, than to try to get rid of it
> or change what it means.

The meaning of SHOULD is clear for the authors (it "mean[s] 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 is that some implementers use a different
meaning (I do not have to implement this if it is inconvenient or difficult for
me to implement), vendors another one (SHOULD gave us the right to not implement
it).  I even read somewhere, perhaps on this list, about a vendor that rejected
any bug report against a SHOULD.  Conditional MUST, in my opinion, does not have
this problem.

> 
> e.g. For the specific case of optional features that must be negotiated, I
> don't think that SHOULD is the problem.  Rather I think that optional
> features are too common.  That's not to say that optional features and
> feature negotiation are never useful, particularly when extending a protocol
> that is already well-established in the field.  But if making features
> optional is seen by WGs as a way to avoid making hard decisions about what is
> required to interoperate, that really is a problem.  It just doesn't have
> anything to do with SHOULD.

- -- 
Marc Petit-Huguenin

---

From: Bill McQuillan <[email-masked]>
Date: Tue, 30 Aug 2011 09:07:47 -0700

On Tue, 2011-08-30, Keith Moore wrote:

> But in general I get the impression that people are attacking
> SHOULD because of specific problems rather than general
> problems.  Since I find SHOULD very useful, to me it makes more
> sense to try to outline cases where SHOULD is problematic, and
> provide advice for those cases, than to try to get rid of it or change what it means.

> e.g. For the specific case of optional features that must be
> negotiated, I don't think that SHOULD is the problem.  Rather I
> think that optional features are too common.  That's not to say
> that optional features and feature negotiation are never
> useful, particularly when extending a protocol that is already
> well-established in the field.  But if making features optional
> is seen by WGs as a way to avoid making hard decisions about
> what is required to interoperate, that really is a problem.  It
> just doesn't have anything to do with SHOULD.

How about recommending SHOULD ... BECAUSE to encourage the author
to justify the SHOULD. I suspect that this would reduce the
number of SHOULDs, that would be better as MAYs, due to the
author's personal preference.

My impression is that the 2119 limitation on MUST and SHOULD for
only necessary protocol features is sometimes forgotten.

-- 
Bill McQuillan <[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 12:11:46 -0400

> any bug report against a SHOULD.  Conditional MUST, in my opinion, does not have

But conditional MUST has other problems, namely that you have to enumerate the exceptions for the MUST, and that's not always practical.

Implementors who think that SHOULD gives them a free pass to avoid implementing something that's needed to interoperate are misreading 2119.  But document editors should avoid using SHOULD for cases where failure to implement the requirement will result in interoperability failure.

I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea.  And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents.

Keith

---

From: Martin Sustrik <[email-masked]>
Date: Tue, 30 Aug 2011 18:20:39 +0200

On 08/30/2011 06:07 PM, Bill McQuillan wrote:

> to justify the SHOULD.

+1

Although saying something like this should do: "If there's a SHOULD 
clause in the document, the document MUST provide background and 
rationale for making the behaviour optional.

For an implementor it's often pretty hard to decide whether to implement 
functionality marked as SHOULD given that he has zero context and no 
idea whether the reason he has for not implementing the feature is at 
all in line with RFC authors' intentions.

Martin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Aug 2011 09:19:23 -0700

On 08/30/2011 09:11 AM, Keith Moore wrote:
> But conditional MUST has other problems, namely that you have to enumerate the
> exceptions for the MUST, and that's not always practical.
> 
> Implementors who think that SHOULD gives them a free pass to avoid implementing
> something that's needed to interoperate are misreading 2119.  But document
> editors should avoid using SHOULD for cases where failure to implement the
> requirement will result in interoperability failure.
> 
> I could see maybe posting an erratum or a brief update to 2119, but I think that
> reopening that document in general is a Very bad Idea.  And for existing
> documents that misuse SHOULD, the appropriate thing to do is to update those
> documents or post errata to those documents, rather than try to retroactively
> change the meaning of the keywords in those documents.

I like your definition a previous email, so perhaps an alternative solution to
updating 2119 is for authors who really care about this subject is to integrate
it in the Terminology section, something like this:

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are
   appropriate when valid exceptions to a general requirement are known
   to exist or appear to exist, and it is infeasible or impractical to
   enumerate all of them.  However, they should not be interpreted as
   permitting implementors to fail to implement the general requirement
   when such failure would result in interoperability failure.

- -- 
Marc Petit-Huguenin

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 12:23:38 -0400

> author's personal preference.

I think 1122 and 1123 did this very well.  State the general requirement briefly in terms of MUST or SHOULD or whatever, then follow that by an explanation written in normal language.

What I see far too often these days is an attempt to write both complicated requirements and the explanations in terms of 2119 conditional keywords.   This makes the requirements difficult for an implementor to understand and perhaps more ambiguous than was intended.    

> only necessary protocol features is sometimes forgotten.

This is actually one case where I think 2119 misstated things.   The problem is that it's not just protocol features (as viewed on the wire) that matter in practice.  SHOULD and its friends are really useful for cases where you can't precisely nail down what should happen on every particular platform on which the protocol might be implemented, but it's quite reasonable to state the intent.

Keith

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Aug 2011 12:46:35 -0400

Can you give an example of where a dangling SHOULD makes sense?  Most often I see something like:
	SHOULD implement security
meaning
	SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 30 Aug 2011 12:11:43 -0500

Umm, wait. I'm confused.

The boilerplate in existing documents points to 2119, right? and the updated boilerplate would point to this spec, if approved, right? so we're not retroactively changing the meaning of anything, right?

What am I missing?

Spencer
  ----- Original Message ----- 
  From: Keith Moore 
  To: Marc Petit-Huguenin 
  Cc: IETF discussion list ; Eric Burger 
  Sent: Tuesday, August 30, 2011 11:11 AM
  Subject: Re: 2119bis

  Keith

------------------------------------------------------------------------------

---

From: HLS <[email-masked]>
Date: Tue, 30 Aug 2011 13:30:41 -0400

In the perfect written technical specification, if you pulled out all
the SHOULDs, the protocol still survives.  But if a required
functionality breaks down, then it wasn't well written.

On 8/30/11, Eric Burger <[email-masked]> wrote:
>> But conditional MUST has other problems, namely that you have to enumerate
>> the exceptions for the MUST, and that's not always practical.
>>
>> Implementors who think that SHOULD gives them a free pass to avoid
>> implementing something that's needed to interoperate are misreading 2119.
>> But document editors should avoid using SHOULD for cases where failure to
>> implement the requirement will result in interoperability failure.
>>
>> I could see maybe posting an erratum or a brief update to 2119, but I
>> think that reopening that document in general is a Very bad Idea.  And for
>> existing documents that misuse SHOULD, the appropriate thing to do is to
>> update those documents or post errata to those documents, rather than try
>> to retroactively change the meaning of the keywords in those documents.
>>
>> Keith
>>

-- 
hls

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 13:50:42 -0400

> 	SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security

That wording doesn't make any sense.  Security implementation should almost always be a MUST, regardless of what any particular government might say.  We shouldn't relax the security requirements of our protocols because of brain-damaged governments (and I include my own country's government in that list).   

In cases like this it's sometimes important to distinguish between implementation and use.  "MUST implement, SHOULD use" is a common compromise.

Note also that MUST doesn't mean "you have to do this".   It means "if you don't do this, you don't comply with the specification".

I don't think the example above is a typical use of SHOULD, though it might be too common.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 13:52:55 -0400

> The boilerplate in existing documents points to 2119, right? and the updated boilerplate would point to this spec, if approved, right? so we're not retroactively changing the meaning of anything, r…

If 2119 were to be updated, that's how it should work.   If we're going to retroactively clarify the meanings of the keywords, that should probably be done on a per-document basis.  (here's what we really meant when we said SHOULD in RFC XXXX...)

I think it's very premature to assume that 2119 will be updated.

Keith

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 30 Aug 2011 11:02:04 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of HLS
> Sent: Tuesday, August 30, 2011 1:00 AM
> To: IETF discussion list
> Subject: Re: 2119bis
> 

I'm sorry if you think it's odd, but it's correct.  Read RFC2119 again:

3. 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.

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Aug 2011 14:02:57 -0400

Note the language
> "MUST implement, SHOULD use" is a common compromise.
                                          ^^^^^^^^^^^

This is my heartache.  Why is it a compromise?  Most use of SHOULD I run into in WG's is either this precise one:
	I don't want to make this a MUST use, because I will have deployments *THAT ARE NOT FOR THE INTERNET* but I want to market them as if they were.
Example: instant messaging systems for enterprises where tapping is a legal requirement, not something to be avoided.
Example: instant messaging systems deployed where governments want to do warrantless, undetectable tapping

I would offer neither of these examples are Internet examples, and we should get some iron underpants on and say so.

Internet protocols need Internet protections.

SHOULD should neither be a crutch for making a proprietary protocol look like an Internet protocol nor for making two proprietary protocols look like a single, Internet protocol.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 30 Aug 2011 11:04:06 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
> Sent: Tuesday, August 30, 2011 7:35 AM
> To: Marc Petit-Huguenin
> Cc: IETF discussion list; Eric Burger
> Subject: Re: 2119bis
> 
> To the extent that SHOULD is causing interoperability problems, it may
> be that some authors are misusing SHOULD.  But it's not an inherent
> problem with SHOULD.
> 
> [...]
> 

+1 to both points.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Aug 2011 11:13:46 -0700

> exceptions for the MUST, and that's not always practical.

No, you just have to list the known cases.  Here's an example of a SHOULD that
creates a lot of problems.  This is from RFC 1889 (RFC 3550 has a slightly
better statement, but the damage was done by the time it was published):

"Functions 1-3 [i.e. RTCP feedback, RTCP CNAME and RTCP rate limit] are
mandatory when RTP is used in the IP multicast environment, and are recommended
for all environments."

If I remember correctly the reason was that it is not always possible for the
receiver to send back the RR packets, for example on satellite links.

But VoIP implementations more or less all decided to not implement RTCP using
this statement (feedback is very important even on unicast RTP for congestion
control).

A conditional MUST could have been written this way:

"Functions 1-3 are mandatory for all environments that permit a channel back to
the sender."

- -- 
Marc Petit-Huguenin

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 30 Aug 2011 11:14:31 -0700

It seems to me RFC2119bis might benefit from some consensus text on what proper use of each is, beyond defining their respective meanings.  From the discussion, this is obviously true for SHOULD at least.  The discussion around use of MAY in RFC2119 is fairly thorough, so maybe SHOULD needs to be similarly expanded.  And I suspect some distillation of this discussion might provide some ideal text.

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Tuesday, August 30, 2011 11:03 AM
To: IETF discussion list
Subject: Re: 2119bis

Note the language

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 14:19:37 -0400

>> "MUST implement, SHOULD use" is a common compromise.

Mumble.  I fundamentally don't buy the argument that things that are used on both local networks and the Internet should not be subject to Internet-strength security.   

And even where recording is a legal requirement, that's NOT an argument for sending traffic in cleartext or with weak encryption.  That might be an argument for some kind of backdoor - e.g. a trusted proxy or key escrow or whatever, but it's not an argument for making the traffic available for those without a legal need to see it.

> SHOULD should neither be a crutch for making a proprietary protocol look like an Internet protocol nor for making two proprietary protocols look like a single, Internet protocol.

agree.

Keith

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Aug 2011 14:26:19 -0400

We violently agree.  However, the most cited reason I get for watering down security requirements are what I mentioned below.

---

From: hector <[email-masked]>
Date: Tue, 30 Aug 2011 14:47:47 -0400

Its not correct if its doesn't state it how you interpreted it. A
recommendation is not a MUST or a mandate, and using a SHOULD as if
its required feature is pretty much guaranteed to cause problems when
this MUST expectation is not met.  Sounds like we are trying to remove
the idea that implementators really don't have "valid" reasons to
ignore it.

IMV, the problem here is that we can't generalized how protocol
recommendations are implemented across the board equally and its not
correct to be begin using this as a mandate for forcing deployment of
what may be deemed unnecessary, controversial and automatically begin
classifying existing minimum requirements implementators as
non-compliant.

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Aug 2011 13:49:48 -0500

> I would offer that ANY construction of SHOULD without an UNLESS is a MAY.

Eric. Put down the axe and step away from the whetstone. Here, I'll give 
you some text from RFC 3265 to mull.

    deactivated: The subscription has been terminated, but the subscriber
       SHOULD retry immediately with a new subscription.  One primary use
       of such a status code is to allow migration of subscriptions
       between nodes.

Let's examine this use of "SHOULD." If the subscriber doesn't 
re-subscribe, is it an interop issue? No.

Is it in the interest of the implementation to re-subscribe? Yes. At 
least, under most circumstances. Otherwise, they won't get the state 
change notifications they want.

Are there cases in which it makes sense for the subscriber _not_ to 
re-subscribe? Yes, I'm sure there are. It's conceivable that the client 
happens to be shutting down but hasn't gotten around to terminating this 
particular subscription yet. But any such exceptions are highly 
implementation-dependent. Listing them would be useless noise to the 
reader, and senseless text creation for the author.

Does "SHOULD" get abused by some authors in some documents? Of course it 
does. But your crusade to throw out a useful tool just because it has 
been misused on occasion is an extreme over-reaction. I like this tool. 
I use this tool. If you see people misusing it, slap them.

But don't ban the tool.

/a

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Aug 2011 14:57:43 -0400

What is the difference in this case between SHOULD or MAY?

On Aug 30, 2011, at 2:49 PM, Adam Roach wrote:

> Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull.
> 
> 
> Let's examine this use of "SHOULD." If the subscriber doesn't re-subscribe, is it an interop issue? No.
> 
> Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want.
> 
> Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author.
> 
> Does "SHOULD" get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them.
> 
> But don't ban the tool.
> 
> /a

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Aug 2011 14:08:15 -0500

> IS THERE ANY CHANCE OF AGREEING THAT SHOUTING IS BAD?  (i.e., Burger's first anti-law.)  As opposed to mandating that requirements ought to be shouted.  Lowercase "must" can be as effective as uppe…

You paint that as tongue-in-cheek, but Peter's draft does go down the 
rat-hole of picking out a color scheme for this particular bike shed, 
when doing so is really unwarranted. In addition to the SHOULD & co 
brouhaha, I have serious heartburn over this passage:

    When it is not appropriate to use the conformance terms, authors can
    use a variety of alternative words and phrases, such as: "need to" or
    "mandatory" instead of "MUST"; "ought to" or "strongly encouraged"
    instead of "SHOULD"; and "might" or "discretionary" instead of "MAY".
    To prevent confusion, authors ought to use these alternative words
    and phrases instead of the lowercase versions of the conformance
    terms, and to use the conformance terms only in their uppercase
    versions.

There is no reason to tie authors' hands by restricting them from using 
perfectly good English words just because they happen to be the same 
symbols used by RFC 2119. If we're going down this path, let's scrap 
using MUST/SHOULD/MAY/etc, and formalize our conformance terms with 
symbols that aren't English words.

Because the current suggestion -- which turns RFC writing into the game 
"Taboo" [1], but with incredibly common English words [2] as the 
forbidden list -- is ridiculous on its face.

/a

[1] http://en.wikipedia.org/wiki/Taboo_%28game%29
[2] According to Project Gutenberg, "must" and "may" are among the 100 
words most frequently used in written literature. See 
http://en.wiktionary.org/wiki/Wiktionary:Frequency_lists#Project_Gutenberg

---

From: hector <[email-masked]>
Date: Tue, 30 Aug 2011 15:08:54 -0400

When I approach a protocol to implement, the first thing I typically 
do is extract and develop the basic wiring of the protocol, the 
minimum requirements.  Make sure the basic framework is correct 100%, 
then I look for the SHOULDs and also MAYS which are the easiest to 
add.  I look at the SHOULD by order of importance and also complexity. 
  How much "CANDY" is it?  It is a security feature?  What are the 
other implementation requirements, tools, APIs, etc.  Generally I want 
to get security out the way.  Its like SMTP AUTH - its not required 
but anyone cleaning up and rewriting an SMTP spec today, might include 
the AUTH extension as a SHOULD. And implementators are keen to the 
importance of it.  But nothing won't break down if you don't, less 
functionality but the basic structure is still there.

Its the same approach used for all the protocols we support. Start 
with the basics and then add on  as necessary.

Eric Burger wrote:
> ------------------------------------------------------------------------
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Aug 2011 14:15:00 -0500

In this case, unless the implementation has a good reason, failing to 
re-subscribe will result in behavior that the user perceives as broken. 
I don't think that's really "MAY" territory.

/a

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Aug 2011 15:18:53 -0400

+1

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Aug 2011 13:00:02 -0700

On 08/30/2011 12:18 PM, Keith Moore wrote:
>> Does "SHOULD" get abused by some authors in some documents? Of course it does.
>> But your crusade to throw out a useful tool just because it has been misused
>> on occasion is an extreme over-reaction. I like this tool. I use this tool. If
>> you see people misusing it, slap them.
>>
>> But don't ban the tool.
> 
> +1
> 

I am wondering if having an Implementers Directorate, tasked to do reviews from
an implementation point of view, could not help discovering when a SHOULD can
create interoperability problems.  I would certainly volunteer in such group.

- -- 
Marc Petit-Huguenin

---

From: Hector Santos <[email-masked]>
Date: Mon, 29 Aug 2011 20:54:53 -0400

Thanks for doing this Peter.  I only have one input regarding SHOULD.

Recently an AD entered an WG during LC, apologized for not being 
involved more and specifically called out the 4-5 people who had 
rejected a SHOULD text injection proposal as not understanding 
RFC2119. He also added that software which does not implement a SHOULD 
is broken already.  In fact, his interpretation is ironically very 
close to what you have for SHOULD in this I-D.  So I wonder if this 
I-D SHOULD text is the same AD view and a result of what happen in the 
WG.  This is not a disrespect of AD, but I vocalized my exception to 
the AD description when:

    A) There was no RFC2119 material text or copy that even came close
       to AD interpretation, and

    B) RFC2119 states SHOULD is the same as the adjective "RECOMMENDED."

As far I am concern, a recommendation is not a mandate nor obligation. 
  The text is very vague and the original RFC2119 is simpler to 
understand and IMO, closer to practical realities faced for 
implementators.

Of course, none of this is cut and dry and I understand the intent of 
the text is to encourage implementators to update their software, 
especially for enhanced protocol and/or new integrated ideas where one 
protocol requires the help of another protocol, a situation where 
ideally one would like something to be written as a MUST but for 
legacy reasons a fallback is available, thus written as a SHOULD.  The 
dilemma begin that unless it is more described with some level of 
obligation, people don't upgrade as fast or as wide as one would like.

My concerns are when a protocol SHOULD is read as an obligation, then 
two things can and has happen:

    - Any software that is not currently supportive of a SHOULD or 
even aware
      of it, is instantly classified as broken software. This was one 
of the
      concerns  in the WG when the AD issued the same description as 
you have
      here.  When the feature was not already support and especially not
      required, or worst viewed as a temporary short term solution, a 
SHOULD
      defined as an Obligation is not going to go smoothly by all
      responsible implementators.

    - A feature that was a highly controversial decision and was added as
      a SHOULD with a rough consensus with lack compromise, an obligation
      interpretation will cause implementators to not follow it nor 
support
      something else that requires an additional SHOULD. It could even 
be a
      cost reason, an expensive design change that is require to 
accommodate
      a SHOULD not believed to be worth the effort.

I think rephrasing is necessary.  I think what is important, no matter 
which way the text wants it convey SHOULD as an important obligated 
feature to support, no protocol error can occur due to lack of support 
on either end or disabled by operators.

So if anything, I believe removing the final sentence would be more 
correct because its no longer a recommendation but an obligation. 
This is not a suggestion, but to highlight it it can probably be said 
in two sentences to convey the point:

      A SHOULD is a MUST with a fallback. Implementators are not
      considered NON-COMPLIANT if a SHOULD is not implemented as long
      as the fallback is already possible.

Thanks

-- 
Sincerely

Hector Santos
http://www.santronics.com

I addition, even if it was added by a piece of software, it does not
mean the operator MUST enabled it or that the software prevent him 
from turning it off.  I venture most implementations will not provide 
an MUST turn off switch but will provide a SHOULD turn off switch.

I also stated more importantly that even if it was a mandate for a 
server, since it must be ready for clients that do not support it and 
there is no operational repercussions for its lack of usage, thus by 
this consideration, there is no mandate or obligation by either side 
to support it.  In my view, if one end expects a feature, then its a 
MUST.  But if its able to fall back, then its a SHOULD.

---

From: [email-masked]
Date: Tue, 30 Aug 2011 15:38:06 -0700 (PDT)

> Personally I think 2119 is just fine and doesn't need to be updated.

+1. I'm still not seeing sufficient justification to open this particular can
of worms at this juncture.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Aug 2011 12:31:12 +1200

> of worms at this juncture.

+ another 1.

    Brian

---

From: Barry Leiba <[email-masked]>
Date: Tue, 30 Aug 2011 22:26:29 -0400

> As far I am concern, a recommendation is not a mandate nor obligation.

The problem we have with using what look like English words for these
things is that people have expectations about what those words mean.
Notwithstanding that, these words, in this context, are technical
terms, not English words.  One can't look them up in a dictionary, nor
use one's own sense, as a speaker of English, to determine what they
mean.  One must only use what RFC 2119 says.

It says this:

   3. 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.

That's not the same as many people's understanding of the English
meaning of the words "should" and "recommended", which are similar in
appearance to the technical terms defined in RFC 2119.

Of course, then we run into interpretations of the definitions of the
terms, and exactly what that sentence in item 3 in RFC 2119 *means*,
but I'm not getting into that here.  This may be where you, I, Peter,
and/or the AD in question differ.

But don't make the mistake of thinking that, in the context of RFC
2119, one can use one's own English sense of what the meanings of
these terms are.

Barry

---

From: Richard Barnes <[email-masked]>
Date: Tue, 30 Aug 2011 23:20:21 -0400

Friendly reminder from BCP 61: Security is a "MUST implement"
<http://tools.ietf.org/html/bcp61#section-7>

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Aug 2011 22:30:35 -0500

> forbidden list -- is ridiculous on its face.

Don't use requirements language unless you absolutely have to. 
Otherwise, explain things in clear prose, describing what happens in 
normal and error cases, and the logic used in distinguishing them.

If you absolutely require RFC 2119 requirements language to make 
something clear, I suggest the following symbology:

✔: MUST
☂: SHOULD
♥: MAY
✖: MUST NOT
♠: SHOULD NOT
☹: MAY NOT

And the fact that the above is garbled for some large percentage of 
readers explains why we use 7-bit ASCII in drafts, so let's just stop 
that argument now, ok?

--
Dean

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 31 Aug 2011 11:47:42 +0800

My first reaction was that the entire topic is a bike shed.  The goal is clear and understandable specifications and 2119 is just a tool we use to make the process of producing and reading specifications more efficient.

What I'm getting from this is that there are a significant number of drafts being submitted to the IESG for publication that are not sufficiently precise in their use of language.

Deciding to revise 2119 seems - at first blush - an interesting reaction to this problem.  But it's become evident that we don't share a common understanding of the language, nor are we consistent in its application.

Formalizing usage patterns (c.f. server MUST/client MAY, MUST...UNLESS...) does help, if only because you've made it easier to do the right thing in more cases.  If the problem is that authors and editors don't have the tools they need, then maybe a revision is the right approach.

However, I'd still like to see more RFCs that describe something without resorting to using these crude implements.

On 2011-08-31 at 05:08:15, Adam Roach wrote:
> There is no reason to tie authors' hands by restricting them from 
> using perfectly good English words just because they happen to be the 
> same symbols used by RFC 2119. If we're going down this path, let's 
> scrap using MUST/SHOULD/MAY/etc, and formalize our conformance terms 
> with symbols that aren't English words.

---

From: Eric Burger <[email-masked]>
Date: Wed, 31 Aug 2011 03:36:43 -0400

My interpretation of what you wrote is that in your mind there is absolutely no difference between a SHOULD and a MAY.  They are both optional, and you implement whatever you have time to implement, with SHOULD's prioritized higher than MAY's.

Even if that is not what you mean, it is what many implementors do.

I would offer this highlights the problem with today's SHOULD.  Some think SHOULD means something is OK to implement, but life does not end if you do not do it. Others think SHOULD means something HAS to be implemented, unless the environment indicates the protocol will not work in some corner case.

On Aug 30, 2011, at 3:08 PM, hector wrote:

> When I approach a protocol to implement, the first thing I typically do is extract and develop the basic wiring of the protocol, the minimum requirements.  Make sure the basic framework is correct 100%, then I look for the SHOULDs and also MAYS which are the easiest to add.  I look at the SHOULD by order of importance and also complexity.  How much "CANDY" is it?  It is a security feature?  What are the other implementation requirements, tools, APIs, etc.  Generally I want to get security out the way.  Its like SMTP AUTH - its not required but anyone cleaning up and rewriting an SMTP spec today, might include the AUTH extension as a SHOULD. And implementators are keen to the importance of it.  But nothing won't break down if you don't, less functionality but the basic structure is still there.
> 
> Its the same approach used for all the protocols we support. Start with the basics and then add on  as necessary.
> 
> Eric Burger wrote:

---

From: Eric Burger <[email-masked]>
Date: Wed, 31 Aug 2011 03:42:00 -0400

Interesting example.  I like it.  I agree that when to retry is not at all a protocol issue.  That probably is why we are in fuzzy land, and this highlights why SHOULD is bad.  The availability of SHOULD drew the author of the mentioned RFC to mix a user interface / user experience issue with a protocol issue.

Saying a client SHOULD retry immediately, to migrate subscriptions, is an implementation detail and has absolutely NOTHING to do with the protocol.

It would be OK to have a NOTE in the protocol RFC discussing that "deactivated" is an opportunity to migrate the subscription.  It would be OK to have an Informational implementor's guide that notes that it would be good for clients to leverage the "deactivated" state to quickly migrate a subscription.  However, there is NOTHING in the protocol to say SHOULD.

On Aug 30, 2011, at 3:15 PM, Adam Roach wrote:

> In this case, unless the implementation has a good reason, failing to re-subscribe will result in behavior that the user perceives as broken. I don't think that's really "MAY" territory.
> 
> /a
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 31 Aug 2011 21:30:24 +1000

Exactly. I'm working my way through RFC2616bis, trying to distinguish between SHOULDs that actually have implications for interoperability and SHOULDs that are just there because the english word 'should' happened to make sense at the time. It's a huge pain.

---

From: Hector <[email-masked]>
Date: Wed, 31 Aug 2011 08:30:46 -0400

Yes, but there is another factor that appears to be presumed in the 
discussions that might will help explains the critical difference:

     Even if SHOULD is interpreted as a MUST IMPLEMENT,
     there is no MUST USE guarantee by protocol consumers.

An implementator might decide a particular SHOULD has an absolute no 
consumer value, it might even be harmful, and it might be a low 
adoption currently, that might be enough to ignore it.

On the hand, if he says "Oh, lets add it anyway," he must still 
present it as OPTION to the consumer for them to decide.

In my view, SHOULD are user protocol options to set.  Odds are good a 
SHOULD would be enabled out of the box.  Some might be disabled out of 
the box.   If its not an user option, then that means it must be 
enabled with no way to turn off.  If so, then logic tells me that this 
SHOULD should of been a MUST to be begin right. No?

--
HLS

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Aug 2011 08:38:01 -0400

On Aug 31, 2011, at 8:30 AM, Hector wrote:

> In my view, SHOULD are user protocol options to set.  

In my view, SHOULD should rarely be used for optional protocol features, because optional protocol features should themselves be rare.  And the primary purpose of SHOULD is not to permit optional protocol features.

Keith

---

From: Hector <[email-masked]>
Date: Wed, 31 Aug 2011 09:12:51 -0400

Keith Moore wrote:
> In my view, SHOULD should rarely be used for optional protocol features, 
> because optional protocol features should themselves be rare.  And the primary 
> purpose of SHOULD is not to permit optional protocol features.

If SHOULD is read as a MUST IMPLEMENT, and that also implies MUST USE 
with no provision to disable then its should of been a MUST in the 
first place.

When presented to consumers, we do this for the most part:

o MUST items

No options, to way to turn off. No GUI, Nada.  Under rare 
circumstances, usually due to protocol conflicts, i.e. a MUST really 
should of been a SHOULD and it might have been a SHOULD in protocol 
STD, but made into a MUST in protocol RFC update and that now causes 
problems, hence undocumented switches are provided for support.

o SHOULD items

Here we have three forms of the options:

    [X] Extended Feature A    -  higher sweet benefit! default ON
    [_] Extended Feature B    -  Nice, but high overhead, default OFF
    [_] Extended Feature C    -  It was default ON, but operator said 
NAHHHHH!

MAY options are similar but heres you have learn more about the 
consumer needs to decide what protocol overhead is added and/or 
initial ON/OFF position.

Many Implementators makes decides on the basic of this SHOULD value 
offers. Its a big waste of them, it won't be implemented.  But when 
its get more adoption, maybe.  And we can't impose Bloat Ware options 
that prove to be bad or not desired, so you have to present these 
SHOULDS as options.

I sense a bad direction with what is basically "ALL or Nothing" 
protocol implementation, including with there little adoption, complex 
to support and simply not required. This might be enough to raise the 
barrier on adoption for some protocols that insist on on a "All or 
Nothing" conformance mandate.

Why even bother with SHOULD, and use have MUST and MAY?

--
HLS

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Aug 2011 09:26:12 -0400

On Aug 31, 2011, at 9:12 AM, Hector wrote:

> If SHOULD is read as a MUST IMPLEMENT, and that also implies MUST USE with no provision to disable then its should of been a MUST in the first place.

Just because a feature is optional does not mean that it's a protocol feature... i.e. it doesn't mean that it affects how the implementation interacts with peers.  

SHOULD is IMO most often useful not when specifying how a protocol acts "on the wire", but when specifying how a protocol needs to be implemented on a particular platform, where the precise semantics, API details, etc. naturally differ from one platform to another.

> Why even bother with SHOULD, and use have MUST and MAY?

To get people out of the rathole of trying to specify exactly how everything must work in excruciating detail, in a world where there is inherently going to be some necessary variation.

Keith

---

From: hector <[email-masked]>
Date: Wed, 31 Aug 2011 09:57:23 -0400

Keith Moore wrote:
>> If SHOULD is read as a MUST IMPLEMENT, and that also 
>> implies MUST USE with no provision to disable then its should of 
>> been a MUST in the first place.
> 
> Just because a feature is optional does not mean that it's a 
> protocol feature... i.e. it doesn't mean that it affects how the 
> implementation interacts with peers.  

Thats the problem with trying generalize SHOULD as single 
interpretation for all SHOULDs when it is so highly subjective many times.

I think you are speaking of long term operations where an SHOULD is so 
widely adopted, it inherently because a MUST have in all new 
implementations.  So that vain, sure, eventually the better options 
naturally become part of the protocol to the extent the options might 
be even remove to simplify things.  We also have the opposite where a 
SHOULD is implemented but no one users it so eventually, it may be 
remove as an option.

> SHOULD is IMO most often useful not when specifying how a protocol 
> acts "on the wire", but when specifying how a protocol needs to be 
> implemented on a particular platform, where the precise semantics, 
> API details, etc. naturally differ from one platform to another.

Yeah, but its also very very useful to offering what parts of a 
protocol are on and off and let operators decide what they want. 
Don't we already do this?

> 
>> Why even bother with SHOULD, and just use MUST and MAY?
> 
> To get people out of the rathole of trying to specify exactly how 
> everything must work in excruciating detail, in a world where there is 
> inherently going to be some necessary variation.

I agree, it is the easy way out.  But wouldn't it still be a rathole 
if SHOULD was still a MUST-IMPLEMENT concept which is why a MUST made 
it an rathole in the first place?  Too many people didn't like, not 
want it nor wish to waste time on a unproven concept. So you make it a 
SHOULD or a MAY.

With a MUST-IMPLEMENT view of SHOULD, then SHOULD really isn't 
compromise if you have to implement and even more so if no one is 
allowed to turn it off.

-1 on RFC2119bis :)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Aug 2011 07:03:20 -0700

> Sent: Wednesday, August 31, 2011 12:37 AM
> To: hector
> Cc: IETF discussion list
> Subject: Re: 2119bis
> 
> I would offer this highlights the problem with today's SHOULD.  Some
> think SHOULD means something is OK to implement, but life does not end
> if you do not do it. Others think SHOULD means something HAS to be
> implemented, unless the environment indicates the protocol will not
> work in some corner case.

On the other hand, given the current SHOULD definition in RFC2119, I'm at a loss to understand how one could reasonably come to other than the second interpretation you give here.  It's fairly explicit to me.

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Aug 2011 10:35:54 -0400

> On the other hand, given the current SHOULD definition in RFC2119, I'm at a loss to understand how one could reasonably come to other than the second interpretation you give here.  It's fairly expl…

The simplest explanation is that people don't bother to read 2119.

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Aug 2011 10:49:44 -0400

On Aug 31, 2011, at 9:57 AM, hector wrote:

> Yeah, but its also very very useful to offering what parts of a protocol are on and off and let operators decide what they want. Don't we already do this?

yes, it is done to some degree.  but that's not, in general, a desirable practice. (though there are cases where it can be justified).

Keith

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Aug 2011 18:43:59 +0300

> Unless of course one considers us the Protocol Nanny's(tm) - if do not do a SHOULD, we will send you to bed without your treacle! I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY.

Of course there is. Its the distinction between -

Qualified SHOULD) Here lie dragons. Take the recommended route, unless you know how to fight them.

Unqualified SHOULD) Here lie some dangers. Check with someone who knows, or take the recommended route.

MAY) Here's an area. You could go there.

Of course, the first and last pieces of text are preferred. But sometimes no one was brave enough to explore the area, so we don't actually know what dangers there are, they cannot be listed.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Aug 2011 18:48:17 +0300

Keith, Peter,

> I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more compl…

I agree.

In any case, Peter, I think its fine to add the NOT RECOMMENDED word to the boilerplate. Publish a spec on that, have it Update 2119, and then new RFCs would refer to that (say, 7119) instead of 2119 and everyone would be happy.

But I'm not quite sure why there are other changes in the text. Maybe I need to be educated better. On quick read I got more questions from it than what I get from 2119...

Jari

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Aug 2011 09:51:22 -0600

On 8/31/11 9:48 AM, Jari Arkko wrote:
> Keith, Peter,
> 
>> I think you're overgeneralizing. My experience is that judicious use
>> of SHOULD seems to make both protocols and protocol specifications
>> simpler; trying to nail everything down makes them more complex.
> 
> I agree.
> 
> In any case, Peter, I think its fine to add the NOT RECOMMENDED word to
> the boilerplate. Publish a spec on that, have it Update 2119, and then
> new RFCs would refer to that (say, 7119) instead of 2119 

Yes, that is one path.

> and everyone
> would be happy.

I'm not sure that everyone would be happy, because I do think that some
clarifications and additional guidelines might be helpful. But those,
too, could go in a separate (likely Informational) document that would
not necessarily update (and certainly not obsolete) 2119.

> But I'm not quite sure why there are other changes in the text. Maybe I
> need to be educated better. On quick read I got more questions from it
> than what I get from 2119...

Thus the desirability of writing a separate document.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Aug 2011 11:52:23 -0400

or maybe just file an erratum.  I think it's fairly obvious that any document that actually uses NOT RECOMMENDED should define what it means, if it expects those words to have any meaning other than the ordinary English meaning of those words (with or without capitalization).  

I've seen documents that didn't quote the 2119 boilerplate verbatim because they didn't use all of the terms defined in 2119.   I didn't see any problem with that.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Aug 2011 09:54:01 -0600

On 8/31/11 9:52 AM, Keith Moore wrote:
> or maybe just file an erratum.

There is an erratum on file:

http://www.rfc-editor.org/errata_search.php?eid=499

I started down this road in part while working to clear out errata...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Hector <[email-masked]>
Date: Wed, 31 Aug 2011 11:55:46 -0400

>> Yeah, but its also very very useful to offering what parts of a protocol are 
>> on and off and let operators decide what they want. Don't we already do this?

> yes, it is done to some degree.  

Every protocol I have implemented such as PPP, RADIUS, SMTP, TELNET, 
FTP, POP3 among the augmented protocols all have some levels of 
"Features" presented as SHOULDs and MAYs and those seem necessary 
where exposed in some form of configuration options. They might be 
tweaked for optimal out of the box performance, so you might not need 
them.  Just look at SMTP extensions, EHLO features.  There are SHOULD 
for 5 mins timeouts and 5321 states that its good idea to make this 
configurable.  Came in handy the other day! :) or even DKIM. Protocol 
options made available, but fined tune so the operators just can start 
using it.  But not all will use the setting you prepare for them.

> but that's not, in general, a desirable practice. (though there are 
> cases where it can be justified).

While I agree long time engineering & fine tuning, options become 
stable, deprecated or obsolete and  short of an finely tuned embedded 
system, turnkey system, even smart phone/devices, and not really even 
then, I hardly seen any protocol with options not implement with some 
level of exposure deemed necessary.

> The simplest explanation is that people don't bother to read 2119.

How can you make a claim like this with a straight face or I guess 
fingers? That invites useless conflicts like "get a dictionary" for 
the word Recommended,  or just plain old accepting the simple idea 
that after determining all full implications above and beyond what was 
necessary is a valid reason to IGNORE the recommendation.

--
HLS

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Aug 2011 12:02:44 -0400

On Aug 31, 2011, at 11:55 AM, Hector wrote:

> Every protocol I have implemented such as PPP, RADIUS, SMTP, TELNET, FTP, POP3 among the augmented protocols all have some levels of "Features" presented as SHOULDs and MAYs and those seem necessary where exposed in some form of configuration options. They might be tweaked for optimal out of the box performance, so you might not need them.  Just look at SMTP extensions, EHLO features.  There are SHOULD for 5 mins timeouts and 5321 states that its good idea to make this configurable.  Came in handy the other day! :) or even DKIM. Protocol options made available, but fined tune so the operators just can start using it.  But not all will use the setting you prepare for them.

Old protocols that were extended after they were widely deployed are one of the exceptional cases where SHOULD / SHOULD NOT / etc. make sense to describe protocol features.   They can't always be MUSTs or MUST NOTs because of the need to maintain backward compatibility with old implementations.

Things like timeout intervals are often labeled as SHOULDs because they aren't precisely determined, they're educated guesses.  So implementors and perhaps operators should have some leeway to tweak them in light of experience.

> How can you make a claim like this with a straight face or I guess fingers?

Because of long experience that indicates that implementors often fail to read base specifications thoroughly, much less the referenced specifications.

Keith

---

From: Hector Santos <[email-masked]>
Date: Wed, 31 Aug 2011 00:08:45 -0400

Barry Leiba wrote:
>> � B) RFC2119 states SHOULD is the same as the adjective "RECOMMENDED."
>>
> ..

Agree, that is why the final part of my email I suggested the 
consideration to remove the last sentence of the text be removed;  The 
term "RECOMMENDED" is equivalent to "SHOULD".

Personally, it benefit us if we state SHOULD under different 
classifications. I'm just winging it, but perhaps:

      NEW ITEM
      IMPROVEMENT
      SECURITY (VERY IMPORTANT)

A context of which the SHOULD offers has a lot of weight in the 
decision making process.

Example:

  If the SHOULD is related to security,
  then all efforts MUST be to made to support it.

  If the SHOULD item is an improvement not related to security,
  then all efforts SHOULD be to made to support it.

  If the SHOULD item is a new item not related to security,
  then all efforts MAY be to made to support it.

Of course, there is the interesting nature of recursion here and the 
last two can possibly be folded, but I think stating SHOULD compliance 
classified under new, improvement and the level of importance context 
will help rather than trying to state it as a generalize, ambiguous 
rule of thumb - "A MUST BUT OPTIONAL IFF YOU KNOW WHAT YOU ARE DOING."

The basic idea is that when is something is NEW there is lesser 
obligation to support it until its becomes widely adopted. If its 
really an important feature, like security, then it ought to be stated 
with a heavy obligatory emphasis.

Also, we may consider other general guidelines text like:

     New protocol enhancements with SHOULD key words MUST NOT be used 
a non-compliance
     measurement tool of existing compliant implementations. i.e. 
current implementator
     are not "broken" because they are not currently supporting a SHOULD.

     A new protocol that has a OPTIONAL dependency on an existing 
optional protocol
     MUST NOT use MUST|SHOULD as an enforcement tool for make 
implementator to
     support the optional protocol.

The last one I had trouble writing it, but I think you get the gist of it.

Overall, I believe the "system" has worked - we got this far because 
we gave implementators the benefit of the doubt that valid reasons to 
ignore was done responsibly and the protocols still worked.

The problem, in my view, has been an agenda of enforcing protocol 
behavior from a "Throw the book" non-compliance mindset, worst when 
dealing with integrated of optional protocols, yet not equally 
applied. e.g., "I don't wish to honor that other protocol SHOULD but 
you MUST follow my protocol SHOULD."

-- 
Sincerely

Hector Santos

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Aug 2011 12:51:03 -0400

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith> In my view, SHOULD should rarely be used for optional
    Keith> protocol features, because optional protocol features should
    Keith> themselves be rare.  And the primary purpose of SHOULD is not
    Keith> to permit optional protocol features.

Let me give an example of where I think SHOULD is useful:
    a TLS end-point SHOULD verify the received certificate against
    a trusted anchor.

Removing this requirement in SMTP-TLS has meant that we now have
opportunistically encrypted email transmission.  It makes sense for the
TLS library to have this option.   

In a web browser, the same SHOULD is much more controversial.

Some TLS libraries have this as a MUST, and there is all sorts of
trouble for people implementing other protocols or authentication
mechanisms over TLS.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Aug 2011 20:17:29 +0300

I think we should update our RFCs when there's a generally accepted errata. I mean, I know about errata. I browse IETF docs through tools.ietf.org and they show me the errata links. But... shame on me... I don't click through those links often enough. I suspect I'd miss a few even if I was implementing something. Its far better if the entire document is up to date. I suspect this holds for other at least some other people, too.

Jari

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Aug 2011 10:34:26 -0700

> Sent: Wednesday, August 31, 2011 9:03 AM
> To: Hector
> Cc: IETF discussion list
> Subject: Re: 2119bis
> 
> Because of long experience that indicates that implementors often fail
> to read base specifications thoroughly, much less the referenced
> specifications.

I absolutely agree, and also with your earlier point that a lot of people apparently either don't bother to read RFC2119 at all, or (in my experience) read it selectively.

If there is an RFC2119bis, I would like to see it illustrate the cases where a MUST would be preferred over a SHOULD, and vice-versa, such that the implications to both the spec author and the reader are clarified.  It already seems to start down that road, which is fine.  But I don't think there's anything wrong with the definitions as we have them; I think they've served us well for the last fourteen years.

I don't agree at all with the interpretation of SHOULD as an optional protocol feature in all cases.  RFC2119 makes it clear what SHOULD and RECOMMENDED mean beyond the dictionary definition.  They are not an invitation to disregard those requirements merely because they are hard to implement or would confuse end users if exposed.  It seems clear to me that SHOULD is the same as "MUST... UNLESS", and the "unless" part has to be carefully considered in terms of how interoperability will be affected, not how your source code or user interface will become more complicated.

It's certainly the case that there are some documents that got use of SHOULD wrong, but that doesn't mean RFC2119 is broken.

---

From: Hector <[email-masked]>
Date: Wed, 31 Aug 2011 13:57:02 -0400

> But I don't think there's anything wrong with the definitions as we have them; 
> I think they've served us well for the last fourteen years.

Correct and by far, most deployments have use SHOULD = OPTION with an 
documented right to IGNORE - so be it written so be it followed.  The 
"MUST-IMPLEMENT seems to be an exception and not the rule and even 
then is inconsistency in application seem to be very selective.

Maybe Tony's I-D can help reinforce this concept of a Recommendation:

    SHOULD, RECOMMENDED:  The words "ought", "encouraged" and "suggest
          strongly" can be used to connote something that is strongly
          urged.

and I hope these terms still don't means "MUST-IMPLEMENT" and worst a 
"MUST-USE" by the operator.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Aug 2011 11:00:20 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector
> Sent: Wednesday, August 31, 2011 10:57 AM
> Cc: IETF discussion list
> Subject: Re: 2119bis
> 
> documented right to IGNORE - so be it written so be it followed.

This sentence is self-contradictory.  "SHOULD" is, by definition, not "OPTIONAL".

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 31 Aug 2011 11:30:52 -0700

Hi -

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "IETF discussion list" <[email-masked]>
> Sent: Wednesday, August 31, 2011 11:00 AM
> Subject: RE: 2119bis
>

I disagree with the claim that there is a contradiction there, but I also think
"IGNORE" is incorrect.

The only difference between "SHOULD" and "MAY" is that the implementor /
deployer needs a good excuse to not implement / employ a "SHOULD."
That's not the same as "IGNORE".

However, looking at an implementation from a conformance testing perspective,
these are indistinguishable.  If the conditions under which the feature may
be omitted are well-defined, then an "if not x MUST y" structure would be
much more appropriate, and this can be easily handled with the existing
keywords.

Randy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Aug 2011 11:39:19 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Wednesday, August 31, 2011 11:31 AM
> To: IETF discussion list
> Subject: Re: 2119bis
> 

What was said is "SHOULD = OPTION", but RFC2119 says "OPTIONAL" is the same as "MAY".  That's the contradiction.

> That's not the same as "IGNORE".

But that's a big difference.  I think some people are being cavalier about the "good excuse" part, and that's where I have a problem.  RFC2119 is not unclear on this point.

---

From: Hector <[email-masked]>
Date: Wed, 31 Aug 2011 15:07:28 -0400

Murray S. Kucherawy wrote:

> But that's a big difference.  I think some people are being cavalier 
> about the "good excuse" part, and that's where I have a problem.  
> RFC2119 is not unclear on this point.

Correct again, it is not unclear.  It says it very clear.  I don't 
know why you wish to ignore Tony's I-D reinforcing this concept and 
optional implementation:

There is no possibility to interpret SHOULD as nothing else as an 
optional implementation and thus can be ignored. Of course, the 
presumptions are:

      - Faith in your engineering peers,
      - Due Diligence decision to decide to ignore it, and
      - understanding if it was implemented, it could be ignored by 
consumers.

If that is not enough, we have a huge deployment history where SHOULDs 
was ignored and implemented as an option for operators, and we have 
history where a SHOULD was changed to a MUST and it caused problems. 
If your interpretation was correct, this change would not have been 
necessary.

IMV, the evidence is quite clear that SHOULD has no MUST-IMPLEMENT 
concept and never had.  If people read it that way, it probably did 
not cause a problem. So no big deal.  But if they expected others to 
MUST-IMPLEMENT a SHOULD and broke down because of that expectation, 
then I suggest they didn't read RFC2119 correctly.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2011 21:09:58 +0200

Hi,

Sometimes the drafts says that something SHOULD be done, but the justification is unclear to the reader, so it can be difficult to interpret the meaning correctly.

So, I think it would cause less confusion if drafts made a better job of describing WHY something is a SHOULD, or MUST.

Something like SHOULD....BECAUSE :)

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hector [[email-masked]]
Sent: Wednesday, August 31, 2011 10:07 PM
Cc: IETF discussion list
Subject: Re: 2119bis

---

From: Hector <[email-masked]>
Date: Wed, 31 Aug 2011 15:12:57 -0400

Randy Presuhn wrote:

>> Murray stated:

That's a good point because if a good-faith decision was made to not 
implement a SHOULD, then there was no intent to ignore, there was no 
negligence and there is technical or protocol liability in that decision.

--
HLS

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Aug 2011 15:14:12 -0400

On Aug 31, 2011, at 3:07 PM, Hector wrote:

> Correct again, it is not unclear.  It says it very clear.  I don't know why you wish to ignore Tony's I-D reinforcing this concept and optional implementation:
> 

When the text in 2119 is already clearly written, but people fail to read it, I don't understand why adding more text in yet another document is likely to improve understanding.   Adding additional text and documents inherently increases the burden on readers.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Wed, 31 Aug 2011 11:27:59 -0800

On 08/31/2011 11:14 AM, Keith Moore wrote:
> When the text in 2119 is already clearly written, but people fail to read it,
 > I don't understand why adding more text in yet another document is
 > likely to improve understanding.   Adding additional text and
 > documents inherently increases the burden on readers.

This seems pretty clear to me, and perhaps it's been the only clear 
thing in this discussion so far.  2119 was published in 1997 and aside
from a typo (that does not seem to have caused confusion, for whatever
that's worth) there haven't been a lot of complaints.  Thumbs up on
correcting typos, and both thumbs down on using the process of
correcting a typo to reopen a "SHOULD/MAY" rathole, or even a "NOT
RECOMMENDED" rathole.  I'd rather let the typo stand.  I don't think
the putative benefits of revising 2119 justify the effort.

Melinda

---

From: Hector <[email-masked]>
Date: Wed, 31 Aug 2011 15:44:12 -0400

Keith Moore wrote:

>> Correct again, it is not unclear.  It says it very clear.  I don't know 
>> why you wish to ignore Tony's I-D reinforcing this concept and 
>> optional implementation:
>>
> When the text in 2119 is already clearly written, but people fail to read 
> it, I don't understand why adding more text in yet another document is 
> likely to improve understanding.   Adding additional text and documents 
> inherently increases the burden on readers.

I'm having a hard time understanding why you continue to work on the 
basis that people "fail to read" essentially implying stupidity in the 
process.  The Point being that if Tony's I-D has it as it was  shown 
above, then it would be incorrect too in its understanding of RFC2119 
because non-normative words are clearly concepts related to a 
non-required mandate.

I suggest we have a huge history of protocol deployment where SHOULDs 
are ignored and SHOULDs implemented as an option, but in addition, the 
idea of the possibility that isn't presented as an option to operators 
was solely an implementator decision to enforce it and not make an 
optional feature for the operator to play with.  It is really up to 
the author to describe what the intent is for a particular SHOULD 
because its not an universal idea that SHOULD is always implemented.

Anyway, I think that's it for me on this. :)

--
HLS

---

From: "John Levine" <[email-masked]>
Date: 31 Aug 2011 19:44:50 -0000

>When the text in 2119 is already clearly written, but people fail to
>read it, I don't understand why adding more text in yet another
>document is likely to improve understanding.  Adding additional text
>and documents inherently increases the burden on readers.

Having done my share of writing, and also having hired people to write
for me, I entirely agree.  You can't force people to write well by
adding ever more detailed and nitpicky rules.

If the problem is that RFCs aren't clear, or that they use words in
misleading ways, the burden should be on the WGs that produce the
drafts to fix them so that they say what they're trying to say better.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Aug 2011 15:50:33 -0400

On Aug 31, 2011, at 3:44 PM, Hector wrote:

> I'm having a hard time understanding why you continue to work on the basis that people "fail to read" essentially implying stupidity in the process.

I work on the basis of "fail to read" because I've seen countless examples of it.   And stupidity is not the same thing as lack of diligence.

>  The Point being that if Tony's I-D has it as it was  shown above, then it would be incorrect too in its understanding of RFC2119 because non-normative words are clearly concepts related to a non-required mandate.

As far as I'm concerned, Tony's I-D is a nonstarter, and therefore irrelevant.

Keith

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Aug 2011 13:00:18 -0700

> Sent: Wednesday, August 31, 2011 12:51 PM
> To: Hector
> Cc: IETF discussion list
> Subject: Re: 2119bis
> 
> > process.
> I work on the basis of "fail to read" because I've seen countless
> examples of it.   And stupidity is not the same thing as lack of
> diligence.

Ditto.  And I also see a lot of creative interpretation.  There's little we can do to thwart any of those problems; some people read what they want to read and do so in a vacuum.

> As far as I'm concerned, Tony's I-D is a nonstarter, and therefore

I certainly agree that it's irrelevant to this discussion, plus it's only an I-D at this point anyway.  We're talking about a published BCP here.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 31 Aug 2011 16:09:31 -0400

> When the text in 2119 is already clearly written, but people fail to read it, I don't understand why adding more text in yet another document is likely to improve understanding.   Adding additional…

context check. The purview of the non2119-nonkeywords doc is to suggest 
wording to use when *NOT* in the 2119 context.

Perhaps the paragraph in the non2119-nonkeywords docs should read:

     *instead* of "SHOULD" or "RECOMMENDED":  The words "ought", 
"encouraged" and "suggest
         strongly" can be used to connote something that is strongly
         urged.

     Tony

---

From: Melinda Shore <[email-masked]>
Date: Wed, 31 Aug 2011 12:16:35 -0800

> wording to use when *NOT* in the 2119 context.

Personally, I'm okay with an ambiguous, informal "may."  I'm
even okay with an ambiguous, informal "must."  I'm less okay
with the IETF publishing a thesaurus.

Melinda

---

From: Hector <[email-masked]>
Date: Wed, 31 Aug 2011 16:20:39 -0400

Keith Moore wrote:

>> The Point being that if Tony's I-D has it as it was  shown above, 
>> then it would be incorrect too in its understanding of RFC2119 
>> because the non-normative words are clearly concepts related to a 
>> non-required mandate.
> 

Oh the irony in the "Failure to Read" labeling category, the art of 
selective synergism, :) if only to acknowledge the rich IETF-MAN-YEARS 
behind the production of this I-D and its obvious relationship to 
RFC2119 and any future consideration for a RFC2119BIS. :)

Thanks

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 1 Sep 2011 07:57:28 +1000

If the author is disciplined enough to use them in that manner, sure.

I haven't come across many.

---

From: Eric Burger <[email-masked]>
Date: Wed, 31 Aug 2011 20:37:08 -0400

This highlights an interesting issue as an RFC goes from PS to IS.  I would offer that most SHOULDs in a document will, if there are real implementations out there, migrate to MUST or MUST NOT.

On Aug 31, 2011, at 9:57 AM, hector wrote:

> I think you are speaking of long term operations where an SHOULD is so widely adopted, it inherently because a MUST have in all new implementations.  So that vain, sure, eventually the better options naturally become part of the protocol to the extent the options might be even remove to simplify things.  We also have the opposite where a SHOULD is implemented but no one users it so eventually, it may be remove as an option.

---

From: Hector <[email-masked]>
Date: Thu, 01 Sep 2011 02:58:57 -0400

Murray S. Kucherawy wrote:

> Ditto.  And I also see a lot of creative interpretation.  There's little we 
> can do to thwart any of those problems; some people read what they want to 
> read and do so in a vacuum.

+1.

I couldn't agree with you more Murray!

When you consider that its not very hard to find mainstream software, 
or even the one they are using to post mail in the list using well 
established IETF protocols that follows RFC2119 to the letter, it 
makes you wonder if there really a problem with RFC2119. I mean, I 
don't see it myself. It reads pretty clear to me, especially section 6 
with that precise non-ambiguous sentence.

    6. Guidance in the use of these Imperatives

    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.

That last sentence is so clear. Maybe the error is not using an 
uppercase MUST NOT and NOT REQUIRED in that last sentence.  Maybe 
software people need logic statements like:

      If X doesn't need Y, then MUST NOT use SHOULD to impose Y.

Honestly, this is like in the DKIM WG where DKIM tried to impose the 
SMTP extension 8BITMIME on SMTP servers with a SHOULD keyword.  DKIM 
tried to make that a MUST but the DKIM WG rejected it, I guess because 
too many SMTP servers did not support 8BITMIME and it wasn't really 
required. I think one person had a problem or something like that and 
because of them, DKIM wanted to force 8BITMIME on SMTP Servers. So 
instead the DKIM WG was yelled at for being RFC2119 illiterates 
because DKIM didn't need a MUST anyway a SHOULD was enough to mandate 
8BITMIME and any SMTP server that didn't support 8BITMIME was broken 
already. So the question here is:

      Does DKIM need 8BITMIME in order to work correctly?

DKIM seems to be working fine without it.

I will say that I don't agree that there isn't much anyone can do to 
thwart these problems.  You really can by just sticking to engineering 
conviction and point out which misinterpretations of RFC2119 can cause 
some serious problems, like with SMTP!

STD10 (RFC821) has a SHOULD NOT drop connection before QUIT is 
negotiated, and it was changed in RFC2821 to a MUST NOT.  I guess 
RFC2119, released during DRUMS, was misread to help provide the 
rational that a SHOULD NOT is really not an option so why not make it 
a MUST NOT? After all there is really no valid reason for not a client 
not to seen a QUIT and all those clients that don't are broken!

But look at that Current Standard STD10 SHOULD to Proposed Standard 
MUST did!  Receivers now are forced to wait for the client to hangup 
for upto 5 minutes and this allowed smart clients to leverage this 
delay to hold the remote host connection to wait for more mail to 
send.  Is that a problem?  Well, maybe not, but those smart clients 
seem to think so warning client operators to:

      - Use it Wisely,
      - Seek Remote Host permission to consume computer resources
      - Do no hold the server too long
      - Its considered Anti-Social, and
      - even foretold that is abuse remote hosts, they might begin
        to drop you and block you!

Even with all those warnings from the smart clients leveraging the 
delays, its ignored and increasingly happening and that server 
defensive prediction is starting to come true - by selectively 
ignoring the one RFC2821 MUST NOT drop connection mandate and 
selective using STD10 SHOULD NOT which RFC2119 says is an option, you 
don't need to follow it.

Its frustrating I must admit when people read RFC2119 with creative 
interpretations to do things it doesn't what you to do!

--
HLS