[142655] in North American Network Operators' Group
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
daemon@ATHENA.MIT.EDU (Joel Jaeggli)
Mon Jul 11 19:22:17 2011
From: Joel Jaeggli <joelja@bogus.com>
In-Reply-To: <CAP-guGXT=6OduATD9=CN11uiZQr1siJLmkZJnFddaeAGMPFgsg@mail.gmail.com>
Date: Mon, 11 Jul 2011 16:21:09 -0700
To: William Herrin <bill@herrin.us>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 11, 2011, at 3:37 PM, William Herrin wrote:
> On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli <joelja@bogus.com> =
wrote:
>>=20
>> On Jul 11, 2011, at 12:18 PM, William Herrin wrote:
>>=20
>>> On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli <joelja@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.
>>>>>>>>>=20
>>>>>>>>> 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.
>>>>>=20
>>>>> Do you find this adjustment objectionable?
>>>>=20
>>>> Do I think that adding yet another required section to an
>>>> internet draft is going to increase it's quality?
>>>> No I do not.
>>>=20
>>> Joel,
>>>=20
>>> 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.
>>>=20
>>> On the other hand, calling out ops issues in RFCs is a modest reform
>>> that at worst shouldn't hurt anything.
>>=20
>> To my mind, one of the really good criterion for an operational
>> considerations document is some actual experience running it.
>=20
> Hi Joel,
>=20
> 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."
>=20
> 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."
>=20
>=20
>>> 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.
>>=20
>> 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...
>=20
> 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.
>=20
> 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
