I would offer that in *some* groups the running code bar is reasonable. For example, in SIPPING, the problem space is pretty well-defined, and there are third-party specifications and requirements out there. There have been way too many half-baked ideas floated for consideration, and that has sucked the life blood out of the work group. As I have mentioned on the SIPPING list, this is NOT a prescription for all proposals or work groups in the IETF. However, the idea is reasonable for *some* work groups in the IETF. I think raising the bar isn't going to hurt. The "they'll take the idea to another standards body" doesn't hold water if there is no code / prototype / product to promote. -----Original Message----- From: Keith Moore [mailto:moore@xxxxxxxxxx] Sent: Friday, March 24, 2006 2:50 PM To: Dave Cridland Cc: dcrocker@xxxxxxxx; ietf@xxxxxxxx Subject: Re: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors) [snip] It may be that we place too much emphasis on running code in IETF today. In ARPAnet days, when the user community was small and homogeneous but platforms were diverse (different word/character sizes, different character sets, different limitations of operating systems and networking hardware), and goals for protocols were modest, merely being able to implement a protocol across different platforms was one of the biggest barriers to adoption. In that environment, being able to demonstrate running code on multiple platforms was nearly sufficient to demonstrate the viability of a protocol. Besides, since the net was small, it wasn't terribly hard to make changes should they be found to be necessary. These days running code serves as proof-of-concept and also as a way to validate the specification. It doesn't say anything about the quality of the design - not efficiency, nor usability, nor scalability, nor security. etc. [snip] _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf