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