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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf