Anybody can participate in the IETF (Was: Why is IPv6 broken?)

Jeff Wheeler jsw at inconcepts.biz
Mon Jul 11 19:41:49 UTC 2011


On Mon, Jul 11, 2011 at 3:18 PM, William Herrin <bill at 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 at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts




More information about the NANOG mailing list