[At-Large] Issues Report on Dispute Handling for IGO Names and Abbreviations

Fri Jul 6 07:41:35 EDT 2007

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

On 6/18/07, Jacqueline A. Morris <jam at 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 at 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
>

-- 
-------------------------
AmericaAtLarge.org
RJPacific.com
DDMF.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://atlarge-lists.icann.org/pipermail/at-large_atlarge-lists.icann.org/attachments/20070706/f93465ec/attachment.html 