On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli <joelja@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@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@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004