![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Simon Josefsson wrote:
Peter Saint-Andre <stpeter at jabber.org> writes:The danger here is that when people bring work to IETF, they might refuse to change protocols which are already deployed.
I think that is a good idea. The IETF could provide guidelines forEven further, how about breaking up the IETF into smaller, more agile standards development organizations? We essentially did that with XMPP by using the XMPP Standards Foundation for extensions to XMPP rather than doing all our work at the IETF (given the large number of XMPP extensions, doing all that work at the IETF would have represented a denial of service attack on the Internet Standards Process). I see a few potential benefits here:
1. Greater focus on rough consensus and running code.
2. Fewer bureaucracy headaches.
3. Reduced workload for our stressed-out IESG members. :)
Just a thought...
self-organizing group efforts, such as mailing list policy, IPR
templates, bug tracker, conflict resolution systems, etc, and let people
standardize ideas and even experiment with implementations. When such
efforts are successful, the technical work can be guided through the
IETF process (potentially changing the design to fix problems).
I think we've seen several examples of where the IETF has spentI agree that running code should be given extra weight, but I am not sure that running code should be a requirement for something which is not well understood yet (some Lemonade WG documents come to mind).
significant amount of energy, ranging from heated discussions to
specification work, on solutions that simply won't fly. It would be
useful if that energy waste could be reduced. Having 'running code' as
a barrier for serious consideration within the IETF may be one approach.
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.