Re: 2119bis

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.
> but that's not, in general, a desirable practice. (though there are 
> cases where it can be justified).
While I agree long time engineering & fine tuning, options become 
stable, deprecated or obsolete and  short of an finely tuned embedded 
system, turnkey system, even smart phone/devices, and not really even 
then, I hardly seen any protocol with options not implement with some 
level of exposure deemed necessary.
> 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? That invites useless conflicts like "get a dictionary" for 
the word Recommended,  or just plain old accepting the simple idea 
that after determining all full implications above and beyond what was 
necessary is a valid reason to IGNORE the recommendation.
--
HLS

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf