On Mon, Jul 11, 2011 at 3:18 PM, William Herrin <bill@herrin.us> wrote:
On the other hand, calling out ops issues in RFCs is a modest reform that at worst shouldn't hurt anything. That beats my next best idea:
I think if this were done, some guy like me would spend endless hours arguing with others about what should and should not be documented in this proposed section, without it actually benefiting the process or the improving the underlying protocol function / specification. Let me give you an example: BGP Messages, which are up to 4KB, need to be expanded to support future features like as-path signing. Randy Bush proposes to extend them to 65,535 octets, the maximum size without significantly changing the message header. This raises a few concerns which I label as operational, for example, off-by-one bugs in code can fail to be detected by a neighboring BGP speaker in some circumstances, because an age-old (since BGP 1) idiot check in the protocol is being silently removed. If you ask me, that is operational and belongs in such a section. I'm sure others will disagree. So we would have a bunch of arguing over whether or not to call this out specifically. Another person believes that expanding the message will affect some vendors' custom TCP stacks, due to window size considerations. I might think that is a developer problem and the affected vendors should fix their crappy TCP implementations, but it might produce unusual stalling problems, etc. which operators have to troubleshoot. Is that an operational issue? Should it be documented? There can be many "operational concerns" when creating or modifying a protocol specification, and every person won't agree on what belongs and what doesn't. However, I do not think the requirement to document them will improve the process or the protocols. It will only add work. Besides, you want "IETF people" who are claimed not to understand operational problems to figure them out and document them in the RFCs? I do not think this will be helpful. More hands-on operators participating in their process is what is needed. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts