ICANN/DNSO
DNSO Mailling lists archives

[ga-full]


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

[ga] GA summary #14: April 10 - April 15, 2002.


This summary covers the DNSO GA mailing list's (and related) 
discussions and news between April 10, 2002, and April 15, 2002.

GA list archives are available online at 
<http://www.dnso.org/clubpublic/ga/Arc10/maillist.html>.

Please feel free to forward this summary as you believe to be 
appropriate.

		   Deadline: 14 days until E&R-day

The deadline for useful input to the Evolution and Reform Committee  
expires on April 29, i.e., in 14 days.   
<http://www.dnso.org/clubpublic/council/Arc10/msg00004.html>


				Topics

(i) OECD report on whois issues.  Danny Younger forwarded an excerpt 
 from an OECD report  
<http://www.oecd.org/pdf/M00027000/M00027316.pdf> on WHOIS and 
cybersquatting experience.  The report claims, based on OECD's own 
experience with ocde.org [the French abbreviation of the 
organization's name], that "the registrars' interest is to keep the 
cybersquatters as client for the volume of registration fees they 
generate and to avoid helping the victim." In a follow-up message, 
Dan Steinberg notes that "a determination of 'cybersquatting' is 
really something no one can make in advance." "Only the courts have 
the right to act as courts," Dan writes.  Ross Rader added that "the 
OECD statements make statements concerning the whole based on 
observations of the parts.  As a result, the conclusion doesn't 
hold, despite its base in a valid root observation."  
<http://www.dnso.org/clubpublic/ga/Arc10/msg00251.html>,  
<http://www.dnso.org/clubpublic/ga/Arc10/msg00253.html>,  
<http://www.dnso.org/clubpublic/ga/Arc10/msg00254.html>.


(ii) The UDRP, and court orders.  James Love forwarded some  
information on the CNNews.com case: "The registrar is apparently in  
Hong Kong.  ICANN has recently written the registrar, telling them  
to turn over the domain to Time-Warner's CNN subsidiary.  There is a 
complicated legal dispute over whether or not the Virginia court has 
jurisdiction over Eastcom, and even whether or not the Virginia  
court has ordered Eastcom to do anything.  But CNN's lawyers wrote  
the ICANN, who then wrote Eastcom, and say that Eastcom is obligated 
to comply with the Virginia court order under the terms of its  
accreditation agreement." James' message included links to some of  
the correspondence.  Finally, he asks whether there is "some policy  
guidance as to when ICANN should jump in and take matters into its  
own hands to enforce one nation's court orders in a cross border  
dispute over jurisdiction?"
<http://www.dnso.org/clubpublic/ga/Arc10/msg00255.html>

I posted a follow-up note stating that "I seem to understand that  
paragraph 3(b) of the UDRP is believed to be applicable." Dan  
Steinberg (who represents the GA on the UDRP task force) followed up 
to this and reminded participants to be careful what exactly we are  
talking about.  In particular, he notes that paragraph 3(b) of the  
UDRP governs the actions of the registrar, not ICANN's.  (The 
paragraph in question says that the registrar will "cancel,  
transfer or otherwise make changes to domain name registrations  
under the following circumstances: [...] receipt of an order from a  
court or arbitral tribunal, in each case of competent jurisdiction,  
requiring such action") 

As a conclusion, Dan writes: "Given that apparently 3b does not  
oblige ICANN to intervene, we must ask does it mean that ICANN  
cannot or should not intervene? or does it fall under general  
discretionary authority?"
<http://www.dnso.org/clubpublic/ga/Arc10/msg00264.html>,
<http://www.dnso.org/clubpublic/ga/Arc10/msg00270.html>.

Maybe the UDRP task force should cover this question in its work?

(iii) Independent Review.  I sent a couple of possible options for  
independent review mechanisms to the GA list.  Joop Teernstra  
replied that he thinks "it is misguided to now start casting about  
for watered-down alternatives." The only idea he likes "is that of  
an industry Ombudsman, but this office could be separated from ICANN 
altogether and should not be used for review of board decisions."  
Peter Dengate-Thrush followed up to state his agreement.  "As a  
member of the IRAC," he writes, "I can say this was one of the early 
successes of ICANN - a policy worked out by an industry led group in 
transparent bottom up style, passed to the board posted for public  
comment and approved by the community." He then gives some details  
on the implementation process, in which three out of six members of  
the nomination committee proposed a list of names for an independent 
review panel, while the other three did not actively support that 
list.
<http://www.dnso.org/clubpublic/ga/Arc10/msg00257.html>,
<http://www.dnso.org/clubpublic/ga/Arc10/msg00258.html>,
<http://www.dnso.org/clubpublic/ga/Arc10/msg00259.html>.

In related news, another member of the Independent Review Advisory  
Committee, Ethan Katsh, has sent a reconsideration request to ICANN. 
He specifically asks for the board resolutions 02.46 and 02.47 to be 
reconsidered.  In these resolutions, the independent review issue is 
passed on to the Evolution and Reform Committee.  Katsh argues that  
the board based its decision exclusively on implementation problems, 
which could be solved by, for instance, replacing some of the  
members of the nomination committee.  "The response of the Board to  
disband the committee, rather than to attempt to get new members or  
replace non-participating ones, cannot be an action that is  
consistent with what the MOU requires," Katsh writes.   
<http://www.umass.edu/cyber/icannreview.htm>,   
<http://www.icannwatch.org/article.php?sid=670&mode=nested&order=1&thold=1>,
<http://www.icann.org/minutes/prelim-report-14mar02.htm#02.46>.

Finally, yet another proposal for an independent review panel can be 
found in a business constituency draft quoted and criticized by  
Danny Younger: "a <<committee which could include, the GAC chair,  
the IAB chair, two board members or past board members, and an  
appointed and paid ombudsman>>."
<http://www.dnso.org/clubpublic/ga/Arc10/msg00292.html>,
<http://www.dnso.org/clubpublic/ga/Arc10/msg00296.html>.

(iv) Evolution / GA.  Philip Sheppard posted a personal reflection  
on the relationship between the NC and GA.  In his message, he  
suggests to get all groups who represent significant stakeholders to 
form a constituency, and participate in the NC.  For individual  
domain name holders, the at-large structure is used. Finally, all  
constituencies vote for a DNSO chair "who simultaneously chairs the  
NC and GA." Alexander Svensson agreed that "individual gTLD  
registrants must have a recognized place in gTLD policy  
development," but disagrees on using an at large structure for this  
representation since an at large membership would encompass more  
than just domain name holders.  
<http://www.dnso.org/clubpublic/ga/Arc10/msg00265.html>,  
<http://www.dnso.org/clubpublic/ga/Arc10/msg00268.html>.

Roberto Gaetano followed up to Philip with some doubts, too: "First  
of all, the GA should also be an open forum, hence not restricted in 
principle, although one would expect that the core would be built  
around the participants in the constituencies." As examples for  
people who may not be constituency members, but could still wish to  
participate, he mentions people from the PSO or ASO.  "So the GA  
will include all constituencies, but not limited to." Also, he  
notes that "the logic of the representativity in the GA is 'one  
individual - one voice', which is different from the  
NC/constituencies" - and can lead to results different from what a  
vote which is counted by constituencies would yield.  Roberto also  
disagrees about using an at large membership as an "eight  
constituency" because (1) it should include individuals who may just 
have an interest in non-DNSO ICANN issues, and (2) such a  
constituency would be unmanageable.  Starting from the same  
assumptions as Philip, Roberto ends up with two options for a  
solution: "1. dynamically correct the constituency structure with a  
mechanism to add/delete/modify the number of constituencies when  
needed (remember the 'Paris Draft'?) 2. get rid altogether of the  
constituency structure and replace it with a GA type structure (Karl 
Auerbach's solution, identifiable to a certain extent with the BWG  
draft)." <http://www.dnso.org/clubpublic/ga/Arc10/msg00266.html>.

(v) Unrelated reregistrations.  Ben Edelman asked for assistance  
with "unrelated reregistrations." The example which prompted his  
research was a search for a bicycle dealer, which lead him to a  
"sexually-explicit" site which resides under the domain name no  
longer used by Bicycle Bill.  The links below lead to the  
discussion on this, which includes a couple of suggestions how to  
find more examples of the kind of reregistration Ben mentioned;  
these suggestions included mining old and current versions of TLD 
zone files, and looking at older SnapNames.com lists of successful 
SnapBacks.
<http://www.dnso.org/clubpublic/ga/Arc10/msg00304.html>,  
<http://www.dnso.org/clubpublic/ga/Arc10/msg00305.html>,  
<http://www.dnso.org/clubpublic/ga/Arc10/msg00306.html>,  
<http://www.dnso.org/clubpublic/ga/Arc10/msg00307.html>,  
<http://www.dnso.org/clubpublic/ga/Arc10/msg00310.html>.

George Kirikos noted that "from an ICANN policy point of view these  
matters are related to:" 1. uniform deletions regulation and  
transfer policies, 2. whois data correctness, 3. better education of 
the end user community. 
<http://www.dnso.org/clubpublic/ga/Arc10/msg00311.html>.

If you want to help Ben with his research, please go to 
<http://cyber.law.harvard.edu/people/edelman/renewals/submit/> and 
submit more examples.

-- 
Thomas Roessler                          http://log.does-not-exist.org/
--
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



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