Issues Report on Dispute Handling for IGO Names and Abbreviations
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
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
-- ------------------------- AmericaAtLarge.org RJPacific.com DDMF.org
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:
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/
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@L 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:
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/
-- ------------------------- AmericaAtLarge.org RJPacific.com DDMF.org
participants (3)
-
Jacqueline A. Morris -
RJGlass | America＠Large -
Wendy Seltzer