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

Sat Jul 7 23:02:06 EDT 2007

Great point Wendy.  I thoroughly agree.

I can't see where the ICRC (International Federation of Red Cross and Red
Crescent Societies) could possibly have a monopoly on the generic term 'red
cross'.  It may be their service mark (a red cross), but it is not the name
of their organization.

Similarly, at an airport, a guy walked up asking for donations -
real-looking credentials and all with pictures of smiling homeless people.
How am I to know this guy is for real?  You know what, I don't care because
he had a lighter and I gave him a dollar anyway.

Likewise, what they do within .int - don't really care, The ICRC can have
any combination of domains that contain R and C for that matter.  (By the
way, ICRC.int doesn't even resolve, so may the real scammers take a step
forward, please).

aloha,
Randy Glass
A at L

On 7/6/07, Wendy Seltzer <wendy at 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 at 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 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
> >>
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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
>
>
> --
> Wendy Seltzer -- wendy at 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/
>

-- 
-------------------------
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/20070707/35dcf8f5/attachment.html 