On 10 Jul 2011, at 21:22, Owen DeLong 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. > > There is another RFC and there are APIs and most operating systems > have configuration mechanisms where an operator CAN set that to > something other than the 3484 defaults.
There is a DHCPv6 option to configure host policy described in http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-01, which is hopefully approaching a WGLC at IETF81. RFC3484 was originally published in 2003, which is a long time ago. And of course it turned out that, with wider operational experience and feedback from the operator community, there were some issues uncovered and some omissions. Perhaps some of those might have been foreseen, but I highly doubt all of them would have. Many of the issues were captured in RFC5220, which led to the work on RFC3484-bis, which is also close to publication. Now, perhaps the DHCPv6 option and the 3484-bis drafts could be posted to the NANOG list at an appropriate time, for example when the docs hit WGLC. But there are a lot of WGLCs out there and the question is then whether the NANOG list, or some special NANOG list for IETF WGLCs, would want all those notifications. As a co-author of the DHCPv6 and 3484-bis drafts, I am quite happy to post about these to NANOG as they approach last call. There are three open issues on 3484-bis that some feedback would be welcomed on. >> 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. Whether it's a separate section in the draft, or a recommendation to post to operators communities (which is more than just NANOG of course), the question as mentioned above is how that's done in a way to get the attention of appropriate operators without drowning them in notifications. Tim
