More comments on draft-aboba-sg-experiment-03.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]