On 7/6/07, Wendy Seltzer <wendy@seltzer.com> wrote:

Thanks for the thorough arguments, Randy. I agree that .int is a far
more suitable place for IGOs to claim monopoly than across every
namespace developed or yet to be established.

The real concerns of these organizations -- that someone will set up at
redcross.biz and gather fraudulent donations -- is better addressed by
traditional legal enforcement than by twisting the DNS and UDRP to fit.
   If the current .int policies don't suffice, those should be changed,
not the much broader policies applicable to all TLDs.

--Wendy

RJGlass | America@Large wrote:
> Sorry this took so long, but in response to the Issues Report pertaining to
> dispute handling for IGO names and abbreviations, these are my thoughts.
>
> The WIPO, through the UDRP, has been increasingly monopolistic in its
> measures to control the various namespaces.  There have clearly been set
> forth TLDs which were designed for use by IGOs, namely .int and .org.
> Although there are agreements protecting the use of IGO names, it is clear
> that constituencies and organizations are trying to misuse these agreements
> for their own gain by improperly citing cybersquatting and phishing,
> commonly misconstrued and misleading terms.
>
> Let's take WIPO as one example.  In the US, the FCC delegated commercial
> radio callsigns West of the Mississippi River to be 4-letter callsigns
> beginning with a W.  Those East begin with a K.  The fact that 'WIPO radio'
> was not allocated is irrelevant.  This is a case where you could have 2
> different entities sharing the same letter combinations, if it were such.
> So, let's say I wanted to have a nonprofit organization called the 'Western
> Indian People's Organization'.  Under the assumptions that I've been
> reading, I would never be allowed to abbreviate this organization under any
> circumstance.  This just seems odd.
>
> So, some want to reserve all rights to their names across the entire
> namespace.  The Red Cross, or "International Committee of the Red Cross
> (ICRC) and the International Federation of Red Cross and Red Crescent
> Societies (the International Federation)'.  If we look at one side of the
> argument, the only names that they should be allowed to have 'given' to
> them:
> 1. InternationalCommitteeoftheRedCross.int
> 2. icrc.int
> 3. RedCrescentSocieties.int
> 4. rcs.int
> But another argument is that they should have those and every conceivable
> combination across all namespace.  In the consideration of time, I'm not
> going to list all possible combinations but I imagine it would number in
> the
> thousands.
>
> I personally cannot see the rationale that the International Committee of
> the Red Cross should be allowed to unfairly claim the registration of
> icrc.ch simply because of their standing on the world stage.  It is unfair
> and monopolistic.
>
> It seems that IANA has already adequately dealt with this matter, but
> currently is in a state of flux due to self-special interest groups:
>
> http://www.iana.org/int-dom/
>
> A. If the organization is a program/function of a treaty organization, we
> suggest you contact that organization. The program/function is eligible,
> with consent of the treaty organization, to receive a third-level domain
> within the second level .int domain operated by that organization (e.g.,
> example.un.int ). For example, if your organization is a program of the UN,
> you should contact the administrator for un.int for a third level
> domain. If
> you wish to pursue this, you should contact the appropriate officials of
> the
> organization, who can set up the third-level domain without involvement of
> the IANA. See the IANA Whois service <http://whois.iana.org/> for
> information about the administrative and technical contacts of the various
> .int domains.
>
> B. The IANA no longer grants .int domain names for international databases
> as per RFC 1591.
>
> In the past, the .int top-level domain was used both for international
> treaty-based organizations and for Internet-infrastructure purposes.
> Because
> of the need for secure and stable management of the infrastructure aspects
> of the .int domain, from the time of its inception in 1988 the .int domain
> was administered by personnel at the University of Southern
> California/Information Sciences Institute. This activity was assumed by
> ICANN as part of the transition of the IANA functions from USC/ISI to ICANN
> at the time of ICANN's establishment. In 2000 the Internet Architecture
> Board recommended <http://www.iab.org/Documents/iab-arpa-stmt.txt > that any
> new infrastructure subdomains be established within .arpa and that
> consideration be given to migrating existing infrastructure subdomains in
> .int to .arpa. See also RFC 3172
> < http://www.rfc-editor.org/rfc/rfc3172.txt>,
> Appendix A (28 April 2000 letter from Karen Rose to Louis Touton
> designating
> administration of .arpa as an additional IANA function). ICANN is currently
> working with the IAB to progress with the transition and has committed to
> the stability <http://www.iab.org/Documents/iab-arpa-stmt.txt> of the
> infrastructure subdomains within .int for however long they need to be in
> place, with guidance from IAB/IETF as to their management.
>
> Accordingly, subdomains are now established in .int only for international
> treaty-based organizations.
>
> A. If the organization is a program/function of a treaty organization, we
> suggest you contact that organization. The program/function is eligible,
> with consent of the treaty organization, to receive a third-level domain
> within the second level .int domain operated by that organization (e.g.,
> example.un.int). For example, if your organization is a program of the UN,
> you should contact the administrator for un.int for a third level
> domain. If
> you wish to pursue this, you should contact the appropriate officials of
> the
> organization, who can set up the third-level domain without involvement of
> the IANA. See the IANA Whois service <http://whois.iana.org/> for
> information about the administrative and technical contacts of the various
> .int domains.
>
> B. The IANA no longer grants .int domain names for international databases
> as per RFC 1591.
>
> In the past, the .int top-level domain was used both for international
> treaty-based organizations and for Internet-infrastructure purposes.
> Because
> of the need for secure and stable management of the infrastructure aspects
> of the .int domain, from the time of its inception in 1988 the .int domain
> was administered by personnel at the University of Southern
> California/Information Sciences Institute. This activity was assumed by
> ICANN as part of the transition of the IANA functions from USC/ISI to ICANN
> at the time of ICANN's establishment. In 2000 the Internet Architecture
> Board recommended <http://www.iab.org/Documents/iab-arpa-stmt.txt> that any
> new infrastructure subdomains be established within .arpa and that
> consideration be given to migrating existing infrastructure subdomains in
> .int to .arpa. See also RFC 3172
> <http://www.rfc-editor.org/rfc/rfc3172.txt >,
> Appendix A (28 April 2000 letter from Karen Rose to Louis Touton
> designating
> administration of .arpa as an additional IANA function). ICANN is currently
> working with the IAB to progress with the transition and has committed to
> the stability <http://www.iab.org/Documents/iab-arpa-stmt.txt> of the
> infrastructure subdomains within .int for however long they need to be in
> place, with guidance from IAB/IETF as to their management.
>
> Accordingly, subdomains are now established in .int only for international
> treaty-based organizations.
>
> ---------------------
>
> In my humble opinion, namespace has already been allocated to these
> organizations and should be dealt with within this (.int) namespace and not
> across all registries.
>
> Randy Glass
> A@L
>
>
>
> On 6/18/07, Jacqueline A. Morris <jam@jacquelinemorris.com> wrote:
>>
>>  The GNSO Council has received an Issues Report pertaining to dispute
>> handling for IGO names and abbreviations –
>>
>> http://gnso.icann.org/mailing-lists/archives/council/msg03586.html
>>
>>
>>
>> The ALAC would appreciate feedback from the AtLarge on this issue.
>>
>>
>>
>> Jacqueline
>>
>>
>>
>> No virus found in this outgoing message.
>> Checked by AVG Free Edition.
>> Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 6/17/2007
>> 8:23 AM
>>
>> _______________________________________________
>> ALAC mailing list
>> ALAC@atlarge-lists.icann.org
>>
>> http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
>>
>>
>> At-Large Official Site: http://www.alac.icann.org
>> ALAC Independent: http://www.icannalac.org
>>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ALAC mailing list
> ALAC@atlarge-lists.icann.org
> http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
>
> At-Large Official Site: http://www.alac.icann.org
> ALAC Independent: http://www.icannalac.org

--
Wendy Seltzer -- wendy@seltzer.org
phone: +1.617.418.3456 / +44 (0)1865 287203 // cell: 07785 550361
Visiting Fellow, Oxford Internet Institute
Fellow, Berkman Center for Internet & Society
http://cyber.law.harvard.edu/seltzer.html
http://www.chillingeffects.org/