+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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to