ICANN/DNSO
DNSO Mailling lists archives

[ga]


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

Re: [ga] Questions about the ccSO Proposal


I sure like this concept.

I would like to see some degree of seperation and or balancing device between
(business&Trademark&IP) and (individuals&end consumers&non-coms&dnhs) but I
think that could be fleshed out after the formation, and would not want it to
hold up this proposal.
The ability to remain fluid and dynamic and quickly responsive is key.  This
gives more weight to this proposal.

Eric

Roberto Gaetano wrote:

> Good evening.
>
> I am adding my comments to this interesting message by Bret Fausett, that I
> was unable to follow up when it first appeared a week ago.
> I wonder whether, if a new SO has to be created, it would not make sense to
> really separate "suppliers" and "consumers" (as defined by Bret below).
>
> In other words, the interests of the "consumers" are relevant in the DNSO,
> but are nowhere present in the ASO and PSO, and it is this conflict between
> "suppliers" and "consumers" in the DNSO that creates the major problems,
> that managed to almost paralize the DNSO on issues like introduction of new
> TLDs (failure to even recognize the consensus points of WG-C by the NC, for
> instance).
> I wonder whether the key is to separate the technical part (almost identical
> to the "supplier") from the "general purpose" (almost identical to the
> "consumer"). What I would consider worth exploring is a "technical" DNSO
> (Registrars, Registries [gTLDs+ccTLDs], ISPs) and a new "consumer" CSO
> (Business, TradeMark, Non-Com, Individuals, ...).
> The rationale is that the participants to the former are to some extent
> forced, sooner or later, to come to a situation in which they have to have a
> contract of some sort with ICANN. Already Registrars and Registries are
> accredited, for instance. Of course for ISPs and connectivity providers the
> situation is different, but still more similar to Registrars and Registries
> than to the "consumers" of Internet services.
>
> Of course at this point the latter SO will oversee all the problems from the
> "users" POV, including aspects related to addressing and protocols, and be
> treated as advisory body on consumer issues by ICANN.
> This will re-focus the DNSO on technical issues (and issues related to
> contractual and service agreements with ICANN) that is the real source of
> the problem with the ccTLDs.
>
> Regards
> Roberto
>
> >------------ Original post by Bret
> >
> >After reading the ccTLD communique and hearing more about the proposal over
> >the remote participation feed, I have a few thoughts and questions.
> >
> >* The current DNSO is reasonably balanced between "suppliers" of DNS
> >services (gTLD registries, ccTLD registries, Registrars, and ISPs) and
> >"consumers" of DNS services (B&C, NCDNHC, IPC, and perhaps one day,
> >Individuals). It's not clear from the ccTLD proposal whether a proposed
> >ccSO
> >would have any representation for the "consumer" side interests now
> >represented within the DNSO.
> >
> >Registrants, of course, have the same interests in the policies of the
> >ccTLDs as they do with gTLDs. These interests include domain name rights,
> >intellectual property rights, access to market issues, and whois access and
> >data privacy concerns. A reasonable ccSO structure would ensure that ccSO
> >consensus policies were not simply the consensus of the TLD managers, but a
> >consensus of the larger community having reasonable interests in the
> >ccTLDs,
> >including the "consumer" interests now present in the DNSO.
> >
> >Depending on the issue, a "consensus policy" coming from a group of
> >like-minded ccTLD managers would not really be a consensus of the impacted
> >community, as ccTLD policies affect a wider group than the companies who
> >manage the ccTLD registries. Building a new structure for representation of
> >other stakeholders within the ccSO, however, might well prove redundant to
> >the existing facilities within the DNSO.
> >
> >The ccTLD communique indicates that it has begun an outreach effort to some
> >of the existing DNSO constituencies, for which the ccTLDs should be
> >commended. Those discussions need to continue, and I'll be interested to
> >hear how the ccTLDs propose to address this representation/consensus issue.
> >
> >* Under the current ICANN bylaws, each Supporting Organization effectively
> >has "veto power" over policy initiatives originating within other
> >Supporting
> >Organizations. ("...the Board shall accept the recommendations of a
> >Supporting Organization if the Board finds that the recommended policy
> >...(4) is not reasonably opposed by any other Supporting Organization."
> >Article III, Section 2(e)).
> >
> >So to create a ccSO would be to give the ccTLD registries veto power over
> >DNSO proposals that they "reasonably opposed."
> >
> >A growing number of ccTLDs count themselves as competitors to gTLDs, and
> >this veto power potentially could be used for anti-competitive purposes.
> >
> >* Another obvious question about any new SO is where do the new Board seats
> >come from?
> >
> >At present, there's a balance between the At Large representatives (even
> >though four remain non-elected), and the SO representatives. This is a
> >balance that's important to retain, at least through the end of the ALSC
> >process.
> >
> >If a ccSO proposal is accepted, one reasonable proposal might be to give
> >each of the four SOs *two* Boards seats, with one Board seat elected by the
> >councils of *all four* SOs.
> >
> >* Finally, it's not clear what issues the ccTLDs have with their current
> >relationship with ICANN and the DNSO that are made better by the creation
> >of
> >a separate constituency and guaranteed seats on the Board. The current
> >contract negotiations with ccTLDs, for example, will be handled by Staff as
> >"implementation issues" under existing policy. So guaranteed *Board seats*
> >don't solve any immediate ccTLD issues. While the budget has an obvious
> >impact on the ccTLDs, they appear to be adequately represented on ICANN's
> >budget committee.
> >
> >If the proposed move is primarily due to the concern of "taxation without
> >representation," then the same case could be made for the gTLDs and the
> >Registrars, depending on future DNSO election outcomes. In fact, the
> >registrant community itself, which pays service fees to the registries and
> >registrars also could reasonably claim that it supports ICANN financially
> >too, albeit indirectly. How far will ICANN allow the creation of new SOs
> >out
> >of existing SOs go?
> >
> >Speaking as someone who participated in the DNSO's creation and who has
> >followed it closely since that time, I'm also not aware of any significant
> >ccTLD initiatives that were presented to the Names Council and the larger
> >DNSO community and which were voted down or otherwise rebuffed. While many
> >issues occupying the DNSO's agenda are focused on non-ccTLD issues, this
> >doesn't mean that ccTLD issues are or will be ignored.
> >
> >If there have been problems having ccTLD issues addressed within the
> >current
> >structure, I'd be interesting in hearing more details.
> >
> >This is obviously an issue that warrants significant discussion, and I look
> >forward to seeing some of these questions addressed.
> >
> >     -- Bret
> >
> >--
> >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
> >
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
> --
> This message was passed to you via the ga-full@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga-full" in the body of the message).
> Archives at http://www.dnso.org/archives.html

--
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 >>>