ietf
[Top] [All Lists]

RE: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)

2006-06-23 13:17:23
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(_at_)cs(_dot_)utk(_dot_)edu] 
Sent: Friday, March 24, 2006 2:50 PM
To: Dave Cridland
Cc: dcrocker(_at_)bbiw(_dot_)net; ietf(_at_)ietf(_dot_)org
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf