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

Mon Jul 11 22:37:02 UTC 2011

On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>
> On Jul 11, 2011, at 12:18 PM, William Herrin wrote:
>
>> On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>>> On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
>>>>>>>> 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 I think that adding yet another required section to an
>>> internet draft is going to increase it's quality?
>>> No I do not.
>>
>> Joel,
>>
>> You may be right. Calling out IANA considerations doesn't seem to have
>> made the IETF any smarter on the shared ISP IPv4 space. And I have no
>> idea if calling out security implications has helped reduce
>> security-related design flaws.
>>
>> On the other hand, calling out ops issues in RFCs is a modest reform
>> that at worst shouldn't hurt anything.
>
> To my mind, one of the really good criterion for an operational
> considerations document is some actual experience running it.

Hi Joel,

I'm not looking for anything that sophisticated. I just want a list of
"These are the things that can be tuned at an operations level (plus
the defaults) and these are the things that can't be tuned but someone
in the discussion thought a reasonable person might want them to be."
The idea is that an ops guy should be able to read the three-paragraph
intro, jump to the list of tunables and then be able to offer feedback
along the lines of, "Whoa! Of course X should be tunable, are you
kidding? Here's a rough description of where I want to configure it."
and "I'm never going to alter Y. You can make it configurable, but I'd
just as soon deal with everybody having the same value of Y."

Heck, make it multiple choice. 1 is "no chance I'll ever want to
change this value" and 5 is "I'll want to set this value case by
case."

>> That beats my next best idea:
>> asking the ops area to schedule its meetings with the various NOG
>> meetings instead of with the rest of the IETF so that the attendance
>> is ops who dabble in development instead of developers who dabble in
>> ops.
>
> The OPS area works on OPS and Management. Protocol
> development of the sort you're describing generally occurs
> in working-groups chartered in the Internet or Routing areas...

A moment ago you said, the ops area "reviews basically every draft in
front of the IESG."

> Participants, especially those that actually do the work are the
> important part as far as I'm concerned.

I don't disagree. But producing flawed standards does nobody any good,
least of all the folks who poured their hearts and souls into making
them.

> Rough consensus is an ugly an imperfect business, it
> should be recognized that not everyone is going to come
> away from every exchange with what they want.

Which if you were talking about a rough consensus of operations folk
addressing operations issues would be just fine. This is basically
what happens at the address registries like ARIN and it more or less
works. That's broken in the IETF. The ops folks aren't there for the
consensus checks. As a consequence, ops issues are being decided not
with -rough- consensus but with -false- consensus.

False consensus falls apart when you try to bring the excluded folks
back to the party, as you must in the operators' case with any
standard the IETF produces.

>> You disagree? What are your thoughts on fixing the problem?
>
> I'm not sure that we agree on the dimensions of the problem.
>
> on the question of ipv6 is broken:
>
> * You're going to have to cope with what you have and can squeeze out of vendors in the near term. implmentors don't change that fast.
> * People have to show up with the problem statement and stick around to do the work
> * the outcomes are not always pretty.

V6 poses some difficult challenges and you're right that in the short
term we're basically stuck with what is and have to make the best of
it. But V6 isn't my focus in this thread. The ops are sufficiently
irate at this point that they'll keep pounding on the WG's and the
vendors until fixes happen.

My focus in this thread is this: how do we help the next teams avoid
the discourtesy and the smackdown that the v6 teams are getting for
not adequately recognizing the ops' issues. These guys should have
been heroes but instead they screwed the pooch and everybody's paying
for it. How do we fix the systemic problems so that next time they are
heroes?

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