<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-igo-ingo] Thoughts on fact-based policy development
- To: "GNSO IGO INGO" <gnso-igo-ingo@xxxxxxxxx>, "Alan Greenberg" <alan.greenberg@xxxxxxxxx>
- Subject: Re: [gnso-igo-ingo] Thoughts on fact-based policy development
- From: "Christopher Lamb" <christopher.lamb17@xxxxxxxxx>
- Date: Wed, 23 Jan 2013 22:52:32 +1100
Dear Alan,
Thanks for this. I'd just add that there are a very large number of domains
which use redcross or redcrescent in association with a country code. You
mention redcross.ca and I won't list all the others of which I'm aware
unless you wish me to do so, but Switzerland is an example worth noting -
the main website is redcross.ch but croixrouge.ch, crocerossa.ch and
roteskreuz.ch all lead to it. The website redcrescent.org was owned by
someone in the US a couple of years ago and dormant, but now appears to hold
a lot of information related to disasters - but it doesn't appear to be
owned by any organisation in the Red Cross Red Crescent Movement. Another
which worries me is http://www.croix-rougecamerounaise.org/, an example of
what should not be possible and which is probably entirely beyond the
control resources of the Cameroon Red Cross Society.
There are many examples of people trying to make money out of the redcross
brand in domain sales. Have a look at laoredcross.org, which has nothing to
do with the Red Cross Society of Laos. Redcross.me is for sale. Quite a
lot of country code domains are a source of concern, and although they're
not part of the current study they offer examples of the way fraudsters and
money-makers work. The RCRC Movement spends a lot of time and resources
getting the relevant authorities to remove these sites, usually
successfully, but it is very resource-intensive and a special problem when
domains appear from nowhere after virtually every newsworthy disaster with
worldwide coverage. As you would expect, these people expect to make all
their money in the first 48 hours while media coverage of the suffering is
at its most intense, and lengthy procedures are completely ineffective - in
all cases which I've tracked the looters disappear with their money long
before any procedure could get started.
There are also cases of abuse with the intention of denigrating the National
Society concerned. One, a few years ago, concerned the abuse of the name of
the Hungarian Red Cross in the US. There have been others aimed at National
Societies which chose to use acronyms or initials for their domain name and
exposed themselves to danger - one was the Palestine Red Crescent Society
whose domain palestinercs.org was mirrored and then abused in
palestinercs.net. This isn't a subject covered by our current work, and
it's my hope that when we resolve the future TLD system the RCRC Movement
should ask National Societies to regularise their naming protocols in
accordance with that system.
I did a survey of the misuse or abuse of the names of National RCRC
Societies in February 2011 and without difficulty found and reported 19
egregious cases. Following that most were able to be removed, but some,
like the Lao and Cameroon cases, are still there. Time permitting, I would
look into this again if it were necessary, but the hard fact is that the
redcross and redcrescent names are abused as a matter of course after
significant newsworthy natural disasters or conflicts. A spectacular one in
2005 enticed the unsuspecting public to donate to a bogus thing called the
Santa Maria Red Cross Tsunami Survivors Fund. You won't find it any more,
but what we did to put it down is a great story worthy of a movie script.
Not what we should be aiming for through this process, of course.
I recognise that this will look like an anecdotal commentary, but it's also
reality.
Best wishes
Chris
-----Original Message-----
From: Alan Greenberg
Sent: Wednesday, January 23, 2013 4:44 PM
To: GNSO IGO INGO
Subject: [gnso-igo-ingo] Thoughts on fact-based policy development
Both I and the ALAC in its recent statement have stated that if we
are going to take the large and unusual step and provide special
protection to IGO/INGO names, we should do so understanding what
problem(s) we are trying to solve and have a high level of comfort
that the proposed solution actually will address these problems.
To take a large number of character strings out of circulation, or at
least put in place significant (no doubt both costly and
time-consuming) hurdles to using these strings without a substantive
benefit is counter to the culture that has allowed the Internet to
thrive. Moreover, it sets the stage for even more similar requests in
the future, both on the basis of TMs and "public money".
To date, we have seen virtually no data related to IGOs and little
related to INGOs on the problems they currently suffer that would be
relieved with the reservation or blocking of their requested
exact-match names and acronyms.
To try to get a feel for whether this is just an obstreperous
objection or really has merit, I undertook a small and not
necessarily representative study of the names of a number of
organizations. Specifically NATO, ITU, UPU, CERN, WHO, ILO, UNICEF
and RedCross. All except the last two were signatories of the letter
requesting protection for IGO names (recently resent to this group
along with the UPU statement appended to the RySG input, but which
also can be found at
http://www.icann.org/en/news/correspondence/igo-counsels-to-beckstrom-et-al-13dec11-en.pdf).
I checked to see whether their names were registered in a number of
TLDs, specifically int, com, net, org, info, biz, us, ca and eu, who
they were registered to, and what use was being made of the domain
name (from a web point of view). The results are attached.
- Lines highlighted in Dark blue are used by the organization in
question (or an affiliate). Light blue are sort of used by them, but
is not actually an active web site, or is used in a rather curious
way, or is seemingly owned by a private individual who redirects the
site as a matter of courtesy.
- Lines highlighted in dark green seem to be legitimate uses of the
name but not by the organization in question. There is a pale green
entry that would be reasonable except it is largely a monetization site.
There are large number of monetized pages, and a fair number of uses
of names for which I can see no rationale at all. In no cases has any
of the organizations in question taken control of all of the names.
For the first few, I also did a reviews search on the e-mail admin
contact address listed in the Whois, as some measure of how many
other domain names are managed by that organization. The short answer
is "not many" for those that I looked at. I stopped when my free
access to the reviews whois engine was cut off.
This was an interesting exercise, but as stated earlier, there is no
pretense of this being a definitive analysis. But it does bring into
question just how important the requested reservations are, what uses
would such reservations rule out if implemented as complete blocking,
and what harms will be prevented by their implementation.
I strongly suggest that at the least, we request specific information
from the organizations that have explicitly requested protection (at
the very least RCRC, IOC, and the organizations identified in the
13Dec11 letter). This should include:
- A list of TLDs in which they have registered their requested names,
or otherwise taken action to prevent them being registered by others.
- Identification of any disputes over identical names, names that
would have been disallowed if the requested policy had been in place
for all gTLDs, and the outcomes of these disputes.
- Identification/elaboration of the harms caused by the above cases.
- An estimate of the magnitude of these cases compared to other
domain name conflicts which will not be prevented by the requested
gTLD protections.
Lastly, I would suggest that we ask whether they would:
- Expect exceptions to the reservation of their names to allow their
own registration of the names
- How they contemplate allowing exceptions for the legitimate use by
others of the names.
Alan
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|