Minimum Implementation Requirements (Was: 2119bis)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]