Hi Ben,
On Oct 10, 2019, at 12:21 AM, John C Klensin <john-ietf@xxxxxxx> wrote:
--On Tuesday, October 8, 2019 21:18 +0200 Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote:
...
Another difference is that while DISPATCH is mainly interesting to people in the ART Area, we can expect GENDISPATCH to draw from all areas. We try not to let DISPATCH conflict with other ART meetings. How do you deconflict GENDISPATCH without it turning into another plenary or a standing BoF?
This is always an issue with Gen Area BoFs and WGs, and this will be no different. I think the bottom line is that there'll be a set of people who will want to participate regularly, and we'll try to accommodate that... there'll be people who want to parachute in for certain topics, and we'll do what we can to accommodate that, realizing that it's harder... and there'll be a lot of people who won't want to have anything to do with it until a proposal is at a stage where they strongly support it or object to it, and there's little we can do to accommodate that. It is what it is, but it's no different than if we just charter Gen Area WGs without a DISPATCH-like start. No?
Barry,
I see one risk with this that I think should be considered and watched for even if the IESG decides to move forward.
The IETF has a rather long and difficult history, with only a few exceptions since the POISED and POISSON WGs, of there being two types of process change proposals. One type is enthusiastically welcomed by the IESG. A large fraction of proposals of that type originated within the IESG (or occasionally the IAB) and were pushed at the community rather than being in any sense bottom-up. That is not necessarily bad -- your work (and Thomas's and Harald's) on IANA Considerations is, IMO, one of the more positive examples. Others are not. They, and especially ones that members of the IESG see as a threat to their authority or the way they do things and sometimes as adding work, have tended to vanish. Often they vanish without a trace, with no opportunity for the community to take positions on Last Call, sometimes inconsistent with WG consensus, and usually with very little accountability for individual ADs or the IESG in general. I (and some others) routinely cite NEWTRK as an example but there are others. In many of them, the IESG has insisted that a working group is needed and then refused to create such a working group (or has created one with a charter so narrow or broad as to make progress impossible) as a means of killing the effort. In others, ADs have managed to erect sufficient obstacles and induce enough delays that people simply lose interest. Sometimes that is A Good Thing; often it is a control mechanism that keep particular people or points of view in power and prevent the IETF from evolving and making progress.
So, the question about this proposed WG for me is whether it will make those tendencies better and thereby prevent good ideas from getting lost or suppressed. If so, I think it is a great idea. But I also see the risk of its being used to bury work that it out of favor with "the leadership" and doing so in a way that preserves the status quo except when the IESG wishes things to be different) and enables even less transparency and accountability than we have seen in the past. I'd like to see ideas and controls about how to prevent the latter or how to detect it and push back if it starts to occur, and I don't see those in the current draft specification.
Hi John,This brings up another question in my mind. The ART ADs typically treat DISPATCH decisions as non-binding recommendations. Likewise, the ADs may skip DISPATCH and take proposals straight to BoF or even WG formation if they think it appropriate.Would GENDISPATCH decisions be treated the same, or would they be binding on the IESG? I had assumed the former, in the sense that AD discretion applies to pretty much any working group. Whichever case is the answer, I think the charter needs to be explicit about it.
Hi Alissa,
That helps. Also, the text about Gen AD discretion that was already there that I somehow completely failed to read also helps :-)
Ben.
|