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