Standards

Harrington, David dbh at enterasys.com
Wed Feb 19 10:34:45 CET 2003


Hi,

I disagree somewhat with both these analyses. My analysis follows

[Robert Elz]

This is truly pathetic.  13 standards in 10 years from an organisation
the size of the IETF 
...
The IETF has become fixated upon publishing PS's and then closing
down working groups as soon as all the required PS's are out the door.
...
In this state, there's nothing left to drive the PS's to DS and
then eventually Standard status.  
[end Elz]

[John C Klensin]

If the IESG (and RFC Editor ?)
insists on perfection at PS, doing so sufficiently exhausts
people and process that there is no energy for doing the work to
advance the document further.  In this model, a lighter-weight
approach to PS might produce somewhat weaker documents, probably
much more rapidly.  Such documents, and the reduced level of
burnout from producing them, might then provide both more
incentive and more energy for going to Draft.
[end Klensin]

[Harrington]
Knowledge work is not defined by its quantity, but by its results. Whether the IETF is being effective must be determined by how well it is meeting the needs of its "customers" - those external entities making use of our "standards".

Advancing from PS to DS to STD is paperwork; it doesn't necessarily reflect the effectiveness of a "standard". Do your companies consider themselves successful when all the project plans have been properly filled out, or when they produce real products that customers are willing to pay money for?

Which is better - a STD that almost nobody is implementing and deploying or a PS that is widely implemented and deployed? 

Rather than spending a great deal of time measuring how many RFCs advance to STD, it might be much more useful to determine which RFCs are being cited in product release notes from the top 90% of market share leaders, and which ones are not. That would help to identify which ones are in demand by vendors' customers, and which ones are not.

As co-chair of the WG that completed the advancement of SNMPv3 to STD, I have a different view of why we have few documents that have made that step - there is little economic motivation to do so. Implementing at PS is justified by vendors because they can sell "standards-based" products to customers. Helping the IETF advance a design from PS to DS is justified by vendors who are economically motivated to report their implementation issues to improve interoperability of their implementation with other implementations (which reduces the costs of support). 

Helping the IETF advance a design from DS to STD, however, yields little benefit to a vendor. If multiple vendors agree on the specifications (PS) and have worked out problems of interoperability (DS), then what is the economic reward to a vendor for having an employee go through extensively detailed documents, and poll their customers, to determine which features are really being deployed and are being found useful?

Given this vendor-centric economic approach to document advancement, I reach the conclusion that an IETF PS document must meet two requirements - 1) it must be completed on a timely basis so the technology it standardizes is still young enough to have de jure standardization matter, i.e. before the market chooses a de facto standard without the help of the IETF and 2) the PS specification must be good enough and yield enough benefits over the existing proprietary implementations to justify moving to the proposed standard.

---
David Harrington            
dbh at enterasys.com           
co-chair, IETF SNMPv3 WG




More information about the Problem-statement mailing list