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

[William Herrin <bill () herrin us>]

On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong <owen () delong com> wrote:
> On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
> > 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.
> 3484 specifies a static default. By definition, defaults in absence of
> operator configuration kind of have to be static. Having a reasonable
> and expected set of defaults documented in an RFC provides a known
> quantity for what operators can/should expect from hosts they have
> not configured. I see nothing wrong with RFC 3484 other than I would
> agree that the choices made were suboptimal. Mostly that was based
> on optimism and a lack of experience available at the time of writing.

Hi Owen,

A more optimal answer would have been to make AAAA records more like
MX or SRV records -- with explicit priorities the clients are
encouraged to follow. I wasn't there but I'd be willing to bet there
was a lonely voice in the room saying, hey, this should be controlled
by the sysadmin. A lonely voice that got shouted down.


> > 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.
>
> I think this would be a good idea, actually. It would probably be more
> effective to propose it to IETF than to NANOG, however.

If the complaint is that the IETF doesn't adequately listen to the
operations folk, then I think it makes sense to consult the operations
folks early and often on potential fixes. If folks here think it would
help, -that- is when I'll it to the IETF.

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