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

William Herrin bill at herrin.us
Mon Jul 11 15:13:07 UTC 2011


On Mon, Jul 11, 2011 at 3:08 AM, Joel Jaeggli <joelja at bogus.com> wrote:
> On Jul 10, 2011, at 11:57 PM, William Herrin wrote:
>> 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.
> "

Joel,

I am giving you a break. Instead of calling this list of folks to the
carpet over a failure of imagination that by the time we've
ubiquitously deployed IPv6 will have been the root cause of billions
if not tens of billions of dollars in needless industry expense, I'm
trying to move the discussion past the errors and focus on ways to
help the next team of smart, selfless and dedicated individuals avoid
sullying their results with a similar mistake.

Denial keeps the discussion focused on the errors. You don't want that
and neither do I.


>>>> 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.

Do you find this adjustment objectionable? Do you have other fresh
ideas to float? Something better than the tired refrain about
operators not showing up?

'Cause I have to tell you: Several years ago I picked a working group
and I showed up. And I faced and lost the argument against the
persistent certainty on the workability of ridiculous deployment
scenarios by folks who never managed any system larger than a software
development lab. And I stopped participating in the group about a year
ago as the core of participants who hadn't given up wandered off into
la la land.

Regards,
Bill Herrin



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




More information about the NANOG mailing list