[142619] in North American Network Operators' Group
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
daemon@ATHENA.MIT.EDU (Joel Jaeggli)
Mon Jul 11 03:08:53 2011
From: Joel Jaeggli <joelja@bogus.com>
In-Reply-To: <CAP-guGVTSYV1O9APc=BU3P8uXJ-h99gXbGFrZk1wRf275VpKOA@mail.gmail.com>
Date: Mon, 11 Jul 2011 00:08:00 -0700
To: William Herrin <bill@herrin.us>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 10, 2011, at 11:57 PM, William Herrin wrote:
> 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.
>>>=20
>> 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.
>=20
> Hi Owen,
>=20
> 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.
Give me a break... multiple implementations have chosen to tweak the =
algorithm independently and at various times.
It's just an rfc, not the gospel according to richard draves.
"
Acknowledgments
The author would like to acknowledge the contributions of the IPng
Working Group, particularly Marc Blanchet, Brian Carpenter, Matt
Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun
Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik
Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman,
Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas. In
addition, the anonymous IESG reviewers had many great comments and
suggestions for clarification.
"=20
>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> I think this would be a good idea, actually. It would probably be =
more
>> effective to propose it to IETF than to NANOG, however.
>=20
> 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.
>=20
> Regards,
> Bill Herrin
>=20
>=20
> --=20
> William D. Herrin ................ herrin@dirtside.com bill@herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>=20
>=20
