Or why not go further and reorganize IETF completely on the same lines
as most other standards bodies.
IETF would be split into intensive one or two day working groups in
which the WG was expected to make significant progress on closing out
its issues list.
Wednesday would be set aside for the tutorial / cross area / cross
IETF sessions with the morning set aside for area meetups and the
afternoon for plenaries led by the IAB and IESG. So instead of the WG
sessions being mostly rather boring status updates we could actually
do some useful work.
A small number of working groups could probably be absorbed into an
area-wide 'maintenance' working group. A lot of security working
groups appear to be impossible to shut down because there is always a
need to maintain lists of algorithms and so on. For several years
running I have put S/MIME on my duty list and then found that the
agenda was completed before I had chance to log into the jabber room.
The current scheme appears to have evolved from the days when the
fore-runners of the ADs were the ARPA program managers and the
fore-runner of IETF meetings were essentially status meetings.
If the IESG insists on making itself the critical path on every loop
it is going to find itself over-worked. And lets not forget that the
IETF is handling a progressively smaller portion of Internet Standards
work. Anyone really think that the IETF could cope with also handling
the work done in W3C and OASIS in addition to its current load?
The current scheme has one meeting format that is attempting to
satisfy two objectives that do not seem to me to be very compatible.
We have three meetings a year, we can experiment with one meeting
every few years or so and see if other arrangements meet those needs
better. We don't even need to experiment with a whole meeting. What I
am proposing might well work better for some areas than others and
some working groups than others.
On Sun, Aug 1, 2010 at 10:48 AM, Dave CROCKER <dhc2(_at_)dcrocker(_dot_)net>
On 7/31/2010 1:00 PM, Peter Saint-Andre wrote:
or perhaps many
drafts are written in such a way that folks can't easily grok the problem
and its proposed solution. Regarding the latter, one of the WGs I advise
held a small "tutorial" session in a side room on Friday morning and that
turned out to be quite useful because it forced some of the key
contributors (in this case the chairs) to clearly explain the core
concepts behind the protocol under development within the WG, and I think
that effort will pay off in the form of a much clearer and more readable
There has long been discomfort about working group meetings that are
primarily tutorial. Given the very short time there is for wg meetings, it
really is essential that they be devoted to resolving specific questions
through face to face debate. That's really all there is time for.
That said, careful summary/tutorial can often be quite helpful. And you
point the perhaps-not-obvious benefit that it solidifies the presentation
abilities of the principles, rather than only providing basic exposure for
So I find myself reacting to your note by thinking that perhaps we should
distinguish these activities and schedule them separately, with clear
labeling. Only some groups will need tutorials. Only some folk will
need/want to attend them. If a group needs /only/ tutorial, we might want
to take a moment and wonder how that can be.
I could, for example, imagine a message of brief tutorials filling some of
Ietf mailing list
Ietf mailing list