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

Mon Jul 11 23:21:09 UTC 2011

On Jul 11, 2011, at 3:37 PM, William Herrin wrote:

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

I said there is an ops directorate that reviews basically every draft in front of the iesg... much like their are genart reviews, security reviews iana reviews etc. The principle work on a draft by the time that occurs is already done unless the iesg returns the draft to the work group.

<SNIP>

>> Participants, especially those that actually do the work are the
>> important part as far as I'm concerned.
> 
> 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?

IPNG was a long time ago. things have changed and will continue to change because standards are written by humans and cemented with consensus which is imperment and changable. Rational changes, Requirements change and things should evolve, that's not failure it's healthy.

> Regards,
> Bill Herrin