Berry, The summary table on the first page quotes 'RAP Recommendation' - this needs to be amended to 'Report Category'. I support the positions outlined and appreciate all your work on this. Best regards, Martin Martin C SUTTON Group Risk Manager, Group Fraud Risk and Intelligence | HSBC HOLDINGS PLC HGHQ Group Security & Fraud Risk 8 Canada Square,Canary Wharf,London,E14 5HQ,United Kingdom ________________________________________________________________ Phone. +44 (0)20 7991 8074 / 7991 8074 Mobile. +44 (0) 7774556680 Email. martinsutton@hsbc.com ________________________________________________________________ berrycobb@infinityportals.com Sent by: owner-bc-gnso@icann.org Mar 31 2010 00:01 Mail Size: 88048 To bc-GNSO@icann.org cc Subject [bc-gnso] Last Call: CBUC Position on Registry Operations Baseline Entity HSBC Holdings plc - GMO CBUC Last call, folks. Below is the draft CBUC position on the Registry Operations Baseline Study. To date, only NetChoice has supplied comment and approval of the position statement. Absent objections by COB tomorrow, we will file as consensus CBUC comments on 1-Apr-2010. Thank you. --B Berry Cobb Infinity Portals LLC 866.921.8891 [attachment "BC_Position_RyBaseline_Draft_03312010.docx" deleted by Martin C SUTTON/GMO/HSBC] ************************************************************ HSBC Holdings plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England number 617987 ************************************************************ ----------------------------------------- SAVE PAPER - THINK BEFORE YOU PRINT! This E-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return E-mail. Internet communications cannot be guaranteed to be timely secure, error or virus-free. The sender does not accept liability for any errors or omissions.

Thanks Steve, Jon and Ron. I support this position. Mike Rodenbaugh RODENBAUGH LAW tel/fax: +1 (415) 738-8087 <http://rodenbaugh.com/> http://rodenbaugh.com From: owner-bc-gnso@icann.org [mailto:owner-bc-gnso@icann.org] On Behalf Of Steve DelBianco Sent: Tuesday, March 30, 2010 3:31 PM To: bc-GNSO@icann.org Subject: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3 Last call, folks. Below is the draft BC position on new TLD Registry Agreement Amendments. Ron Andruff and Jon Nevett provided the draft. I've signaled my agreement, as did Berry Cobb. Absent objections by COB tomorrow, we will file as consensus BC comments on 1-Apr-2010. --Steve Business & Commercial Users' Constituency (BC) Position/Comments on Process for Amendments to New gTLD Registry Agreements The Commercial and Business Users Constituency (BC) welcomes the opportunity to comment on the New gTLD Program Explanatory Memorandum on the Process for Amendments to New gTLD Registry Agreements, which was published for public comment on February 15, 2010 (see http://icann.org/en/announcements/announcement-4-15feb10-en.htm ). ICANN seeks comment as to a fair process to amend New TLD registry agreements. In DAG v.3, ICANN proposed that it could unilaterally amend registry agreements even after a majority of the registry operators rejected such amendments. The Registries Stakeholder Group (RySG) recently has proposed a system of good faith negotiations between ICANN and the registry operators, but that each registry would have a veto on proposed changes to that registry agreement. As a matter of policy, the BC believes that businesses should not be subject to agreements where the other party has the unilateral right to amend such an agreement. ICANN's proposal in which the ICANN Board could unilaterally impose a change to registry agreements notwithstanding the objections of a majority of registry operators, the BC, or any other ICANN organization is an anathema to ICANN's bottom-up policy making roots. Similarly, the RySG's proposal, in which each individual registry has the ability to veto a proposed change, also is inconsistent with the efficient functioning and scalability of the New gTLD program. This issue requires a "balanced" approach that satisfies both parties. The BC analyzes the issue based on whether proposed changes are within the so-called "picket fence" - and subject to Consensus Policy - or not. All contractual changes should be made in a transparent manner with input from the community. For issues within the picket fence, there is an existing Policy Development Process that carries the power to change all registry and registrar agreements. As described in current and proposed registry contracts, the picket fence includes most conceivable ways that community and BC members would need to control registry practices: 1.2.1. issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS; 1.2.2. functional and performance specifications for the provision of registry services; 1.2.3. Security and stability of the registry database for the TLD; 1.2.4. registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars; or 1.2.5. resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names). 1.3.1. principles for allocation of registered names in the TLD (e.g., first-come/first-served, timely renewal, holding period after expiration); 1.3.2. prohibitions on warehousing of or speculation in domain names by registries or registrars; 1.3.3. reservation of registered names in the TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); and 1.3.4. maintenance of and access to accurate and up-to-date information concerning domain name registrations; and procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving registered domain names in a TLD affected by such a suspension or termination. Source: http://icann.org/en/topics/new-gtlds/draft-agreement-specs-clean-04oct09-en. pdf By way of example, a picket fence PDP was how the BC and other community members put a stop to domain tasting that was occurring by abuse of the add-grace period. While many felt that a 2-year PDP and implementation process took too long, this experience showed that the system works, generating a policy outcome that became part of all registrar and registry agreements. Therefore, ICANN shouldn't have the ability to unilaterally change such agreements without community consent, and the BC does not see any need for a separate process for amendment on top of the current PDP process. The ICANN community is tasked with making policy; not the ICANN Board or staff. We have a process to make changes now. If that process needs improvement, let's improve it. Giving ICANN the ability to unilaterally amend the Registry contract is not the answer. Certain other issues outside the picket fence also should not be subject to unilateral changes, such as pricing, ICANN fees, and other similar topics where neither party can unilaterally amend an agreement without consent of the other party to the contract. There are some issues outside the picket fence, however, where ICANN and/or the community should be able to amend registry agreements without the specific consent of every single registry operator, as long as there is a consensus of the community. These issues should include security and stability issues, enforcement tools, registrant protections, and promoting a stable marketplace, and should be enforceable against all registry operators. For example, compliance staff must have the tools to enforce the registry agreements against potential bad actor registries. One rogue registry should not be able to veto changes that the rest of the community supports. Similar changes to the Registrar Accreditation Agreement were recently adopted without each registrar being able to veto the changes. Even with such rogue issues, neither the ICANN staff nor the Board should be able to amend registry agreements without community involvement and input from the registry operators. All changes - regardless of the issue -- must be transparent and exhibit the appropriate level of accountability to the community. ICANN needs to strike a balance in the manner in which registry agreements are amended. In the BC's view, neither the current ICANN proposal nor the RySG proposal succeeds in doing so yet.

Marilyn ‹ I think your notes on the domain tasting episode actually help showwhy it¹s a great example of how we can use the Consensus Policy Œpicket fence¹ to amend all registry and registrar contracts. As you say, some contract parties did not support the domain tasting policy change. But the PDP process and community pressure eventually did prevail ‹ thanks in large measure to your own persistence on this issue. Once staff provided implementation details, the new policy was automatically applied to ALL contracts, without delays, lawsuits or appeals. I can¹t think of a better example of how we empower the community to develop consensus policies that force all contract parties to comply, no matter what¹s in their own contract/agreement or business plan. Seeing it in that light, would you agree to retain the example in our position statement? --Steve On 3/31/10 7:41 AM, "Marilyn Cade" <marilynscade@hotmail.com> wrote:

Thanks, Steve, Jon, and Ron, for your work on this position. I largely support the perspective in the document.

However, I would propose a change: I think that your use of domain name tasting as an example is actually not fully factual. I'd propose that you simply strike that example. The PDP 06 is a better example, but I don't think you should substitute it. Instead, just strike the reference to the specific example. [first paragraph under the source: citation]. It would take too much time and detail to factually explain this topic. I'd propose just to remove it as an example.

Background to why I am proposing that change: The BC [and IPC] led a significant effort to push forward awareness of kiting, tasting, and parking, against considerable opposition from some other constituencies within ICANN. The data gathering efforts, which included informational exchanges with the ICANN staff and Board, and by some members of the BC with legal and operational staff was very challenging. The PDP process could have floundered due to lack of support by some of the constituencies. Some parties in the business community undertook extensive work, outside of ICANN, to deal with aggregious tasting/parking/kiting when it involved trademarked names. These actions helped to educate and inform ICANN staff and Board. Ultimately, it was the combination of external and awareness efforts that built willingness to address this contentious issue within the ICANN PDP process.

Overall comment: In reading this, i would note that the BC needs to be very sensitive in our positions, focusing on our role and responsibility as the BC, to be business user centric. Business users are affected by these policies differently than the supplier/contracted parties are.

Finally, there is a reference to 'rogue issues', or 'rogue registry'. A registry with very unique characteristics, such as a brands focused registry, might find certain requirements impossible to agree to -- e.g. the transfer of the registry operations in the event of a decision to close the registry. This would not make them a 'rogue' registry.

Marilyn Cade speaking in individual capacity as a BC member

From: icann@rodenbaugh.com To: bc-GNSO@icann.org Subject: RE: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3 Date: Tue, 30 Mar 2010 17:04:29 -0700

Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3 Thanks Steve, Jon and Ron. I support this position.

Mike Rodenbaugh

RODENBAUGH LAW

tel/fax: +1 (415) 738-8087

http://rodenbaugh.com <http://rodenbaugh.com/>

From: owner-bc-gnso@icann.org [mailto:owner-bc-gnso@icann.org] On Behalf Of Steve DelBianco Sent: Tuesday, March 30, 2010 3:31 PM To: bc-GNSO@icann.org Subject: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3

Last call, folks. Below is the draft BC position on new TLD Registry Agreement Amendments.

Ron Andruff and Jon Nevett provided the draft. I¹ve signaled my agreement, as did Berry Cobb.

Absent objections by COB tomorrow, we will file as consensus BC comments on 1-Apr-2010.

--Steve

Business & Commercial Users¹ Constituency (BC) Position/Comments on Process for Amendments to New gTLD Registry Agreements

The Commercial and Business Users Constituency (BC) welcomes the opportunity to comment on the New gTLD Program Explanatory Memorandum on the Process for Amendments to New gTLD Registry Agreements, which was published for public comment on February 15, 2010 (see http://icann.org/en/announcements/announcement-4-15feb10-en.htm ).

ICANN seeks comment as to a fair process to amend New TLD registry agreements. In DAG v.3, ICANN proposed that it could unilaterally amend registry agreements even after a majority of the registry operators rejected such amendments. The Registries Stakeholder Group (RySG) recently has proposed a system of good faith negotiations between ICANN and the registry operators, but that each registry would have a veto on proposed changes to that registry agreement. As a matter of policy, the BC believes that businesses should not be subject to agreements where the other party has the unilateral right to amend such an agreement. ICANN¹s proposal in which the ICANN Board could unilaterally impose a change to registry agreements notwithstanding the objections of a majority of registry operators, the BC, or any other ICANN organization is an anathema to ICANN¹s bottom-up policy making roots.

Similarly, the RySG¹s proposal, in which each individual registry has the ability to veto a proposed change, also is inconsistent with the efficient functioning and scalability of the New gTLD program. This issue requires a ³balanced² approach that satisfies both parties. The BC analyzes the issue based on whether proposed changes are within the so-called ³picket fence² ­ and subject to Consensus Policy ­ or not. All contractual changes should be made in a transparent manner with input from the community.

For issues within the picket fence, there is an existing Policy Development Process that carries the power to change all registry and registrar agreements. As described in current and proposed registry contracts, the picket fence includes most conceivable ways that community and BC members would need to control registry practices:

...

1.2.1. issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS;

1.2.2. functional and performance specifications for the provision of registry services;

1.2.3. Security and stability of the registry database for the TLD;

1.2.4. registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars; or

1.2.5. resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names).

