On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong <o...@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 ................ her...@dirtside.comĀ b...@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004