ICANN/DNSO
DNSO Mailling lists archives

[ga]


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

Re: [ga] Pulling the plug on the Council



Hello Thomas!

At 11.04.2002 23:42, Thomas Roessler wrote:
>If the council actually delivers on its promise and produces an intelligent, useful, and practicable alternative to the Lynn plan, then it would have proven that it can work kind of "effectively," and may deserve another chance.
>
>If, however, the council does not deliver (for whatever reason), the current DNSO concept has proven beyond all doubt that it is not useful, and not usable.  In this case, the council's plug should indeed be pulled, and it should be replaced by something _radically_ different.
>
>
>I would guess that any work product which does not identify and address the problems with the DNSO's current process would be considered a failure.  Any work product which just says "everything's almost fine" would most likely be a failure.

Although I agree, I concede that the DNSO has had the most
difficult job of all the SOs.

The ASO only oversees and coordinates the bottom-up
policy development process -- which is done by the
regional IP registries. So the ASO has not done much
except for electing representatives to the Board and
organizing meetings. (This is not meant as criticism:
If the bottom-up IP address policy development works,
that's fine! Have a look at the ASO web site and
mailing list and judge for yourself if you see any
activity -- the last posting to aso-policy seems to
have been in September 2001.)

The PSO seems to have even less work. It again elects
representatives to the Board and organizes meetings.
There are two statements from the Protocol Council,
both of which are unrelated to protocol and parameter
assignments (Alternative Roots and At Large Study).
The mailing list archive seems to end in September, too.

The DNSO has a hell of a lot of work. 
I believe that part of the problem lies in the constituency
structure. It's not only about including all relevant 
groups (Philip mentioned individual name holders), it's 
about the constituency representatives not being able to work 
together. Stuart Lynn calls it "the DNSO's complex and 
noisy crowd of working groups, constituencies, and the 
Names Council." 

Not all concerned parties in the Task Forces are 
represented, but even worse -- not all represented
parties seem to be interested in the work. In addition,
some Names Council members see themselves mainly as
constituency representatives and seem unwilling to
work on anything which they don't have a constituency
members' meeting vote on ("imperative mandate")
or which their constituency does not perceive as
important issue. Combine this with the lack of
professional staff support and you end up here.

Stuart Lynn's proposal changes this subtly by adding
not only staff support, but also NomCom-chosen members 
to the Names Policy Council: This makes the gTLD-NPC 
members /individual/ members instead of representatives 
waiting for orders. Don't get me wrong: I don't prefer 
NomComs. I don't mind members getting feedback from 
their constituency, as long as it is done simultaneously 
with the policy development instead of the current 
stop-and-go approach. But the NC members should feel
primarily responsible for gTLD policy development, not
for representing constituency interests. (Additionally,
the DNSO must get rid of incentives to block work
getting done.)


>Anyway, I'm speculating.  It may also be the case that this is all just the fight for having the best deck chairs on the Titanic, as Milton has been suggesting on the NCDNHC's list.

Absolutely no need to do that when you get the plans for your own 
Titanic deck chair for only $9.95 from Popular Woodworking magazine.
http://www.popularwoodworking.com/store/displayplan.asp?id=1139
http://titanic.gov.ns.ca/chair.html

Best regards,
/// Alexander

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



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