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

[William Herrin <bill () herrin us>]

On Sun, Jul 10, 2011 at 1:41 PM, David Miller <dmiller () tiggee com> wrote:
> On 7/10/2011 12:16 PM, Jeroen Massar wrote:
> > You are on NANOG out of your own free will, the same applies to the
> > IETF. If you don't participate here your voice is not heard either, just
> > like at the IETF.
>
> True, anyone can participate in the IETF processes.  However, if key players
> do not participate, then something is broken.  I will take my lumps for not
> participating.
>
> My point was - "If fingers can be pointed at both sides, i.e. operators and
> IETF, then both sides are to blame."

Hi David,

This is a process problem, not an individual problem.

The IETF is run by volunteers. They volunteer because they find
designing protocols to be fun. For the most part, operators are not
entertained by designing network protocols. So, for the most part they
don't partiticpate.

This is not going to change. And it also isn't the problem -- people
who enjoy the work tend to do better work.

The problem is that the IETF routinely exceeds the scope of designing
network protocols. Participants in the working groups take what are
fundamentally operations issues unto themselves. They do so knowing
they lack adequate participation by network operators. And the process
that leads to RFCs offers inadequate checks and balances to mitigate
that behavior.

Consider, for example, RFC 3484. That's the one that determines how an
IPv6 capable host selects which of a group of candidate IPv4 and IPv6
addresses for a particular host name gets priority. How is a server's
address priority NOT an issue that should be managed at an operations
level by individual server administrators? Yet the working group which
produced it came up with a static prioritization that is the root
cause of a significant portion of the IPv6 deployment headaches we
face.


I don't know the whole solution to this problem, but I'm pretty sure I
know the first step.

Today's RFC candidates are required to call out IANA considerations
and security considerations in special sections. They do so because
each of these areas has landmines that the majority of working groups
are ill equipped to consider on their own.

There should be an operations callout as well -- a section where
proposed operations defaults (as well as statics for which a solid
case can be made for an operations tunable) are extracted from the
thick of it and offered for operator scrutiny prior to publication of
the RFC.

Food for thought.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin () dirtside com  bill () herrin us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004