RE: IPv6 Confusion

["Tony Hain" <alh-ietf () tndh net>]

David Conrad wrote:
> 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.

No argument.

> 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.

Outside of a handful of people that make a point of it, there is almost no
interaction.

> 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.

Well, for awhile there was a push to develop 'requirements' RFCs, but
without participation from the ops community, these did little and were
widely chastised as a waste of time. I personally disagree with that, as
anytime you get more than a couple of people working on a problem you need
to write down the expected outcome to keep everyone on track. In any case,
there is a place to put high-level requirements into the system, it just
needs to be exercised.

> 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.

It is easy to throw rocks and say that the other guy needs to change.
Reality is that both sides need to move toward each other. There is nothing
that says the ops community has to stay involved throughout the entire
bit-positioning set of arguments, but if they don't engage at requirements
definition time there is no hope that the outcome will be close to what they
want.

Tony