IPv6 Confusion

[drc at virtualized.org (David Conrad)]

Tony,

On Feb 18, 2009, at 11:13 AM, Tony Hain wrote:
> The bottom line is, if you want something to be defined in a way  
> that works for you, you have to participate in the definition.

Well, yes.  But there is an impedance mismatch here.

The IETF still seems to operate under the assumption that the folks  
who run the networks are the same folks who implement the code the  
network runs on top of.  I figure this (mostly) stopped being the case  
(at least for the "production Internet") sometime in the mid-90s.   
Today, network operators and end users are the folks who are  
specifying requirements.  Folks who go to IETFs are the ones who are  
trying to figure out the protocols to meet those requirements, or at  
least what they believe those requirements to be.  Unfortunately,  
that's not what we have.  We have network operators in their own  
little world, trying to keep the network running and protocol  
developers in their own little world, trying to come up with cool  
features that will make their protocols relevant, based on their own  
beliefs as to what is important or not.  These two camps seem to  
intersect rarely.

As such, it isn't particularly surprising when IETF protocol  
developers tell network operators who go to the IETF they aren't  
relevant.  In the specific definition of protocol bits on the wire,  
network operators actually aren't that relevant.  Network operators  
care about the functionality and multi-vendor interoperability,  
whether it is bit 8 in the second octet or bit 4 in the third octet  
that results in that functionality isn't a big concern (as long as  
everyone agrees).  The network operators tell the vendors what sort of  
functionality they need, and the vendors go to the IETF to push their  
particular approach to address those requirements (or block another  
vendor's approach).  This may be where Randy Bush derives his "IVTF"  
label.

The problem is, since around the mid-90s, it seems we've taken it too  
far.  The fact that the IETF has demonstrably ignored network operator  
input in stuff like DHCP or routing scalability means the IETF has  
developed protocols that don't meet network operator requirements.   
And because network operators can't be bothered to learn and argue the  
bit patterns, their ability to provide input into protocol definition  
is reduced to yelling from the sidelines or communicating via proxies  
with their own agendas.

Yes, there have been attempts to bridge the two camps, but I suspect  
the only way to really address this is a fundamental shift in the way  
the IETF does business, taking into account the fact that network  
operators and end users, by and large, are not the implementors of  
protocols and don't actually care how they are implemented, but rather  
the folks who define what the protocols need to do.  I'll admit some  
skepticism that such a change is actually feasible.

Regards,
-drc