ietf
[Top] [All Lists]

Re: 2119bis

2011-09-03 06:24:14
Sam Hartman wrote:
"Eric" == Eric Burger <eburger(_at_)standardstrack(_dot_)com> 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.

+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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>