I think the questions of precedence, scope, etc. are interesting but not
particularly on point. In may view there are two types of work the IETF
performs: Infrastructure and Functional.
Most IETF protocols fall into the functional category. They may be building
blocks for other protocols to build on or they may be application protocols in
their own right but they are designed to support a clearly defined function
that is either currently unmet or there are difficulties with the manner in
which it is being met (cost, patent encumberance, lack of extensibility,
ambiguity, proprietary control, etc.)
Functional protocols typically have a very clear deployment case: there is some
form of functionality that users require which the protocol delivers. In many
cases the choice is between no functionality and use of the protocol.
Alternatively there is a situation where multiple protocols have developed as
de-facto standards and a quorum of proprietary stakeholders have come to a
mutual agreement that there is a need for an open standard.
The only cases in which a deployment case would usually be useful for a
functional protocol is if either 1) the success of the protocol is dependent on
establishing a network effect or 2) there is an established proprietary
standard that the open standard is intended to displace. Let me be clear here:
I do not assert that development deployment cases should be mandatory in such
cases but I do think that they might be of use in working out how to develop a
protocol that has a chance of success in a difficult situation of this type.
The deployment problem is much greater for infrastructure protocols such as IP,
DNS and PKI. By infrastructure I mean a protocol whose sole purpose is to
provide value as a platform on which to build other systems. IP and DNS are
unique in the sense that they are the only IETF protocols that the IETF can and
must claim sole control of. Development of protocols that compete with or
functionally replace SMTP, PKIX or TLS could take place in W3C or OASIS. If
effective change control of IP or DNS ever left IETF control it is the end of
the IETF.
Another difference with IP is that the IETF is competing with its past success.
What made IPv4 successful is also the reason that end users are reluctant to
change. There is a major difference between reseach and development. IPv4 was
the result of pure research. To succeed IPv6 must be a development, an
incremental enhancement on the legacy base. The deployment case for IPv4 was
clear: there was no effective, non-proprietary alternative established so the
choice was between the Internet and no Internet.
The range of considerations that it is necessary to take account of in
proposing to change a rapidly growing infrastructure with a billion users is
much wider than the range of considerations that were relevant in developing
IPv4. To answer Brian's point directly: Where the future of IP is concerned the
IETF is and must be as narrowly focused as the technology specific standards
organizations he refers to.
We have a mismatch here in objectives:
1) IETF Objective: Deploy IPv6.
2) Stakeholder Objective: Avoid the consequences of IPv4 address space
exhaustion.
If we continue to simply assert that #1 satisfies #2 and thus the choice is
inevitable we miss the fact that the stakeholders have many other choices. We
fall victim to the fallacy of the excluded middle.
The reason I am proposing deployment cases is that while I beleive that #1 is
the ultimate end state I also believe the same of PKI and cryptographic
security systems. There is no technology developed in computer science that
provides a more compelling intellectual case than Public Key Cryptography. Yet
after three decades our use of PKI barely scratches the surface of what is
possible. We need to ask why.
The idea of deployment cases is not to turn engineers into marketers but to
facilitate a conversation between the engineers designing the product and the
stakeholders whose support is required to deploy it. The number of people who
have ever attended an IETF is approximately on thousandth of one percent of the
Internet user population. If we want to influence we have to communicate in a
language they accept.
The stakeholder leadership may to first order be modeled by a warren of
rabbits: myopic. The more enlightend of them are driven by the needs of the
next two quarters, for most it is only one. When faced with a threat their
instinct is to run away and hide. The odd Caerbannog attending the IETF is just
as frustrated as the rest of us. Recently I spoke to a senior executve at a
very large manufacturing company that is 100% certain that their principal
product line will be completely obsolete within five years, most of you would
say it is obsolete today. Their idea of forward planning for the change is not
investing in any new equipment that is unlikely to see a return before that
time.
Mere exhaustion of the IPv4 address space is not going to be a sufficient
incentive unless (1) it is certain to happen in the next two quarters and (2)
the impact is certain to be negative on the specific stakeholder in question.
If we are to turn the stakeholders around we have to offer them a compelling
proposition. Merely preventing the exhaustion of the unallocated IPv4 pool is
not a sufficient incentive for a stakeholder executive sitting on a large pool
of unused addresses.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf