On Aug 31, 2011, at 11:55 AM, Hector wrote:
Keith Moore wrote:
On Aug 31, 2011, at 9:57 AM, hector wrote:
Yeah, but its also very very useful to offering what parts of a protocol
are on and off and let operators decide what they want. Don't we already do
this?
yes, it is done to some degree.
Every protocol I have implemented such as PPP, RADIUS, SMTP, TELNET, FTP,
POP3 among the augmented protocols all have some levels of "Features"
presented as SHOULDs and MAYs and those seem necessary where exposed in some
form of configuration options. They might be tweaked for optimal out of the
box performance, so you might not need them. Just look at SMTP extensions,
EHLO features. There are SHOULD for 5 mins timeouts and 5321 states that its
good idea to make this configurable. Came in handy the other day! :) or even
DKIM. Protocol options made available, but fined tune so the operators just
can start using it. But not all will use the setting you prepare for them.
Old protocols that were extended after they were widely deployed are one of the
exceptional cases where SHOULD / SHOULD NOT / etc. make sense to describe
protocol features. They can't always be MUSTs or MUST NOTs because of the
need to maintain backward compatibility with old implementations.
Things like timeout intervals are often labeled as SHOULDs because they aren't
precisely determined, they're educated guesses. So implementors and perhaps
operators should have some leeway to tweak them in light of experience.
The simplest explanation is that people don't bother to read 2119.
How can you make a claim like this with a straight face or I guess fingers?
Because of long experience that indicates that implementors often fail to read
base specifications thoroughly, much less the referenced specifications.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf