Hi Bernhard,
Hi Lakshminath,
I read through draft-aboba-sg-experiment-03.txt and have a few comments.
I had a quick reply written and then I deleted everything again because
I mainly struggled with two questions:
* Pros/Cons of the SG
+ Some (or all) existing tools could be reused
(Could also be done without a SG as well.)
+ Formal status within the IETF
(Could be valuable in some interactions with other SDOs)
- Risk of delaying work further and introducing even more formalism to
the IETF.
* What are the problems a SG could solve?
The document is quite short on these aspects; it only says:
"
In some situations, while interest on the part of IETF participants
and end-users may be evident, and the relevance to the Internet
community may be demonstrated, the answer to other questions (such as
an understanding of existing work, clarity or achievability of goals,
or overlap with existing working groups or standards bodies) may not
be as clear.
"
I really wonder whether these are truely the problems for unsuccessful
BOFs.
It would have been good to have meta-discussions after a BOF about why
it wasn't successful and suggestions on how todo it better next time.
The reasons for lack of success in a BOF are manifold. Some of them are
listed in
http://www.ietf.org/internet-drafts/draft-narten-successful-bof-03.txt.
I am not convinced that a SG will help to improve something per-se.
Last Thursday I attended the SAVA meeting in Helsinki (see
http://mail.nrc.tsinghua.edu.cn/pipermail/sava/2007-October/000211.html).
It was organized by Jari Arkko as an effort to help unexperienced guys
with their attempt to bring some work to the IETF. (Note that's my own
interpretation of Jari's intention here. He might have had other ideas
in mind.) Sometimes it just seems to be better for some experienced IETF
persons (e.g., IAB, IESG or other individuals) to help people with a BOF
preparation effort. To me this seems to be far more efficient
particularly since many BOFs fail due to the lack of "street
credibility" by the folks initiating the work. Furthermore, I am not
sure whether to start a SG after a BOF is the right thing todo. I
personally would think that helping people earlier would be useful
(e.g., after one or more Bar-BOFs).
Hence, I wonder whether it would be useful todo the following:
* Give the concept a name. "Study Group" is fine with me.
* Start with with SG as early as possible; no need to wait for a failed BOF
* Reuse the IETF tools (mailing lists, web pages, etc.).
* Find a few knowledgeable IETF persons (who are interested to help --
and not delay or destroy efforts) and assign them as mentors to the
preparation work.
[Note: If you cannot find any experienced person to help then that's
probably already an indication that something is really heading into the
wrong direction.]
Rather than putting this into the constraints of a working group I would
intentionally leave this a bit "unregulated". This gives the
participants more freedom to organize conference calls, f2f meetings,
etc. and to announce them on the list without having long debates about
whether it was sent with enough time in advance. Additionally, it would
leave the group open to come up with other innovative ways to make progress.
For example, at IETF#69 we had an adhoc meeting on SPIT prevention. In
short, it was a disaster.
We have a few solution approaches, we can envision a problem but we
obviously do not have a lot of SPIT to determine whether the proposed
mechanisms would help and which mechanism is more likely to be
successful. The group of people working on the subject would obviously
appreciate input from other IETF members on how we should move forward
with the work since the work stalled a bit. This is a quite practical
example and I would like to better understand how the proposals in
draft-aboba-sg-experiment-03.txt could help me to make progress.
I could also come up with a simpler example, based on the early warning
adhoc meeting from IETF#69. It is a simpler case since we had
constructive discussions and there was a lot of support for the work.
Let me know if I should elaborate a bit more on this case if the
above-mentioned one is too tough.
In any case, if you come up with ways to work more efficiently then
that's certainly great.
Ciao
Hannes
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf