On Jul 11, 2011, at 12:18 PM, William Herrin wrote: > On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli <joe...@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. > 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... At least one of the ops chairs are on this list attends nanog regularly etc. Participants, especially those that actually do the work are the important part as far as I'm concerned. 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. > 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. I hope that my time is productively employed. http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 > Regards, > Bill Herrin > > > -- > William D. Herrin ................ her...@dirtside.com b...@herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 >
