Simon Josefsson wrote:
Peter Saint-Andre <stpeter@xxxxxxxxxx> writes:
Even 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...
I think that is a good idea. The IETF could provide guidelines for
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).
The danger here is that when people bring work to IETF, they might
refuse to change protocols which are already deployed.
And speaking of cross area review again: last thing I want is to be
forced to go to multiple smaller meetings in various other organizations
instead of attending 3 IETF meetings per-year.
I think we've seen several examples of where the IETF has spent
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.
I 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).
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf