Subject: Re: 2119bis

From: Keith Moore <[email-masked]>
Date: Thu, 1 Sep 2011 07:46:34 -0400

On Sep 1, 2011, at 2:58 AM, Hector wrote:

>   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:

I actually think that the last sentence is overbroad.  There are other defensible reasons to use the 2119 keywords than those enumerated in the document.   And those words can be (and have been) interpreted in such a way as to compel working groups to fail to make design choices, and to permit too many alternative choices in implementations.     

Keith

---

From: "George Willingmyre" <[email-masked]>
Date: Thu, 1 Sep 2011 09:16:47 -0400

I offer for consideration the ISO and IEC  requirements for use of  the 
terms   "Shall" ; Shall not"; "Should"; "Should not" ;  "May"; "Need not" ; 
"Can'; "Cannot" in ISO and IEC standards.

This document explains why ISO/IEC selects "Shall" and "Shall not" rather 
than "Must" and "Must not" to denote mandatory requrrments.

"Do not use "must" as an alternative for "shall". (This will avoid any 
confusion  between the requirements of a document and external statutory 
obligations.)"

It is in the interests of IETF to contemplate and perhaps reference this 
ISO/IEC document somehow in our defnition of the terms below

2.1.  MUST  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  MUST NOT  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.3.  SHOULD  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.4.  SHOULD NOT  . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.5.  MAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

George T. Willingmyre, P.E.
President, GTW Associates
Spencerville, MD USA 20868
301.421.4138
www.gtwassociates.com

---

From: "George Willingmyre" <[email-masked]>
Date: Thu, 1 Sep 2011 09:17:28 -0400

I offer for consideration in the attachment  the ISO and IEC  requirements 
for use of  the
terms   "Shall" ; Shall not"; "Should"; "Should not" ;  "May"; "Need not" ;
"Can'; "Cannot" in ISO and IEC standards.

This document explains why ISO/IEC selects "Shall" and "Shall not" rather
than "Must" and "Must not" to denote mandatory requirements.

It is in the interests of IETF to contemplate and perhaps reference this
ISO/IEC document somehow in our definition of the terms below

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 01 Sep 2011 16:48:51 +0300

George,

We currently use MUST in regular cases and SHALL when we either want not 
to create confusion where non-normative "must" is used or for aesthetic 
reasons, eg. to make a requirement look not so strict as MUST implies 
(even though formally they both have similar force).  I personally use 
SHALL when I mean "it is to be so" and not strict "it is mandatory and 
obligatory and compulsory and <...> to be so".

CAN and CANNOT are an interesting idea, but they have little in common 
with conformance.  Current 2119 language, as primarily used in 
<http://tools.ietf.org/html/rfc1123#page-11>, was intended to clear up 
the requirements on support of particular feature(s).  Yes, it is 
sometimes desired to express possibility and allowance, but IMO simple 
"can" and "cannot" are fine for this purpose.

I don't actually think Annex H of <I don't know what since you're 
providing only part of it> should be referenced in 2119bis.

Mykyta Yevstifeyev

01.09.2011 16:17, George Willingmyre wrote:
> I offer for consideration in the attachment  the ISO and IEC  
> requirements for use of  the
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "George Willingmyre" <[email-masked]>
Date: Thu, 1 Sep 2011 10:00:18 -0400

While we are on the topic of definitions I  hoped to stimulate thinking and we can reach the conclusion that best meets our needs.

The source parent  document is at the URL on the ANSI web site http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/International%20Standardization/ISO/ISO_IEC_Directives_Part2.pdf
ISO/IEC Directives, Part 2  Rules for the structure and drafting of International Standards 

  ----- Original Message ----- 
  From: Mykyta Yevstifeyev 
  To: [email-masked] 
  Sent: Thursday, September 01, 2011 9:48 AM
  Subject: Re: 2119bis

  George,

  We currently use MUST in regular cases and SHALL when we either want not to create confusion where non-normative "must" is used or for aesthetic reasons, eg. to make a requirement look not so strict as MUST implies (even though formally they both have similar force).  I personally use SHALL when I mean "it is to be so" and not strict "it is mandatory and obligatory and compulsory and <...> to be so".

  CAN and CANNOT are an interesting idea, but they have little in common with conformance.  Current 2119 language, as primarily used in <http://tools.ietf.org/html/rfc1123#page-11>, was intended to clear up the requirements on support of particular feature(s).  Yes, it is sometimes desired to express possibility and allowance, but IMO simple "can" and "cannot" are fine for this purpose.

  I don't actually think Annex H of <I don't know what since you're providing only part of it> should be referenced in 2119bis.

  Mykyta Yevstifeyev

  01.09.2011 16:17, George Willingmyre wrote: 
    I offer for consideration in the attachment  the ISO and IEC  requirements for use of  the 
    terms   "Shall" ; Shall not"; "Should"; "Should not" ;  "May"; "Need not" ; 
    "Can'; "Cannot" in ISO and IEC standards. 

     

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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Sep 2011 10:29:14 -0400

Mykyta says...
> I personally use SHALL when
> I mean "it is to be so" and not strict "it is mandatory and obligatory and
> compulsory and <...> to be so".

But, see, this is exactly the sort of problem we're talking about.
You make some sort of semantic (not just stylistic) distinction
between MUST and SHALL.  Yet RFC 2119 does not; it defines them as
synonyms.  In a document that uses these terms according to RFC 2119,
they mean exactly the same thing, and they are interchangeable.

Barry

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 01 Sep 2011 17:35:56 +0300

01.09.2011 17:29, Barry Leiba wrote:
>> compulsory and<...>  to be so".

Yes, you're right - they both have similar force.  But SHALL *looks* 
like being a bit more lightweight variant of MUST; whereas we 
differentiate how they'll be perceived by the human reader, SHALL still 
means that the implementor is obliged to what it is applied to.  I mean 
only stylistic distinction here.

Mykyta

---

From: Pete Resnick <[email-masked]>
Date: Thu, 1 Sep 2011 08:10:02 -0700

On 8/31/11 12:36 AM, Eric Burger wrote:
> 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.
>    

Peter's document makes a change to 2119 that nobody has mentioned yet, 
and I think it is the one that is causing most of the strife in this 
discussion.

