On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
On Sun, Jul 10, 2011 at 1:41 PM, David Miller <dmiller@tiggee.com> wrote:
On 7/10/2011 12:16 PM, Jeroen Massar wrote:
You are on NANOG out of your own free will, the same applies to the IETF. If you don't participate here your voice is not heard either, just like at the IETF.
True, anyone can participate in the IETF processes. However, if key players do not participate, then something is broken. I will take my lumps for not participating.
My point was - "If fingers can be pointed at both sides, i.e. operators and IETF, then both sides are to blame."
Hi David,
This is a process problem, not an individual problem.
The IETF is run by volunteers. They volunteer because they find designing protocols to be fun. For the most part, operators are not entertained by designing network protocols. So, for the most part they don't partiticpate.
This is not going to change. And it also isn't the problem -- people who enjoy the work tend to do better work.
The problem is that the IETF routinely exceeds the scope of designing network protocols. Participants in the working groups take what are fundamentally operations issues unto themselves. They do so knowing they lack adequate participation by network operators. And the process that leads to RFCs offers inadequate checks and balances to mitigate that behavior.
Consider, for example, RFC 3484. That's the one that determines how an IPv6 capable host selects which of a group of candidate IPv4 and IPv6 addresses for a particular host name gets priority. How is a server's address priority NOT an issue that should be managed at an operations level by individual server administrators? Yet the working group which produced it came up with a static prioritization that is the root cause of a significant portion of the IPv6 deployment headaches we face.
3484 specifies a static default. By definition, defaults in absence of operator configuration kind of have to be static. Having a reasonable and expected set of defaults documented in an RFC provides a known quantity for what operators can/should expect from hosts they have not configured. I see nothing wrong with RFC 3484 other than I would agree that the choices made were suboptimal. Mostly that was based on optimism and a lack of experience available at the time of writing. There is another RFC and there are APIs and most operating systems have configuration mechanisms where an operator CAN set that to something other than the 3484 defaults.
I don't know the whole solution to this problem, but I'm pretty sure I know the first step.
I don't know what you had in mind, but, reading RFC 5014 would be my suggestion as a good starting point.
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.
I think this would be a good idea, actually. It would probably be more effective to propose it to IETF than to NANOG, however. Owen