DNSO Archives: [council]

This is a perfectly rational position, but it involves tradeoffs, as I noted earlier. I doubt that any would argue that the larger a body gets, the less efficient it gets. So there is a cost to increased size, which is why I would not favor the alternate idea either. If there is a need for a whip system (which is what I take it you are saying -- meaning a system to take the pulse of members and count noses on issues), why could not that be implemented within the constituency itself, and not require multiple members on the NC? There could be a series of regional constituency focal points, who would serve as both the distributors of info from the NC members and the recipient and aggregators of feedback from the constituency. It may be that mailing lists could serve all or some of this function. Perhaps because I have not been there/done that, I just don't see why the number of NC members is that critical from this perspective.

As I said before, this must be a point on which reasonable people can differ, since we are demonstrating that (of course, I make the assumption that we all are reasonable), but I do think there is an obligation on those who would want to revisit the structure adopted in the Blueprint to provide a compelling argument for change. Any other standard would threaten to reopen many issues, and make it very difficult if not impossible to get to finality in the time frame available.

One other option (which I recognize may not look that attractive to those on the other side of this issue): let's get through the restructuring, even if it includes what some might think are imperfect features, because it is critical that ICANN get to a position of relative stability quickly. Once that happens, issues like this could be taken up and debated without having the outcome unduly affected by the need for finality that is today driven by the confluence of outside and inside issues facing ICANN. My personal view is that arguments like this would have a better chance if not being decided in the context of the extreme time pressure we have now. In other words, while we certainly do not want to make any critical errors in our restructuring effort, what is critically important now is actually getting it done in the timeframe available. The practical fact is that all time spent by anyone on rearguing Blueprint issues, even if there is a rational basis for doing so, is not being spent on implementing. Unless your view is that this is a crippling deficiency in the Blueprint, I would argue that the better use of very finite resources (we all have day jobs) is to focus on implementation.

[council]

RE: [council] Status report on implementation of evolution and reform