Hector is exactly right. SHOULDs are optional. MAYs are optional. What 
he fails to point out is that MUSTs are also optional. They're all 
optional because.....

RFC 2119 does *not* provide *conformance* terms.

Peter's document uses the words "conform" and "conformance". They appear 
nowhere in RFC 2119. RFC 2119 was not coming up with a vocabulary for 
things that MUST be done if one is to conform to a specification. It 
came up with terms for things that MUST be done to interoperate. Or 
SHOULD be done (with a pretty specific meaning of "SHOULD"). Or MAY be done.

If you think that the presence of SHOULD means that you don't have to 
implement a particular thing in a document, you're wrong. SHOULD means 
that "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 is, if you 
don't do what is in the statement marked by "SHOULD", there is a good 
chance you will fail to do something that is "required for 
interoperation" or to engage in "behavior which has potential for 
causing harm" unless you understand the implications.

But if you think that the presence of SHOULD (or MUST) means that you 
*have to* implement a particular thing in a document, you're also wrong. 
There are not protocol police. We don't do conformance checks in the IETF.

You might have a contract with someone who requires you to implement all 
MUSTs (or SHOULDs unless you provide an explanation of why you didn't). 
That's up to them. But the IETF ought not be in the business of 
conformance requirements.

Maybe we do write documents now with conformance requirements. Maybe 
this ship has sailed. Maybe the elephant is on board. I hope not.

Clarifying "SHOULD" is a fine thing. Making it conformance language is 
not. I don't like the 2119bis document in its current form.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Sep 2011 11:51:02 -0400

--On Thursday, September 01, 2011 08:10 -0700 Pete Resnick
<[email-masked]> wrote:

>...
> Peter's document makes a change to 2119 that nobody has
> mentioned yet, and I think it is the one that is causing most
> of the strife in this discussion.
> 
> Hector is exactly right. SHOULDs are optional. MAYs are
> optional. What he fails to point out is that MUSTs are also
> optional. They're all optional because.....
> 
> Peter's document uses the words "conform" and "conformance".
> They appear nowhere in RFC 2119. RFC 2119 was not coming up
> with a vocabulary for things that MUST be done if one is to
> conform to a specification. It came up with terms for things
> that MUST be done to interoperate. Or SHOULD be done (with a
> pretty specific meaning of "SHOULD"). Or MAY be done.

Pete,

This is right, but it is also close to (and hugely clarifies) my
earlier comment about the difference between 2119 language
(about interoperability requirements) and 1122/1123 language
(very much about conformance).  A careful reading of the
introductions to those documents should make this clear.  For
example, "This RFC enumerates standard protocols that a host
connected to the Internet must use,..." isn't a statement about
interoperability -- a host that doesn't support SMTP won't have
interoperability problems unless it decides to use some other
protocol on the relevant port.

Similarly, 

	"However, the specifications of this document must be
	followed to meet the general goal of arbitrary host
	interoperation across the  diversity and complexity of
	the Internet system." 

talks about interoperation, but is actually a conformance
statement -- what one must do and conform to in order to meet an
interoperability goal.

Perhaps we should be saying something like "in a Technical
Specification, 2119-like language maps onto interoperability
conditions; in a Applicability Statement, the same language maps
onto conformance requirements".  Unfortunately, we often mix the
two types of specifications together in single documents, so
such a provision would add, rather than reduce, confusion.

>...
> But if you think that the presence of SHOULD (or MUST) means
> that you *have to* implement a particular thing in a document,
> you're also wrong. There are not protocol police. We don't do
> conformance checks in the IETF.

But we do make conformity statements.   We make an indirect one
every time we say "if some does X, it simply puts that outside
the specification".  That doesn't translate as "won't
interoperate", in part because robustness provisions on the part
of a peer might cause it to work anyway, or because someone gets
lucky, or..., but it certainly translates as "doesn't conform".

> You might have a contract with someone who requires you to
> implement all MUSTs (or SHOULDs unless you provide an
> explanation of why you didn't). That's up to them. But the
> IETF ought not be in the business of conformance requirements.

That is actually a slightly different issue.  We don't do
conformance testing or conformance certification, and I hope we
continue to stay far away from those swamps.  But, until we
start saying, persuasively, "do not use RFCs in procurement
specifications" or "RFCs are unsuitable for procurement
specifications", we are in the conformance requirements business
whether we like it or not.  And, were we to succeed in saying
those things, we would, IMO, swiftly become irrelevant.

> Maybe we do write documents now with conformance requirements.
> Maybe this ship has sailed. Maybe the elephant is on board. I
> hope not.

<insert: loud elephant trumpeting noise>

> Clarifying "SHOULD" is a fine thing. Making it conformance
> language is not. I don't like the 2119bis document in its
> current form.

And, precisely because it muddles a distinction I consider to be
even more important because I find both interoperability and
conformance language in different IETF documents, I don't like
it either.

    john

---

From: SM <[email-masked]>
Date: Thu, 01 Sep 2011 11:12:31 -0700

At 08:10 01-09-2011, Pete Resnick wrote:
>Peter's document makes a change to 2119 that nobody has mentioned 
>yet, and I think it is the one that is causing most of the strife in 
>this discussion.

[snip]

>Peter's document uses the words "conform" and "conformance". They 
>appear nowhere in RFC 2119. RFC 2119 was not coming up with a 
>vocabulary for things that MUST be done if one is to conform to a 
>specification. It came up with terms for things that MUST be done to 
>interoperate. Or SHOULD be done (with a pretty specific meaning of 
>"SHOULD"). Or MAY be done.

Agreed.

Section 6 of RFC 2119 offers some guidance about the use of key 
word.  IETF RFCs are written so that implementations can 
interoperate.  The change in Peter's document was noticed.  It is 
premature to take a shot at the document.

>If you think that the presence of SHOULD means that you don't have 
>to implement a particular thing in a document, you're wrong. SHOULD 
>means that "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 is, if you don't do what is in the statement marked by 
>"SHOULD", there is a good chance you will fail to do something that 
>is "required for interoperation" or to engage in "behavior which has 
>potential for causing harm" unless you understand the implications.

People will attempt to justify anything if they have a reason to do 
so.  If you are feeling lazy, that's a valid reason not to implement 
a "should".  If you believe that "should" is optional, that's also a 
reason to ignore it.  As you are the implementer, whatever you say 
goes.  If your implementation does not interoperate because you have 
not fully understood the implications of your decision, what can I say.

>You might have a contract with someone who requires you to implement 
>all MUSTs (or SHOULDs unless you provide an explanation of why you 
>didn't). That's up to them. But the IETF ought not be in the 
>business of conformance requirements.

Yes.

>introductions to those documents should make this clear.  For

[snip]

>statement -- what one must do and conform to in order to meet an

I'll quote extracts of a "historical" RFC and leave it to the reader 
to decide whether to conform or not:

   "These documents are intended to provide guidance for vendors,
    implementors, and users of Internet communication software.  They
    represent the consensus of a large body of technical experience and
    wisdom, contributed by the members of the Internet research and
    vendor communities."

   "A good-faith implementation of the protocols that was produced after
    careful reading of the RFC's and with some interaction with the
    Internet technical community, and that followed good communications
    software engineering practices, should differ from the requirements
    of this document in only minor ways.  Thus, in many cases, the
    "requirements" in this RFC are already stated or implied in the
    standard protocol documents, so that their inclusion here is, in a
    sense, redundant.  However, they were included because some past
    implementation has made the wrong choice, causing problems of
    interoperability, performance, and/or robustness."

   'An implementation is not compliant if it fails to satisfy one
    or more of the MUST requirements for the protocols it
    implements.  An implementation that satisfies all the MUST and
    all the SHOULD requirements for its protocols is said to be
    "unconditionally compliant"; one that satisfies all the MUST
    requirements but not all the SHOULD requirements for its
    protocols is said to be "conditionally compliant".'

That RFC also mentions the Robustness Principle:

   "Be liberal in what you accept, and conservative in what
    you send"

Between you are me, "no one has ever seriously claimed that being 
liberal in what is accepted requires being stupid". :-)

>such a provision would add, rather than reduce, confusion.

The old wording for an Applicability Statement was:

   "An Applicability Statement specifies how, and under what circumstances, one
    or more TSs may be applied to support a particular Internet capability."

It's easier than using the word "conformance".

The 2119bis discussion seems to be about what is required, what is 
recommended, what is elective, what is for limited use and what is 
not recommended.

The Internet Engineering Terrorist Force will report any sightings of 
pachyderms and white elephants.

Regards,
-sm

---

From: hector <[email-masked]>
Date: Thu, 01 Sep 2011 15:24:08 -0400

Pete,

The last sentence is section 6, IMV, is the "protection shield" 
against overzealous authors, technology leaders, etc  imposing 
protocol methods or "Total Solution" concepts.  It also serves as the 
ultimate guideline for the author at the minimum expectation to 
hopefully guarantee success.

I agree the Conformance terms is good.  But this RFC2119 is messing 
one thing, at the very top somewhere it needs to touch base with the 
critical idea of:

    Minimum Conformance
    Minimum Requirements
    Minimum Implementation Requirements

etc.

In my view, and honestly its hard to imagine how anyone can really 
survive writing or implementing protocols especially as the complexity 
increases, take any RFC, if you can't make the protocol work by 
removing all the SHOULD|MAY [NOT] and just leaving behind the MUST 
[NOT], then it really a bad specification and will drive people nuts 
trying to get it right.  Really, when a protocol [specifications] gets 
so complex with intertwining semantics, many in conflict as well, the 
only way to get started is to put out its minimum requirements and 
start from there.

So RFC2119 should being with a top section that deals with two 
essential ideas on both end (Just text, better writers welcome)

   Authors:

       Focus on your Minimum Implementation Requirements
       using the RFC2119 Conformance Terms

   Implementors:

       Follow the Author's Minimum Implementation Requirements

Its a touch challenge because authors can just use MUST most of the 
time, and I believe that is part of the issue.  Yet at the same time, 
with all the optional pieces, the protocols depending on a suite of 
optional pieces, well, begin to have a low efficiency, low payoff, or 
just doesn't work to the expectation of its authors. Works great when 
all the parts are used, but that hope of total success becomes 
disappointing. Isolation begins - works for that group, but not the rest.

--

Pete Resnick wrote:
>> 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.
>>

---

From: Hector <[email-masked]>
Date: Thu, 01 Sep 2011 15:25:24 -0400

Pete,

    Minimum Conformance
    Minimum Requirements

etc.

   Authors:

   Implementors:

--

---

From: hector <[email-masked]>
Date: Thu, 01 Sep 2011 15:44:08 -0400

I think the focus should be on Minimum Implementation Requirements to 
even make a protocol in the first place.  IMV, this will help separate 
the ambiguity.  It helps the author and implementator keep the eye on 
the prize - communications.

Just consider, open RFC2119[bis] and I don't think you will even find 
the word MINIMUM.

This is why I always viewed RFC 1123 as the "Holy Bible" because it 
did just that with its Minimum Requirements focus for many of the 
internet hosting protocols.  Its what help John produce RFC2821 and 
probably why SMTP is very successful.

IMV, this is missing in many of the RFCs I read that gets twisted from 
over time, and worst, when items are thrown in at the last minute 
(last call).

--
HLS

---

From: Melinda Shore <[email-masked]>
Date: Thu, 01 Sep 2011 11:45:04 -0800

On 09/01/2011 11:25 AM, Hector wrote:
> trying to get it right.

Can anybody point to an incident in which lack of clarity around
2119 language caused problems, and it was determined that 2119
itself was the problem and not authors or editors being careless?

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Sep 2011 07:59:50 +1200

On 2011-09-02 07:45, Melinda Shore wrote:
...
> itself was the problem and not authors or editors being careless?

(or implementors being careless)

Indeed. I'm in favour of leaving "good enough" alone and not striving
for perfection, which is impossible anyway.

   Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 1 Sep 2011 15:11:21 -0500

Hi, Melinda,

> itself was the problem and not authors or editors being careless?

My recollection is that, at least since the early 2000s, most "problems" 
were encountered with Last Call/Gen-ART (and probably other review team) 
comments taking forms like

"Why is this SHOULD not a MUST?", or the ever-popular
"Why is this Informational draft using 2119 language??

There are probably variants I don't remember (I stopped being an active 
Gen-ART reviewer when I began serving on the IAB, and I've slept since 
then).

In my comments on 2119bis 
(http://www.ietf.org/mail-archive/web/ietf/current/msg68885.html), I was 
suggesting that clarifications might head off some of these recurring 
conversations.

At this point, I would be fine with a draft (of any flavor - obsoleting, 
updating, or just an IESG statement) that addresses whether these questions 
are reasonable questions. I don't have a deep need to add the (mostly 
reasonable) suggestions that have been made for new terms.

If the IESG thinks that's a reasonable thing to do, they can make a call 
about the particular flavor, just fine ...

Spencer

---

From: Hector <[email-masked]>
Date: Thu, 01 Sep 2011 16:29:26 -0400

Keith Moore wrote:
>> 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:
> 
> I actually think that the last sentence is overbroad.  There are 
> other defensible reasons to use the 2119 keywords than those enumerated 
> in the document.   And those words can be (and have been) interpreted in 
> such a way as to compel working groups to fail to make design choices, 
> and to permit too many alternative choices in implementations.
> 
> Keith
> 

Keith, I feel ya.

I once presented a paper at a trade conference presenting the idea of:

       Cooperative Competition  (COCOMP)

It touch based with the growing industry of competitors trying to work 
well around new standards of communications. The issue of alternative 
choices in implementations was becoming harder to support, more 
complex, etc.  Especially on the mail side which was rapidly changing 
and each adding their own twist or proprietary feature that added 
value to their product lines. COCOMP proposed the central idea that 
there are ways to have your cake and eat it as long as we have:

   a) A understanding of minimum standard requirements that NO ONE can
      twist and turn, and

   b) and also offer added value, if you wish, using a standard
      method to extend your offerings for implementators to follow,
      if they want.

The MUST and the SHOULD|MAYs.

So the issues we see here has always been the case and you can't avoid 
them. When you have technology leaders that many follow, you have to 
be careful that quite often they offer extensions that only apply to 
their product line.

That is what that last sentence pretty much touches base with, its a 
great insight of the realities of dealing with different implementators.

I think "Cooperative Competition" is the name of game here. Its why 
all the vendors get together, that compete in the market place, but we 
hopefully cooperative for a common goal.

RFC2119 needs to focus on establishing the minimum conformance 
requirements for a protocol or a suite of protocols yet we need to 
understand that not everything is required or need to be imposed 
across the board because its not just about one mainstream vendor or 
technology leader interest but the entire community interest. I can't 
impose my product features on anyone and its not proper for another 
vendor to impose its wishes on others. Even if they feel its for the 
"Common Goal" not everyone is going to agree its a "All or Nothing" 
concept.

--
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Sep 2011 13:45:17 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
> Sent: Thursday, September 01, 2011 12:45 PM
> To: [email-masked]
> Subject: Re: Minimum Implementation Requirements (Was: 2119bis)
> 

+1.

As we've defined SHOULD and MUST in RFC2119, they lay out conformance requirements.  I still don't see what's broken.

If the "Why is this a SHOULD and not a MUST?" question that Spencer pointed out is a common one, then guidance to authors might be an appropriate addition.  But I don't think the definitions as they currently stand are at all ambiguous.

