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
Peter Saint-Andre 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.
http://www.ietf.org/id/draft-saintandre-2119bis-01.txt
Peter
--
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf