Re: 2119bis

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

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


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