---

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

> itself was the problem and not authors or editors being careless?

Melinda, the closest incident apropo this is what happen in the DKIM 
WG where a SHOULD for the optional SMTP extension 8BITMIME was argued 
that based on RFC2119, a SHOULD is enough to mandate SMTP servers to 
implement it, despite the fact that many didn't and it wasn't required 
for DKIM to work. I personally took exception that a group of people 
were called out as RFC2119 illiterates and that any SMTP server that 
did not support 8BITMIME was non-compliant and broken already.

So personally don't see a problem with RFC2119, but a new perception 
by overzealous authors using RFC2119 to impose methods on others.

I can only assume its due to the growth of new proposals with a high 
dependency on a suite of optional protocols.  Efforts to consolidate 
and integrate well established but optional protocols to make thinks 
work better as a whole.  ESMTP, DKIM, IDN, IPv6, IPSEC etc, etc, etc, 
all work better if "everyone" following a "All or nothing" methodology 
- one way to encourage change is to change the rules of "conformance."

--
HLS

---

From: [email-masked]
Date: Thu, 01 Sep 2011 14:22:32 -0700 (PDT)

> If the "Why is this a SHOULD and not a MUST?" question that Spencer pointed
> out is a common one, then guidance to authors might be an appropriate
> addition. 

The fact that reviewers sometimes question the choice between a SHOULD and MUST
(in either direction) demonstrates absolutely nothing in and of itself. In fact
I see such questions as entirely healthy and appropriate, indeed, if they
didn't come up fairly regularly I'd strongly suspect we have a much bigger
problem with our specifications not taking operational realities into account.

Now, if when such questions arise the eventual outcome is often that the SHOULD
gets changed to a MUST or vice versa, then we may have an issue with using the
terms that needs to be addressed. Or we may not - there are plenty of other
possible explanations.

But we can save the root cause analysis until there is at least some evidence
that compliance terms are regularly being *changed* as a result of review
feedback. AFAIK such evidence has not been introduced.

				Ned

P.S. And if anyone seeks to provide such evidence, please remember that
data is not the plural of anecdote.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 2 Sep 2011 00:14:28 +0200

On 30 August 2011 10:05, Eliot Lear wrote:

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

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

If there are compelling reasons to fix a BCP "somehow", as it was
the case when the Trust was created and the IPR issues were fixed,
it was obviously possible to create tons of new BCPs updating old
BCPs.

Maybe RFC 2119 has enough valid (= verified + 499) errata for an
update.  OTOH many folks here agree that it should be kept "as is",
because folks here do not agree *how* to fix it, e.g., nobody
proposed to fix only the errata, and they also don't agree *what*,
if anything (excl. errata), is broken.

Maybe Peter can propose a completely new "mustard RFC" as a kind
of process experiment, where authors are free to use this new RFC
to define their mustard, or stick to "RFC 2119 cum errata".

It was never REQUIRED to use RFC 2119 terminology, when authors
don't like it and have other ideas.  I recall how hard it was to
switch RFC 5321 from some "proprietary" terminology in RFC 2821 to
the common RFC 2119 terminology, when the author mumbled about the
consensus of some prehistoric WG, which apparently decided that it
is a "good" idea to *copy* RFC 2119 definitions instead of simply
reference RFC 2119.  By popular demand RFC 5321 got this right.

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

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

That's simple, I know how to find Brian's [PROCDOCS], and there I'd
find all inhabitants of this zoo...

> Let's not repeat that fiasco with 2119.

...okay, I certainly don't insist on it.  But as long as nobody
offers to fix only the errata in 2119bis anything more ambitious
should leave RFC 2119 alone, no "obsoleted by" and no "historic".

-Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 2 Sep 2011 00:32:18 +0200

On 30 August 2011 11:14, Mykyta Yevstifeyev wrote:

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

That's better, but otherwise still near to "second worst proposal".

RFC 2026 section 5.1 does not mention 6.3 (revising), it mentions
6.4 (retiring).  If Peter creates a new RFC (independent of 2119),
and it turns out that everybody prefers the new RFC, then the old
RFC 2119 should be retired.

But as noted by Eliot, of course I have no idea if this part of
RFC 2026 happens to be one of the few things that are still valid,
I only know where I'd find the updates if I'd need to find them.

This 2119 rathole is a major distraction from various Last Calls,
hopefully the IESG has good filters to find Last Call comments on
this list.

-Frank

---

From: Hector <[email-masked]>
Date: Thu, 01 Sep 2011 18:53:47 -0400

> for perfection, which is impossible anyway.

My assessment.

At some top level, a good bit of this is a  "technical writing" style 
issue. The IETF RFC document model blends two phases of the software 
engineering process:  Functional Requirements (what we want) and 
Technical Specification (how its done). Its a blessing and curse.  We 
have a wide degree of multiple discipline audience so you get input 
from a wide degree of people. However, we often get into the mess of 
satisfying different functional needs and the technical specification 
gets really complex.  To me, thats an experience factor as you can 
clearly see this in RFC different writing styles and you can also see 
specific authors get better at it.   So it might help for IETF to help 
remind authors of the distinction of the multiple disciplines and to 
better separate or organize the functional and technical 
specifications parts of the RFC. If a charter is not going to do it 
with separate functional requirements and technical specification 
RFCs, the author should do it within the one RFC.

Second, minimum requirements need to be very clear and hopefully 
documented in its own section of a RFC.  It should not take a 
implementator to carefully analyze every sentence, every word or do 
other minding reading activity to figure out what the Author intent 
is.   The AUTHOR can not assume that every reader has been part of 
every stage during the WG and understand every little detail and 
reason why this or that is the way it is.  Overall, citing the minimum 
requirement very quickly in a RFC helps to resolve many of those 
unsure readings.    This is where the RFC2119 can help I believe by 
help authors focus on this.

Third, I think it is still very important that the insights provided 
in Section 6 regarding imposing methods that are not required is 
extremely important. When author gain realization of this realistic 
insight, it will help them better focus on their protocol engineering 
and its minimum requirements.  I don't believe there is no danger here 
because if an Author believe he can use use MUST all the time, he will 
find out very quickly how much lower his RFC is less adopted. Yet, 
when it carefully consider this, he will be better prepare the RFC for 
maximum support.

Finally, I don't think we can do much about this, but if only to 
highlight the problem,  the IETF Rough Consensus (RC) Decision Tool is 
a major factor in RFC conformance conflicts.  When a decision is made 
based on RC, especially one deciding SHOULD|MUST, its increase the 
odds of getting different usages.  Here is one example scenario:

     - Very Rough Consensus choose MUST,
     - Chair or AD overrides this to SHOULD due to the obvious chaos,
     - Reluctantly, MUST advocates accept SHOULD because,
     - MUST advocates will always implement the SHOULD,
     - Overtime, they become dependent on the SHOULD operation,
     - But has interops problems with wide support across the board.

So what do MUST advocates do?

    MUST people begin to say RFC2119 SHOULD means you MUST implement it
    and only an "Act of G-D" reason is valid for not implementing the
    SHOULD. And not only MUST implement, it must also be a MUST-USE
    by operators.

One can say, "RC would of worked if the Chair/AD didn't change it", 
but then you have the problem Pete stated,  people on the SHOULD side, 
including those who felt a MAY was more appropriate begin to ignore 
the MUST especially if possible to work without it and offer it as an 
option to operator to turn ON or OFF just in case there is a problem 
went its not enabled.

RC may not be the issue, but it might help if its use carefully 
measure how much a MUST is required to get the job done.

--
hls

---

From: Melinda Shore <[email-masked]>
Date: Thu, 01 Sep 2011 15:00:47 -0800

On 09/01/2011 02:53 PM, Hector wrote:
> RC may not be the issue, but it might help if its use carefully measure
> how much a MUST is required to get the job done.

You appear to be advocating for more rigorous document review, not
for a 2119 revision.

Melinda

---

From: Hector <[email-masked]>
Date: Thu, 01 Sep 2011 19:16:25 -0400

> You appear to be advocating for more rigorous document review, not

Its a circular management issue.  I personally don't believe there is 
a problem with RFC2119, and the different interpretations only 
reflects the recognition there are new implementation issues (or 
needs). Some of this are resolved with relaxed reviews and 
controversial (appeal material) decisions. Will the new Two-Level 
Maturity process perpetuate the problem?

I think RFC2119 can be fine tuned to recognize the new issues without 
fundamentally changing its original intent.  Maybe it can help to 
reduce reviewing pressures and help the new two-level maturity be more 
successful.

---

From: Hector <[email-masked]>
Date: Fri, 02 Sep 2011 01:04:11 -0400

I'm just winging this.

What do you think about having a Conformance Level model ?

   Conformance Level 1 (CL1) - MUST [NOT] - minimum requirement
   Conformance Level 2 (CL2) - CL1, SHOULD [NOT]
   Conformance Level 3 (CL3) - CL1, CL2, MAY [NOT]

It allows author to declare in the RFC (abstract, intro perhaps) the 
level of conformance he expects, i.e. "This Protocol only works best 
with CL2 implementators."  When an implementator sees that, it might 
help in its decision making process on how much is supported.  This is 
also help remove the stigma of existing implementations being labeled 
non-compliant, which quite frankly, those are "fighting words!" :)

Of course, out of the gate, all protocols must be a Conformance Level 
1 protocol :)

Spencer Dawkins wrote:
> updating, or just an IESG statement) that addresses whether these 
> questions are reasonable questions. I don't have a deep need to add the 
> (mostly reasonable) suggestions that have been made for new terms.
>

---

From: "t.petch" <[email-masked]>
Date: Fri, 2 Sep 2011 11:18:43 +0200

----- Original Message -----
From: "Spencer Dawkins" <[email-masked]>
To: "Melinda Shore" <[email-masked]>; <[email-masked]>
Sent: Thursday, September 01, 2011 10:11 PM
> "Why is this Informational draft using 2119 language??

This sounds like RFC2119 working perfectly.  The WG is saying that this element
of the protocol SHOULD (as defined in RFC2119) be ...
whereas the reviewer is saying that the protocol would be improved if this
element of the protocol MUST (as defined in RFC2119) be ....

No evidence of a problem with RFC2119 there.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Fri, 2 Sep 2011 11:42:24 +0200

----- Original Message -----
From: "George Willingmyre" <[email-masked]>
To: "Mykyta Yevstifeyev" <[email-masked]>; <[email-masked]>
Sent: Thursday, September 01, 2011 4:00 PM
Subject: Re: 2119bis

While we are on the topic of definitions I  hoped to stimulate thinking and we
can reach the conclusion that best meets our needs.

The source parent  document is at the URL on the ANSI web site
http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Internation
al%20Standardization/ISO/ISO_IEC_Directives_Part2.pdf
ISO/IEC Directives, Part 2  Rules for the structure and drafting of
International Standards

<tp>
And ......

They have their terms in Appendix H, and while we agree on MUST/SHALL, we
disagree on SHOULD; ISO IEC have a much weaker interpretation of 'should' than
the IETF.  No doubt it works for them as ours does for us.

Tom Petch

</tp>

  ----- Original Message -----
  From: Mykyta Yevstifeyev
  To: [email-masked]
  Sent: Thursday, September 01, 2011 9:48 AM
  Subject: Re: 2119bis

---

From: Sam Hartman <[email-masked]>
Date: Wed, 31 Aug 2011 23:10:58 -0400

>>>>> "Eric" == Eric Burger <[email-masked]> writes:

    Eric> This highlights an interesting issue as an RFC goes from PS to
    Eric> IS.  I would offer that most SHOULDs in a document will, if
    Eric> there are real implementations out there, migrate to MUST or
    Eric> MUST NOT.
    Eric> On Aug 31, 2011, at 9:57 AM, hector wrote:

Hmm.  Most of the times I use SHOULD I'd expect them to stay SHOULD.
SHOULD doesn't mean "this feature is desired," it means "do this unless
you have justification for doing something else." There are a few cases
(new algorithms) where you mean SHOULD+ (we'll move to MUST in the
future) but often you mean do this unless you're in a constrained
environment, or you know you won't need it or something like that. In
those cases, SHOULDS tend to stay SHOULDS.

---

From: Hector <[email-masked]>
Date: Sat, 03 Sep 2011 07:24:57 -0400

+1.

Eric, I was referring to the implementation level where one can afford 
to make streamlining decisions overtime when options become stable and 
never change its state. It can be removed to make things easier out of 
the box, but I would not not propose it as a spec change.

Beside the obvious backward compatibilities issue, changes can be 
leverage to perform different functional needs than what was not the 
original intent.

One real example is with SMTP just recently realized how a SHOULD to 
MUST change has been leveraged.

STD10 has a SHOULD NOT drop connection before QUIT negotiated, changed in
RFC2821 (now RFC5321) to a MUST NOT.

We are observing a lost of CPU idle time and resources (channels) 
consumption with anonymous clients intentionally holding connections 
open while for additional mail transactions to arrive and send.  The 
only receiver defense to control the abuse is to violate RFC5321 by 
dropping the client after the first transaction.

Note: No intent to highlight this issue, just an example of changing a 
SHOULD to a MUST not necessarily due to long term stabilization, but 
for new functional needs have repercussions.

--
HLS

---

From: John C Klensin <[email-masked]>
Date: Sat, 03 Sep 2011 08:59:37 -0400

--On Wednesday, August 31, 2011 23:10 -0400 Sam Hartman
<[email-masked]> wrote:

>     Eric> This highlights an interesting issue as an RFC goes
> from PS to     Eric> IS.  I would offer that most SHOULDs in a
> document will, if     Eric> there are real implementations out
> there, migrate to MUST or     Eric> MUST NOT.
> Hmm.  Most of the times I use SHOULD I'd expect them to stay
> SHOULD. SHOULD doesn't mean "this feature is desired," it
> means "do this unless you have justification for doing
> something else." There are a few cases (new algorithms) where
> you mean SHOULD+ (we'll move to MUST in the future) but often
> you mean do this unless you're in a constrained environment,
> or you know you won't need it or something like that. In those
> cases, SHOULDS tend to stay SHOULDS.

+1

Exactly right.   Indeed, if I agreed with Eric's view, I'd think
we should abolish SHOULD and SHOULD NOT (almost) entirely,
replacing them with temporary qualifications for MUST that would
convey "not quite sure about this yet, but MUST is certainly our
intention".  "Tentative"  or "Provisional", with appropriate
IETF-specific definitions, would be two such words.

Note that this loops back to the the discussion about
conformance and certification.  The standards bodies whose
principal concerns about about conformance and certification
cannot use what we call SHOULD because one cannot build a
conformance test around a case that might have exceptions,
especially exceptions that are not completely enumerated.  They
can, and do, use what we periodically describe with language
like "MUST implement but are not required to configure in
operation" (and, to add to the confusion, sometimes call that
"SHOULD use"), but the conformance test then checks only for the
implementation and, perhaps, for the presence of the knob.

    john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 3 Sep 2011 22:34:04 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: Saturday, September 03, 2011 6:00 AM
> To: Sam Hartman; Eric Burger
> Cc: IETF discussion list
> Subject: Re: 2119bis
> 

We do have a few RFCs that have a subsection called "Conformance Requirements" or something close to it.  Section 3 of RFC3464 comes to mind, and it's not that old.  I take it the current posture in the IETF is that such things are actually a bad idea, or at least not something we encourage?

For especially large or complex protocol documents, it might not be a bad idea to have all the MUSTs, SHOULDs and MAYs enumerated in one place as a summary for implementers to use as a checklist, and they can then consult the rest of the document for the details about how to implement each point.

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 4 Sep 2011 11:22:28 +0000

I agree with several who have already voiced objections to obsoleting 2119.

On the other hand, a BCP on conformance keyword usage could be useful.

In addition to the clarification of the use of SHOULD 
(that is being discussed at length),
I would like to see a clarification of the difference between MUST and metaMUST
(or supportMUST or interopMUST) and regular/meta similar terms for SHOULD, MAY, etc.
and examples of their use.

By that I mean the difference between
     MUST:   When sending a foo message you MUST include the bar TLV
 metaMUST:   All implementations MUST support the bar TLV
the latter meaning that bar is not always sent, 
but if sent it must be properly processed.

There is an (AFAIK unwritten) rule about metaMUST, 
that I believe SHOULD be documented.
If the protocol allows several options for doing something,
precisely one MUST be a metaMUST, and the others metaMAYs.

Note that the MUST in the previous sentence is MUST about
the use of a metaMUST, and is this a metametaMUST.
I am not sure if the previous SHOULD is a meta^2SHOULD or a meta^3SHOULD.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Tuesday, August 30, 2011 00:37
To: IETF discussion list
Subject: 2119bis

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: Hector <[email-masked]>
Date: Sun, 04 Sep 2011 15:13:13 -0400

> IETF-specific definitions, would be two such words.

I like those terms, Tentative, Provisional, perhaps also Exploratory, 
Experimental.

But consider, if SHOULD [NOT] was to be abolished, wouldn't MUST [NOT] 
now be redundant and implied in functional and technical semantics?

It seems it will reduce to usages of key words such as: IMPLEMENT, 
USE, NEGOTIATE, IFF, DON'T, CAPABLE, DEPEND and perhaps PLEASE and 
their negatives.

    PLEASE IMPLEMENT X, Y, Z. PLEASE NEGOTIATE for X first and PLEASE
    USE Y IFF peer implementators are not CAPABLE of Z.

       IMPLEMENTATION NOTE:  PLEASE DON'T DEPEND on X, Y, or Z if
       peer implementation are not capable of X, Y or Z.

Jokes to the side, IMO, I don't see how it would be possible to impose 
things on implementators deciding on items that are not necessary, 
overdone, "candy" and perhaps Pareto's principle comes into play - It 
works 100% of the time for the minimum required which represents 80% 
of the total capabilities.

The situation here appears to be features in the remaining 20% now 
become more necessary overtime and in hindsight, we see there are a 
lot "Oops" that didn't make those things part of the minimum 
requirements.

Will any future rewording of "compliance" docs change this or make it 
better?  I don't seem to think so because as we all know, perfection 
is not possible - we need to have those knobs and switches.  Making 
everything a MUST [NOT] or wording things to steer people to 100% 
implementation will most like raise the adoption barrier and  and we 
end up relaxing things anyway just to get people to consider an RFC.

My opinion.

--
HLS

---

From: Hector <[email-masked]>
Date: Sun, 04 Sep 2011 15:56:32 -0400

Michael Richardson wrote:
>>>>>> "Keith" == Keith Moore <[email-masked]> writes:
>     >> In my view, SHOULD are user protocol options to set.
> 
>     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.

+1

The issue here, in my technical opinion, is the difference in the 
functionality.

With HTTP, you have the design ergonomics options for interactive I/O 
with the user to allow the user (giving him the benefit of doubts) to 
decide.

With SMTP, it is inherently designed for automated decisions.  I guess 
one can suggest it is technically possible by having user decisions 
predefined.  But for SMTP-TLS, we have a chicken and egg design 
problem - what comes first the SYSTEM or the USER?  SMTP-TLS is 
decided before the USER is known, but is not inconceivable to have a 
belated automated SMTP-TLS state decision made until the target user 
is known.

--
HLS

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 09:34:13 -0600

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

Based on the feedback received, I do not plan to pursue further work on
that Internet-Draft. However, given that the IETF Secretariat and the
RFC Editor team already accept documents that include "NOT RECOMMENDED"
in the RFC 2119 boilerplate, does anyone see harm in verifying the
aforementioned erratum?

Peter

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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 12 Sep 2011 19:41:56 +0300

> in the RFC 2119 boilerplate, does anyone see harm in verifying the

In strict accordance with 
<http://www.ietf.org/iesg/statement/errata-processing.html> this erratum 
should be Held for Document Update:

> 5. Typographical errors which would not cause any confusions to 
> implementation or deployments should be Hold for Document Update.
> 6. Changes which are simply stylistic issues or simply make things 
> read better should be Hold for Document Update. 

However, as far as the corrected boilerplate is widely used, I think 
there is no harm in marking it as Verified.

Mykyta Yevstifeyev

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Sep 2011 12:41:31 -0400

--On Monday, September 12, 2011 09:34 -0600 Peter Saint-Andre
<[email-masked]> wrote:

>> 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.
>> 
> Based on the feedback received, I do not plan to pursue
> further work on that Internet-Draft. However, given that the
> IETF Secretariat and the RFC Editor team already accept
> documents that include "NOT RECOMMENDED" in the RFC 2119
> boilerplate, does anyone see harm in verifying the
> aforementioned erratum?

Sigh.

Sorry to make this more complicated but, IMO, the error in 2119
and, to some extent, recent practice, is in permitting
"RECOMMENDED" as a synonym for "SHOULD", not in failing to
permit its opposite.   If one goes back to 2026, there is a
fairly clear separation between Technical Specifications" and
interoperability requirements (terminology for which appears in
2119) and the "Requirement levels" and conformance requirements
of Applicability Statements.  Those levels, as specified in
Section 3.3 of RFC 2026, are "Required", "Recommended",
"Elective", "Limited Use", and "Not Recommended".  