1.3.1. principles for allocation of registered names in the TLD (e.g., first-come/first-served, timely renewal, holding period after expiration);

1.3.2. prohibitions on warehousing of or speculation in domain names by registries or registrars;

1.3.3. reservation of registered names in the TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); and

1.3.4. maintenance of and access to accurate and up-to-date information concerning domain name registrations; and procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving registered domain names in a TLD affected by such a suspension or termination.

Source: http://icann.org/en/topics/new-gtlds/draft-agreement-specs-clean-04oct09-en.... df

By way of example, a picket fence PDP was how the BC and other community members put a stop to domain tasting that was occurring by abuse of the add-grace period. While many felt that a 2-year PDP and implementation process took too long, this experience showed that the system works, generating a policy outcome that became part of all registrar and registry agreements.

Therefore, ICANN shouldn¹t have the ability to unilaterally change such agreements without community consent, and the BC does not see any need for a separate process for amendment on top of the current PDP process. The ICANN community is tasked with making policy; not the ICANN Board or staff. We have a process to make changes now. If that process needs improvement, let¹s improve it. Giving ICANN the ability to unilaterally amend the Registry contract is not the answer. Certain other issues outside the picket fence also should not be subject to unilateral changes, such as pricing, ICANN fees, and other similar topics where neither party can unilaterally amend an agreement without consent of the other party to the contract.

There are some issues outside the picket fence, however, where ICANN and/or the community should be able to amend registry agreements without the specific consent of every single registry operator, as long as there is a consensus of the community. These issues should include security and stability issues, enforcement tools, registrant protections, and promoting a stable marketplace, and should be enforceable against all registry operators. For example, compliance staff must have the tools to enforce the registry agreements against potential bad actor registries. One rogue registry should not be able to veto changes that the rest of the community supports. Similar changes to the Registrar Accreditation Agreement were recently adopted without each registrar being able to veto the changes.

Even with such rogue issues, neither the ICANN staff nor the Board should be able to amend registry agreements without community involvement and input from the registry operators. All changes ­ regardless of the issue -- must be transparent and exhibit the appropriate level of accountability to the community.

ICANN needs to strike a balance in the manner in which registry agreements are amended. In the BC¹s view, neither the current ICANN proposal nor the RySG proposal succeeds in doing so yet.

-- Steve DelBianco Executive Director NetChoice http://www.NetChoice.org and http://blog.netchoice.org +1.202.420.7482

I wonder if the term is challenging to the newcomers, though, Ron. Perhaps a footnote that while not naming a registry specifically, could note that captures your first sentence. I fully support the issue/concern, but wanted to note that a 'brands' registry for instance, would have different needs. Your other excellent example is a bigger concern and one well worth noting. How about a [for example, a registry that after delegation, engages in undertakings that are demed to damage the integrity of the Internet and ICANN, and harms registrants and specific communities, or engages in actions which are deemed to create technical risks]. That last phrase would have captured 'sitefinder', I think, and wildcarding in the g's. for instance. Marilyn S. Cade 202 360 1196 or 202 251 6787 mscade@att.net or marilynscade@hotmail.com From: randruff@rnapartners.com To: marilynscade@hotmail.com; bc-gnso@icann.org Subject: RE: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3 Date: Wed, 31 Mar 2010 10:44:11 -0400 Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3 Marilyn, Regarding your comment on ‘rogue’ registries, this refers specifically to undertakings that are deemed to damage the integrity of the Internet and ICANN, which ultimately harms both individual users and specific communities. For example the current managers of .TRAVEL have been using that registry as their ‘own pool of domain names’, which irrespective of other’s IP rights are purchased and held in a separate company (held 100% by the managers of .TRAVEL) which has been set up solely to try to monetize their .TRAVEL domain names. In order to do this, they first established a self-serving bulk purchase policy at massive discounts to the industry retail price. These are the types of rogue issues that we are recommending ICANN address in the new gTLD contracts – specifically by providing compliance with effective tools to allow them to address the types of issues noted above as soon as they arise. Hope this helps to clarify the matter for you and all of the members. Kind regards, RA Ronald N. Andruff President RNA Partners, Inc. 220 Fifth Avenue New York, New York 10001 + 1 212 481 2820 ext. 11 From: owner-bc-gnso@icann.org [mailto:owner-bc-gnso@icann.org] On Behalf Of Marilyn Cade Sent: Wednesday, March 31, 2010 7:42 AM To: bc - GNSO list Subject: RE: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3 Thanks, Steve, Jon, and Ron, for your work on this position. I largely support the perspective in the document. However, I would propose a change: I think that your use of domain name tasting as an example is actually not fully factual. I'd propose that you simply strike that example. The PDP 06 is a better example, but I don't think you should substitute it. Instead, just strike the reference to the specific example. [first paragraph under the source: citation]. It would take too much time and detail to factually explain this topic. I'd propose just to remove it as an example. Background to why I am proposing that change: The BC [and IPC] led a significant effort to push forward awareness of kiting, tasting, and parking, against considerable opposition from some other constituencies within ICANN. The data gathering efforts, which included informational exchanges with the ICANN staff and Board, and by some members of the BC with legal and operational staff was very challenging. The PDP process could have floundered due to lack of support by some of the constituencies. Some parties in the business community undertook extensive work, outside of ICANN, to deal with aggregious tasting/parking/kiting when it involved trademarked names. These actions helped to educate and inform ICANN staff and Board. Ultimately, it was the combination of external and awareness efforts that built willingness to address this contentious issue within the ICANN PDP process. Overall comment: In reading this, i would note that the BC needs to be very sensitive in our positions, focusing on our role and responsibility as the BC, to be business user centric. Business users are affected by these policies differently than the supplier/contracted parties are. Finally, there is a reference to 'rogue issues', or 'rogue registry'. A registry with very unique characteristics, such as a brands focused registry, might find certain requirements impossible to agree to -- e.g. the transfer of the registry operations in the event of a decision to close the registry. This would not make them a 'rogue' registry. Marilyn Cade speaking in individual capacity as a BC member From: icann@rodenbaugh.com To: bc-GNSO@icann.org Subject: RE: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3 Date: Tue, 30 Mar 2010 17:04:29 -0700 Thanks Steve, Jon and Ron. I support this position. Mike Rodenbaugh RODENBAUGH LAW tel/fax: +1 (415) 738-8087 http://rodenbaugh.com From: owner-bc-gnso@icann.org [mailto:owner-bc-gnso@icann.org] On Behalf Of Steve DelBianco Sent: Tuesday, March 30, 2010 3:31 PM To: bc-GNSO@icann.org Subject: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3 Last call, folks. Below is the draft BC position on new TLD Registry Agreement Amendments. Ron Andruff and Jon Nevett provided the draft. I’ve signaled my agreement, as did Berry Cobb. Absent objections by COB tomorrow, we will file as consensus BC comments on 1-Apr-2010. --Steve Business & Commercial Users’ Constituency (BC) Position/Comments on Process for Amendments to New gTLD Registry Agreements The Commercial and Business Users Constituency (BC) welcomes the opportunity to comment on the New gTLD Program Explanatory Memorandum on the Process for Amendments to New gTLD Registry Agreements, which was published for public comment on February 15, 2010 (see http://icann.org/en/announcements/announcement-4-15feb10-en.htm ). ICANN seeks comment as to a fair process to amend New TLD registry agreements. In DAG v.3, ICANN proposed that it could unilaterally amend registry agreements even after a majority of the registry operators rejected such amendments. The Registries Stakeholder Group (RySG) recently has proposed a system of good faith negotiations between ICANN and the registry operators, but that each registry would have a veto on proposed changes to that registry agreement. As a matter of policy, the BC believes that businesses should not be subject to agreements where the other party has the unilateral right to amend such an agreement. ICANN’s proposal in which the ICANN Board could unilaterally impose a change to registry agreements notwithstanding the objections of a majority of registry operators, the BC, or any other ICANN organization is an anathema to ICANN’s bottom-up policy making roots. Similarly, the RySG’s proposal, in which each individual registry has the ability to veto a proposed change, also is inconsistent with the efficient functioning and scalability of the New gTLD program. This issue requires a “balanced” approach that satisfies both parties. The BC analyzes the issue based on whether proposed changes are within the so-called “picket fence” – and subject to Consensus Policy – or not. All contractual changes should be made in a transparent manner with input from the community. For issues within the picket fence, there is an existing Policy Development Process that carries the power to change all registry and registrar agreements. As described in current and proposed registry contracts, the picket fence includes most conceivable ways that community and BC members would need to control registry practices: 1.2.1. issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS; 1.2.2. functional and performance specifications for the provision of registry services; 1.2.3. Security and stability of the registry database for the TLD; 1.2.4. registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars; or 1.2.5. resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names). 1.3.1. principles for allocation of registered names in the TLD (e.g., first-come/first-served, timely renewal, holding period after expiration); 1.3.2. prohibitions on warehousing of or speculation in domain names by registries or registrars; 1.3.3. reservation of registered names in the TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); and 1.3.4. maintenance of and access to accurate and up-to-date information concerning domain name registrations; and procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving registered domain names in a TLD affected by such a suspension or termination. Source: http://icann.org/en/topics/new-gtlds/draft-agreement-specs-clean-04oct09-en.... By way of example, a picket fence PDP was how the BC and other community members put a stop to domain tasting that was occurring by abuse of the add-grace period. While many felt that a 2-year PDP and implementation process took too long, this experience showed that the system works, generating a policy outcome that became part of all registrar and registry agreements. Therefore, ICANN shouldn’t have the ability to unilaterally change such agreements without community consent, and the BC does not see any need for a separate process for amendment on top of the current PDP process. The ICANN community is tasked with making policy; not the ICANN Board or staff. We have a process to make changes now. If that process needs improvement, let’s improve it. Giving ICANN the ability to unilaterally amend the Registry contract is not the answer. Certain other issues outside the picket fence also should not be subject to unilateral changes, such as pricing, ICANN fees, and other similar topics where neither party can unilaterally amend an agreement without consent of the other party to the contract. There are some issues outside the picket fence, however, where ICANN and/or the community should be able to amend registry agreements without the specific consent of every single registry operator, as long as there is a consensus of the community. These issues should include security and stability issues, enforcement tools, registrant protections, and promoting a stable marketplace, and should be enforceable against all registry operators. For example, compliance staff must have the tools to enforce the registry agreements against potential bad actor registries. One rogue registry should not be able to veto changes that the rest of the community supports. Similar changes to the Registrar Accreditation Agreement were recently adopted without each registrar being able to veto the changes. Even with such rogue issues, neither the ICANN staff nor the Board should be able to amend registry agreements without community involvement and input from the registry operators. All changes – regardless of the issue -- must be transparent and exhibit the appropriate level of accountability to the community. ICANN needs to strike a balance in the manner in which registry agreements are amended. In the BC’s view, neither the current ICANN proposal nor the RySG proposal succeeds in doing so yet.

Agreed. Rogue by definition refers to unprincipled or dishonest actors, so I think we are ok with registries that are just unique, but not rogue. Thanks. Jon On Mar 31, 2010, at 10:44 AM, Ron Andruff wrote:

Marilyn,

Regarding your comment on ‘rogue’ registries, this refers specifically to undertakings that are deemed to damage the integrity of the Internet and ICANN, which ultimately harms both individual users and specific communities. For example the current managers of .TRAVEL have been using that registry as their ‘own pool of domain names’, which irrespective of other’s IP rights are purchased and held in a separate company (held 100% by the managers of .TRAVEL) which has been set up solely to try to monetize their .TRAVEL domain names. In order to do this, they first established a self-serving bulk purchase policy at massive discounts to the industry retail price. These are the types of rogue issues that we are recommending ICANN address in the new gTLD contracts – specifically by providing compliance with effective tools to allow them to address the types of issues noted above as soon as they arise.

Hope this helps to clarify the matter for you and all of the members.

Kind regards,

RA

Ronald N. Andruff President

RNA Partners, Inc. 220 Fifth Avenue New York, New York 10001 + 1 212 481 2820 ext. 11

From: owner-bc-gnso@icann.org [mailto:owner-bc-gnso@icann.org] On Behalf Of Marilyn Cade Sent: Wednesday, March 31, 2010 7:42 AM To: bc - GNSO list Subject: RE: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3

Thanks, Steve, Jon, and Ron, for your work on this position. I largely support the perspective in the document.

However, I would propose a change: I think that your use of domain name tasting as an example is actually not fully factual. I'd propose that you simply strike that example. The PDP 06 is a better example, but I don't think you should substitute it. Instead, just strike the reference to the specific example. [first paragraph under the source: citation]. It would take too much time and detail to factually explain this topic. I'd propose just to remove it as an example.

Background to why I am proposing that change: The BC [and IPC] led a significant effort to push forward awareness of kiting, tasting, and parking, against considerable opposition from some other constituencies within ICANN. The data gathering efforts, which included informational exchanges with the ICANN staff and Board, and by some members of the BC with legal and operational staff was very challenging. The PDP process could have floundered due to lack of support by some of the constituencies. Some parties in the business community undertook extensive work, outside of ICANN, to deal with aggregious tasting/parking/kiting when it involved trademarked names. These actions helped to educate and inform ICANN staff and Board. Ultimately, it was the combination of external and awareness efforts that built willingness to address this contentious issue within the ICANN PDP process.

Overall comment: In reading this, i would note that the BC needs to be very sensitive in our positions, focusing on our role and responsibility as the BC, to be business user centric. Business users are affected by these policies differently than the supplier/contracted parties are.

Finally, there is a reference to 'rogue issues', or 'rogue registry'. A registry with very unique characteristics, such as a brands focused registry, might find certain requirements impossible to agree to -- e.g. the transfer of the registry operations in the event of a decision to close the registry. This would not make them a 'rogue' registry.

Marilyn Cade speaking in individual capacity as a BC member

From: icann@rodenbaugh.com To: bc-GNSO@icann.org Subject: RE: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3 Date: Tue, 30 Mar 2010 17:04:29 -0700

Thanks Steve, Jon and Ron. I support this position.

Mike Rodenbaugh RODENBAUGH LAW tel/fax: +1 (415) 738-8087 http://rodenbaugh.com

From: owner-bc-gnso@icann.org [mailto:owner-bc-gnso@icann.org] On Behalf Of Steve DelBianco Sent: Tuesday, March 30, 2010 3:31 PM To: bc-GNSO@icann.org Subject: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3

Last call, folks. Below is the draft BC position on new TLD Registry Agreement Amendments.

Ron Andruff and Jon Nevett provided the draft. I’ve signaled my agreement, as did Berry Cobb.

Absent objections by COB tomorrow, we will file as consensus BC comments on 1-Apr-2010.

--Steve

Business & Commercial Users’ Constituency (BC) Position/Comments on Process for Amendments to New gTLD Registry Agreements The Commercial and Business Users Constituency (BC) welcomes the opportunity to comment on the New gTLD Program Explanatory Memorandum on the Process for Amendments to New gTLD Registry Agreements, which was published for public comment on February 15, 2010 (see http://icann.org/en/announcements/announcement-4-15feb10-en.htm ).

ICANN seeks comment as to a fair process to amend New TLD registry agreements. In DAG v.3, ICANN proposed that it could unilaterally amend registry agreements even after a majority of the registry operators rejected such amendments. The Registries Stakeholder Group (RySG) recently has proposed a system of good faith negotiations between ICANN and the registry operators, but that each registry would have a veto on proposed changes to that registry agreement. As a matter of policy, the BC believes that businesses should not be subject to agreements where the other party has the unilateral right to amend such an agreement. ICANN’s proposal in which the ICANN Board could unilaterally impose a change to registry agreements notwithstanding the objections of a majority of registry operators, the BC, or any other ICANN organization is an anathema to ICANN’s bottom-up policy making roots.

Similarly, the RySG’s proposal, in which each individual registry has the ability to veto a proposed change, also is inconsistent with the efficient functioning and scalability of the New gTLD program. This issue requires a “balanced” approach that satisfies both parties. The BC analyzes the issue based on whether proposed changes are within the so-called “picket fence” – and subject to Consensus Policy – or not. All contractual changes should be made in a transparent manner with input from the community.

For issues within the picket fence, there is an existing Policy Development Process that carries the power to change all registry and registrar agreements. As described in current and proposed registry contracts, the picket fence includes most conceivable ways that community and BC members would need to control registry practices:

1.2.1. issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS;

1.2.2. functional and performance specifications for the provision of registry services;

1.2.3. Security and stability of the registry database for the TLD;

1.2.4. registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars; or

1.2.5. resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names).

1.3.1. principles for allocation of registered names in the TLD (e.g., first-come/first-served, timely renewal, holding period after expiration);

1.3.2. prohibitions on warehousing of or speculation in domain names by registries or registrars;

1.3.3. reservation of registered names in the TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); and

1.3.4. maintenance of and access to accurate and up-to-date information concerning domain name registrations; and procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving registered domain names in a TLD affected by such a suspension or termination.

Source: http://icann.org/en/topics/new-gtlds/draft-agreement-specs-clean-04oct09-en....

By way of example, a picket fence PDP was how the BC and other community members put a stop to domain tasting that was occurring by abuse of the add-grace period. While many felt that a 2-year PDP and implementation process took too long, this experience showed that the system works, generating a policy outcome that became part of all registrar and registry agreements.

Therefore, ICANN shouldn’t have the ability to unilaterally change such agreements without community consent, and the BC does not see any need for a separate process for amendment on top of the current PDP process. The ICANN community is tasked with making policy; not the ICANN Board or staff. We have a process to make changes now. If that process needs improvement, let’s improve it. Giving ICANN the ability to unilaterally amend the Registry contract is not the answer. Certain other issues outside the picket fence also should not be subject to unilateral changes, such as pricing, ICANN fees, and other similar topics where neither party can unilaterally amend an agreement without consent of the other party to the contract.

There are some issues outside the picket fence, however, where ICANN and/or the community should be able to amend registry agreements without the specific consent of every single registry operator, as long as there is a consensus of the community. These issues should include security and stability issues, enforcement tools, registrant protections, and promoting a stable marketplace, and should be enforceable against all registry operators. For example, compliance staff must have the tools to enforce the registry agreements against potential bad actor registries. One rogue registry should not be able to veto changes that the rest of the community supports. Similar changes to the Registrar Accreditation Agreement were recently adopted without each registrar being able to veto the changes.

Even with such rogue issues, neither the ICANN staff nor the Board should be able to amend registry agreements without community involvement and input from the registry operators. All changes – regardless of the issue -- must be transparent and exhibit the appropriate level of accountability to the community.

ICANN needs to strike a balance in the manner in which registry agreements are amended. In the BC’s view, neither the current ICANN proposal nor the RySG proposal succeeds in doing so yet.

Steve, AIM supports this. It may be helpful - in keeping with past BC papers - to separate by subtitles - the factual background information and the BC position. Your text already does this. Just a question of a couple of sub-titles I believe. BC opinion starts at the paragraph "Therefore ICANN shouldn't..." Philip