ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [council] framing the discussion on SGs and role of the Council



Hi,

(I changed the topic yet again)

I do not believe I have the ability to educate you on this, nor would I presume to do so. What I can do is present arguments in support of my position.

I think the problem is in the framing of the discussion. We are not oversight of the whole GNSO. I did not know you were suggesting oversight for the GNSO. I tend to think of each of the SGs self-organizing in terms of their internal issues, with the Board's by-your-leave - of course. I do not believe further oversight of SGs is needed beyond what the SIC already does.

What is sometimes needed is coordination, an aggregation point where the various SGs can come together and work on common goals - if and when they wish. The council can be useful in such facilitation. SGs can also put together other constructions, such as the current 'for counting purposes only' Houses*. They are useful to the degree that the components, the SGs, decide to use them. Not in an authoritative manner, but as a organizational focusing point. Perhaps there are things that the Houses wish to make common cause on and they are free to self-organize any sort of coordination function they wish to organize. Likewise other cooperative projects between Houses or between constituencies can form and reform based on the patterns of cooperation and be issue based.

So I see the council as oversight of the policy process, not the SGs. I also see as the place where the SG can naturally come together enabling us as council members to also be useful in encouraging our separate SGs to work together as a way of achieving various goals. I also see the council as a service organization that can be used by the SGs when they have a common cause, aka GNSO consensus, to effect changes beyond GNSO policy.

avri

* (Have we actually managed to make Houses useful for anything other than counting votes yet?)

On 04-Feb-14 15:26, Mike O'Connor wrote:

hi Avri.

i love it when i blunder into something like this.  interesting!  so i hijacked the thread 
over to it’s own new one so we don’t unduly tangle up the MSI discussion.

i don’t hold this as an absolute do or die issue — but if the Council has authority and 
responsibility for the *whole* GNSO, i think we’ve got some figuring-things-out to do.  i’ve 
been laboring under the notion that the heads of the SGs and constituencies had responsibility and 
authority over their respective organizations and that the Council truly is a policy council.

can you point me at the right places to go learn more about this topic?  i’m in that “oops, 
i’d better go educate myself” mode at the moment.

thanks for the heads up,

mikey


On Feb 4, 2014, at 9:46 AM, Avri Doria <avri@xxxxxxx> wrote:


Hi

On 04-Feb-14 10:02, Mike O'Connor wrote:
which brings me to the last idea for this post.  i wonder whether we
need *two* GNSO Councils — a Policy Council (us) and a Leadership
Council comprised of the heads of the SGs and constituencies who elect
their own leader to coordinate and drive the work of those functional
bodies.


While this is the sort of thing that the review of the GNSO can come up with, I 
personally think it is a really bad idea that will confuse things even further.

I think that the GNSO has one leadership council, the GNSO Council, not a GNSO 
Policy Council but a GNSO Council.  And while there are those who have had a 
long standing campaign to denature the GNSO Council to make it less then it is 
supposed to be, the only real effect of splitting the leadership into two 
councils would be to weaken the GNSO and promote inter-council conflict on 
whose responsibility something was.  Finger pointing would be the order of the 
day.

Definitely something I will argue against on every opportunity.

avri



PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP 
(ID for Twitter, Facebook, LinkedIn, etc.)







<<< Chronological Index >>>    <<< Thread Index >>>