According to 2026, those requirement levels in AS documents
apply to entire TSs but I think we have sometimes relaxed that a
bit into statements about features within a TS.   If AS
requirement  level statements apply only to full TS
specifications, the use for "RECOMMENDED" as a statement about
interoperability requirements, synonymous with "SHOULD" is
merely somewhat confusing.  If we are going to sometimes have
ASs that make statements at the feature level, then it is
disastrously so because the same term has an interoperability
meaning in one context, a conformance meaning in another, and
there may be no reliable way to deduce the difference.

To provide an additional focus for this, I've just filed
proposed erratum 2969
(http://www.rfc-editor.org/errata_search.php?rfc=2119&eid=2969)
that reflects the comments above.  You now have a choice about
which one to approve :-)

regards,
    john

---

From: Hector <[email-masked]>
Date: Mon, 12 Sep 2011 15:50:52 -0400

John C Klensin wrote:

> permit its opposite.   

hmmmmmm,  now I am even more confused!!!  Does this mean people could 
now add this errata reference in their new documents? Does it mean 
authors SHOULD|MUST remove and stop all usage of RECOMMENDED in their 
current and future docs?

How about an Errata to the Errata? :)

--
HLS

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Sep 2011 08:28:04 +1200

John,

I don't share your confusion. I do feel that to be able to
construct reasonably pleasant sentences, we need both the verb
SHOULD and the adjectival participle RECOMMENDED, and their
negatives, in various circumstances.

I could propose an alternative erratum, adding MANDATORY,
but I won't; it's NOT MANDATORY to increase confusion.

Regards
   Brian

---

From: SM <[email-masked]>
Date: Mon, 12 Sep 2011 13:21:39 -0700

Hi Peter,
>in the RFC 2119 boilerplate, does anyone see harm in verifying the

One of the properties of a RFC is immutability.  In practice, this 
means that if you make a mistake and invert a bit in your 
specification, everyone else implementing the specification makes the 
same mistake.  This ensures that implementations interoperate.

In the case of "NOT RECOMMENDED", as you mentioned, there are 
documents that include the term and the term is defined in Section 4 
of 2119.  There is also a note that says that
the force of the words is modified by the requirement level of the 
document.  Given that there could be side effects, I suggest 
considering the erratum as a change.

The only "harm" here is the erratum as it paves the way for different 
interpretations when it is flagged as verified.

Regards,
-sm

P.S. According to the The Chicago Manual of Style, an erratum is a 
device to be used only in extreme cases where errors severe enough to 
cause misunderstanding are detected too late to correct in the normal 
way but before the finished book is distributed.

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Sep 2011 16:51:54 -0400

> but I won't; it's NOT MANDATORY to increase confusion.

Brian,

I don't think this is worth pushing very hard, nor spending a
lot of time on.  If Peter wants to approve the other (499)
erratum in the name of editorial consistency, I will lose
exactly zero sleep over it.

However, as things have evolved, our goal is apparently to turn
the terminology of 2026 and 2119 into very specific terms of art
with clear boundaries.  Personally, I don't particularly like
such efforts.  As you know from other discussions, I generally
believe that trying to force our increasingly-complex protocols
and protocol interactions into rigid categories (whether those
are Proposed/ Draft/ Full, MUST/ SHOULD / MAY and their
negations, or something else), presumably by the method of
Procrustes because nothing else really works, does not serve us
well.  But, if we are going to do it, then lists of synonyms and
near-synonyms for those terms of art really don't help us.   

Even if use of the specific terms sometimes leads to awkward
sentence constructions, so does trying to avoid those terms when
they are not appropriate.  I note that
draft-hansen-nonkeywords-non2119 takes us into the realm of
personifying protocols to the extent of talking about what they
"need to" do, a construction that would have given the people
who taught me --and probably you-- how to write at least a bad
case of the creeps and possible outrage.

So, again, if we really intend terms of art, rather than
slightly-less-informal prose, I think we would be better off
with one term per concept/category and living with it.  If we
really intend slightly-less-informal prose --which is the way I
took the intent of 2119 when it was first written (perhaps
erroneously)-- then none of this discussion and the
corresponding hair-splitting makes much difference and we should
just make 2119 internally consistent and move on.

YMMD.

    john

---

From: Hector <[email-masked]>
Date: Mon, 12 Sep 2011 18:38:29 -0400

A fundamental fact is that the IETF RFC document models are for a 
multiple-disciplined environments of people, at least most are writing 
with a mix view of different audiences.    Not too many break it down 
to different functional vs technical specification levels.

A Manager, Docs, Help, Support, Admin person might read SHOULD 
different in how its applied than perhaps a software/author person in 
the finer details in the how things work or behave differently than 
what was interpreted at higher levels.

IMV, this is all about good software or component engineering methods, 
and if one wishes to follow a trend, take a look at industry efforts, 
such as with Microsoft SE efforts with Code Contracts which is to 
basically provide a meta language to make sure functional I/O 
interfaces are well defined especially with well defined exceptions.

Here is wikipedia's description of this growing direction with 
developers that increasingly need all the help they can get in an 
extreme complex integrated world of "Plug and Play" pieces:

     http://en.wikipedia.org/wiki/Design_by_contract

    The central idea of DbC is a metaphor on how elements of a
    software system collaborate with each other, on the basis of mutual
    obligations and benefits. The metaphor comes from business life, 
where
    a "client" and a "supplier" agree on a "contract" which defines for
    example that:

    o The supplier must provide a certain product (obligation) and
      is entitled  to expect that the client has paid its fee (benefit).

    o The client must pay the fee (obligation) and is entitled to get
      the product (benefit).

    o Both parties must satisfy certain obligations, such as laws and
      regulations, applying to all contracts.

Is there such an ideas for "IETF Standards Engineering & 
Implementation Contracts?"  I think that is what we are trying to do 
here with RFC2026, RFC2019 all along.

But to me, the only way you can even begin this, is for the author to 
first layout and for the reader to extract what are the minimum 
requirements of a RFC protocol specification - that is the first CODE 
CONTRACT anyone can even first thing about.

--