ietf
[Top] [All Lists]

Re: what is the problem? (was Re: draft-housley-two-maturity-levels)

2010-10-27 20:15:53
+1 

On Oct 26, 2010, at 3:04 PM, Fred Baker wrote:


On Oct 26, 2010, at 10:19 AM, Phillip Hallam-Baker wrote:

Action

We should adopt Russ's proposal: Axe the DRAFT status and automatically 
promote all DRAFT status documents to STANDARD status. This can be done 
formally by changing the process or the IESG can just agree to a convention 
where every DRAFT standard is automatically promoted.
    [snip]
The Internet is now a large place with two billion users. Any institution 
that wants to be influential in shaping the future of the Internet has to be 
willing to commit to the proposals it is making. The current process 
represents an abdication of will and a failure of commitment. It should be 
corrected as a matter of urgency.

I agree with much of that, but suspect I might have worded it differently. 
Bottom line, we put a lot of effort into making documents at the "Proposed" 
level "right", and at that point the people working on it have neither 
incentive nor energy left to do anything more with it unless it is shown to 
have a bug. There are people that will only buy a product if it has been 
interoperability-tested with another vendor's product; they generally do 
interoperability testing themselves.

So yes, move Draft Standards to Standard, and eliminate Draft Standard as a 
status.

I might also make two other changes.

There is a rule in 2026 that says that every feature of the protocol has to 
be shown interoperable, and it strongly prefers complete implementations - 
and wants an updated version with the unused bits removed. It turns out that 
this becomes hard to accomplish for various reasons, and is one of the issues 
with taking protocols to Draft (er) Standard. It could also be described as 
the purpose of a PICS Pro Forma; other standards bodies write documents that 
say "when you are using protocol X for purpose Y, you need to implement 
features Z1, Z2, and Z3". PICS make me crazy, but they may be an acceptable 
alternative to the current rule.

And how do you do interoperability testing? I suspect that if N vendors care 
and are in a position to say that they have several common customers that are 
using both of their equipment interchangeably in the same network, that 
constitutes prima facie evidence of interoperability. We would need to 
clearly specify what an acceptable statement of interoperability is, but we 
might consider that approach.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>