March 2010 - Bc-gnso - lists.icann.org

BC Draft Position on New TLD Registry Agreement Amendments DAG v3
by Ron Andruff 06 Apr '10

06 Apr '10

Dear Fellow Members, Please find the draft BC position on new TLD Registry Agreement Amendments attached. This draft position is open for discussion/amendment through April 1st, 2010. Thanks to Jon Nevitt for carrying the ball on this one! Kind regards, RA Ronald N. Andruff President RNA Partners, Inc. 220 Fifth Avenue New York, New York 10001 + 1 212 481 2820 ext. 11

9 15

Whois Studies discussion at 1-Apr GNSO Council Meeting
by Steve DelBianco 01 Apr '10

01 Apr '10

Mike & Zahid -- You asked for some BC membership views on the Whois studies that will be discussed at your Council meeting tomorrow (1-Apr). See below and attachment. Hope this helps. Your agenda shows potential actions on Whois studies: > 3.4.1 Review and assess cost and feasibility estimates for the studies > 3.4.2 Decide whether to pursue any of the studies and, if so, which ones > 3.4.3 Provide input into the FY11 budget process > 3.5 How should we accomplish the above? > Should we form a drafting team to develop recommendations for > consideration in our next meeting? > Note that a final budget has to be finished by 17 May and there are > currently no funds budgeted for Whois Studies My recommendations: Let¹s proceed with the Misuse and Registrant Identification studies. > The Misuse and Registrant ID studies are likely to generate data that would > affect policy decisions and compliance work. These 2 studies are not going to > stop the long-standing disagreements between passionate parties on either > side, but that¹s not the point of doing studies. Remember the debate over > domain tasting? Fact-based data on the number of deletes with the AGP were > astounding, and helped us enact a policy change. The data did not make > everyone agree on whether domain tasting was harmful. But facts showed a > hugely prevalent use of AGP that was outside its original purpose, and that > moved us to a new consensus policy. > > We¹ll certainly use study data when setting policy and compliance standards, > especially with so many new TLD operators coming online next year. > > Moreover, the Affirmation of Commitments (9.3.1) requires ICANN to ³organize a > review of WHOIS policy and its implementation to assess the extent to which > WHOIS policy is effective and its implementation meets the legitimate needs of > law enforcement and promotes consumer trust². The Misuse and Registrant data > studies will be essential for that review. > > We will also want to have these study results on hand so they can be compared > with study results after new TLDs are operating for one year, as required by > the Affirmation of Commitments item 9.3 Let¹s go right to the core issue of Money. Consider this discussion that happened during Council meeting in Nairobi: > Liz Gasster described some study proposals as "expensive" and then Stefane and > Wolf commented on the costs and budget constraints. > > I intervened to say that the lack of fact-based studies has itself been very > expensive over several years of time & travel on the part of dozens of > community members. Those costs will continue unless/until we have facts at > hand to make policy decisions. > > Marilyn made a similar point about need for fact-based analysis. > > Bruce Tonkin recommended that Council budget a lump sum for studies, then > decide how to spend it. Don't budget each specific study, he said. > > I believe Bruce Tonkin is right. Council should ask for a budget of $XXX,XXX > in FY 2011 for a general category of Whois studies. Since we need a budget > number now, I¹d say $360,000, to cover the misuse and registrant studies > ($150K each) plus a 20% contingency. > Next steps: I would ask staff to begin negotiating with the two superior¹ bidders on detailed workplan for their studies. Staff should start by asking bidders to review: > > The 4-Mar-2009 Council resolution on Whois studies, including the original > rationale for each hypothesis, etc. > > The Affirmation of Commitments, items 9.3 and 9.3.1 > > Staff should also show the bidders any Whois-related items in the Draft > Applicant Guidebook. > > Superior Bidders can then prepare detailed study workplans that policy staff > can analyze and present to Council later this year. Note: The Staff report (page 7) mentions the Whois Accuracy report, and asks whether ³barriers to accuracy² provide useful insights to policy. > > I would answer, ³Accuracy is something we aspire to; whereas inaccuracy is a > contract compliance problem.² > > Let¹s set high aspirations to require accurate Whois data for registrants, > even if we know that lots of data is inaccurate today. After all, registrars > manage to gather credit card information that¹s sufficiently accurate to > ensure they get paid. Let¹s find ways to ensure they apply the same > diligence in collecting and validating public Whois data. > > (Note: Susan Kawaguchi of Facebook volunteered to draft BC comments on Whois > Accuracy report. Those aren¹t due until 15-Apr) Whois Studies Reports and resources: > https://st.icann.org/gnso-council/index.cgi?whois_discussion# > http://gnso.icann.org/issues/whois/whois-studies-report-for-gnso-23mar10-en…> f > Presentation Slides: > http://gnso.icann.org/correspondence/whois-studies-presentation-01apr10-en.… -- Steve DelBianco Executive Director NetChoice http://www.NetChoice.org and http://blog.netchoice.org +1.202.420.7482

1 1

Comments from Marilyn Cade: Another Last Call: BC Position - Baseline Registry Operations Report
by Marilyn Cade 01 Apr '10

01 Apr '10

Barry, Steve, Thanks Barry, for your work on this. I have a couple of suggestions, and point out a couple of editorial changes that you will want to make. I provide several suggestions ,and put into bold some of the key words/and new proposed language to try to make this easier to understand and follow. Overall great job. A few critical changes proposed. For the longer term, I know that there are other discussions to be had about a 'template' or 'templates' for BC policy positions and, I do hope that you will play a leadership role in that process. On the substance of this comment, I would suggest that you change the legend on some of the elements to !. For instance, although the category: "Reserves" says no comment, actually the BC does have a comment. Capital Expenditures: says no comments, but does offer a very important comment. Continuity Planning, legend says no comment, but we do have a comment. I'd just suggest changing the legend to "!", and editing out the /NO comment on those issues. Finally, I wanted to call your attention and others to the need to have a category that is 'brands related gTLD registry'. Youcould add a footnote to 'registry population', noting that there may be a category of registries that are operated by a brand holder, for their subscribers, or employees, and that this category is not addressed, to date, in ICANN's work. In the Survey Demographics section. The first bullet point needs to have an edit in the last reference to the ccTLDs. it should read "..... under different contractual obligations to ICANN than ccTLDs. I think you mean ... "than gTLDs". Discussion Point: I spent a good deal of time studying ccTLDs when I was chairing the first WHOIS Task Force. The working methods of the cc's are indeed a good barometer for learning. Sometimes this is not well understood by business users who primarily register in cc's defensively. And, there are other factors that limit the exposure of business users to the ccTLD managers -- e.g. while we once held dialogues with the cc's that has gone by the wayside and the primary focus is on the gTLDs. And, then the reality is that the gTLDs registries often believe that they are the 'rightful choice' for back engines for future gTLDs and even for ccTLDs. As BC, we need to agnostic about business preferences. Business uses can register in either gTLDs or ccTLDs and need to have a broadened understanding of the role and activities of the ccTLDs for many reasons. I'd propose that we soften the comments about the cc's. For instance, I disagree with the proposal that the review of cc's be limited to those ccTLDs that mimic gTLDs -- I do not agree. That would eliminate .de; .uk, and .ca, and .cn, for example, all of which are large and complex ccTLDS, often more complex and technically sophisticated than many of the smaller gTLDs. A few cc's are marketed as 'global' TLDs, and that has disconcerted, or annoyed some gTLD registries. That is a perspective of gTLD registries that may not not actually serve the broader global business user communities' interest. For instance, if you are a small Kenyan business, you may both prefer to register in .ky and find advantage in doing so. You may also want to register in a gTLD as well, however. Global business users are registering in ccTLDs in many cases to have identity in the country they are doing business in. Understanding cc's practices is a 'good thing'. I'd prefer to strike the statement "Perhaps ccTLDs that mimic a gTLD should be chosen'. Instead, I'd propose that the BC statement read: The CBUC supports the inclusion of ccTLDs in this study and is interested in ensuring that the sample is fully representative of different practices and models, including analyzing different 'sizes" of cc TLD registries. In your bullet about slide 4, the language seems to need some editing. Finally, I do not support ICANN's outsourcing of compliance, and I suggest that the BC should not support that. The present position offered could be strengthened by changing the statement to proposed new statement: "Enforcement and compliance should remain a primary function of ICANN itself. Outsourcing of such functions may create vulnerabilities for ICANN to fulfull its core responsibilities and any proposed outsourcing should be carefully studied, and the subject of further public comment before proceeding with any such initiatives. ICANN may be proposing an initial cost savings approach that will ultimately harm the registrants and limit ICANN's ability to fulfill its core responsibilities. " Technical and Network Architecture: This BC statement could use the same footnore reference mentioned above regarding brands registries. > Date: Tue, 30 Mar 2010 18:57:58 -0400 > Subject: [bc-gnso] Another Last Call: BC Position - Baseline Registry Operations Report > From: sdelbianco(a)netchoice.org > To: bc-GNSO(a)icann.org > > Another Last Call before closing on a BC comment. > > Attached is the draft BC position regarding the report on Baseline Registry > Operations. > > Berry Cobb circulated the draft back on 23-Mar (see below). I¹ve signaled > my agreement. > > Absent objections by COB tomorrow, we will file as consensus BC comments on > 1-Apr-2010. > > --Steve > > On 3/23/10 3:16 AM, "Berry Cobb" <berrycobb(a)infinityportals.com> wrote: > > BC, > > Attached is the first draft of the CBUC position statement for the Baseline > Registry Operation report released by ICANN. Overall, I feel KPMG performed > well and provided meaningful views of the data. It is ashamed that more > participants were not a part of the sample data. > > My Registry operations experience is limited, so I ask the BC team to take a > strong look at the report and the initial comments I provided. I especially > invite our members that have direct Registry operations experience > to enhance our position about this study and its future use by the gTLD > Evaluation teams. > > This material is sure to have a direct impact to the next Draft Applicant > Guidebook version 4 to be released just prior to Brussels. In a > quick review, the following are what I believe to be sections of the DAGv3 > where this study could influence the Application Evaluation Criteria, or > the Application Process both of which will be used by the gTLD Evaluation > teams. > > 1.2.2 Required Documents for Application > 1.4.2 Application Form > 2.1.2 Applicant Reviews > 2.1.3 Registry Services Review > 2.2.1 Technical/Operational or Financial Extended Evaluation > 2.2.2 DNS Stability Extended Evaluation > 2.2.3 Registry Services Extended Evaluation > > The comment period closes April 1st, so I ask for your quick > turn-around. As Steve DelBianco eluded to in our last BC call, there are a > large number of comment period closings converging at once. I thank you for > your quick response. I will compile all feedback and incorporate changes on > 3/30/2010. > > > Berry Cobb > Infinity Portals LLC > San Jose, CA > mailto:berrycobb@infinityportals.com > http://infinityportals.com <http://infinityportals.com/> > 866.921.8891 > >

2 2

Re: [bc-gnso] Last Call: BC Position on New TLD RegistryAgreement Amendments DAG v3
by Marilyn Cade 31 Mar '10

31 Mar '10

:-) We actually made a lot of progress /and needed to do so, due to an unfortunate attitude of some operational staff, legal staff, and Board members -- BEFORE getting to agreement to do a PDP. I agree that the PDP was an essential element to policy that is enforceable across the board. It was a large group of resellers of contracted parties, also. No need to highight the details oin the comments. In that light, I agree. Marilyn Sent via BlackBerry by AT&T -----Original Message----- From: Steve DelBianco <sdelbianco(a)netchoice.org> Date: Wed, 31 Mar 2010 12:46:34 To: <marilynscade(a)hotmail.com>; <bc-gnso(a)icann.org> Subject: Re: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3 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(a)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(a)rodenbaugh.com To: bc-GNSO(a)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(a)icann.org [mailto:owner-bc-gnso@icann.org] On Behalf Of Steve DelBianco Sent: Tuesday, March 30, 2010 3:31 PM To: bc-GNSO(a)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 DelBianco Executive Director NetChoice http://www.NetChoice.org and http://blog.netchoice.org +1.202.420.7482

1 0

Another Last Call: BC Position - Baseline Registry Operations Report
by Steve DelBianco 31 Mar '10

31 Mar '10

Another Last Call before closing on a BC comment. Attached is the draft BC position regarding the report on Baseline Registry Operations. Berry Cobb circulated the draft back on 23-Mar (see below). I¹ve signaled my agreement. Absent objections by COB tomorrow, we will file as consensus BC comments on 1-Apr-2010. --Steve On 3/23/10 3:16 AM, "Berry Cobb" <berrycobb(a)infinityportals.com> wrote: BC, Attached is the first draft of the CBUC position statement for the Baseline Registry Operation report released by ICANN. Overall, I feel KPMG performed well and provided meaningful views of the data. It is ashamed that more participants were not a part of the sample data. My Registry operations experience is limited, so I ask the BC team to take a strong look at the report and the initial comments I provided. I especially invite our members that have direct Registry operations experience to enhance our position about this study and its future use by the gTLD Evaluation teams. This material is sure to have a direct impact to the next Draft Applicant Guidebook version 4 to be released just prior to Brussels. In a quick review, the following are what I believe to be sections of the DAGv3 where this study could influence the Application Evaluation Criteria, or the Application Process both of which will be used by the gTLD Evaluation teams. 1.2.2 Required Documents for Application 1.4.2 Application Form 2.1.2 Applicant Reviews 2.1.3 Registry Services Review 2.2.1 Technical/Operational or Financial Extended Evaluation 2.2.2 DNS Stability Extended Evaluation 2.2.3 Registry Services Extended Evaluation The comment period closes April 1st, so I ask for your quick turn-around. As Steve DelBianco eluded to in our last BC call, there are a large number of comment period closings converging at once. I thank you for your quick response. I will compile all feedback and incorporate changes on 3/30/2010. Berry Cobb Infinity Portals LLC San Jose, CA mailto:berrycobb@infinityportals.com http://infinityportals.com <http://infinityportals.com/> 866.921.8891

3 2

Posted: BC comment on RAP Initial Report
by Steve DelBianco 30 Mar '10

30 Mar '10

The BC was one of just 11 stakeholders to post comments on the initial report for Registration Abuse Policies (RAP) Below is the text cover for our comment attachment: > Attached are consensus comments of the Commercial & Business Users > Constituency (CBUC), regarding the initial report of the GNSO Working group > on Registration Abuse Policies. > > The CBUC supports most of the recommendations in the Initial Report, and > offers specific suggestions to guide the policy development process as it > moves to the next stage. We have offered suggestions in several areas > where the CBUC agrees, plus two areas of disagreement with the Initial > Report. > > Several CBUC members contributed to this working group, including Mike > Rodenbaugh, Mike O'Connor, Martin Sutton, Phil Corwin, and Berry Cobb. Our > lead rapporteur for developing these comments was Berry Cobb. BC comments are at http://forum.icann.org/lists/rap-initial-report/msg00010.html All comments at http://forum.icann.org/lists/rap-initial-report/ note: please watch for additional comments pending approval this week. -- Steve DelBianco

1 0

CBUC Position Statement on RAP
by berrycobb＠infinityportals.com 29 Mar '10

29 Mar '10

CBUC, This is the final call for any edits, comments, or disagreements with the positions outlined for the Registration Abuse Policies WG. If there are no objections to the draft as presented here, this will be submitted as a BC Consensus position. We have been granted to COB March 29th to submit the statement. If you have any questions or concerns, please advise. Thank you for your support. FYI, the only change with the attached draft is that I added Phil Corwin as a member of the team. My apologies for omitting his contribution. Berry Cobb Infinity Portals LLC 866.921.8891

5 5

.XXX
by berrycobb＠infinityportals.com 29 Mar '10

29 Mar '10

CBUC, I am reviewing the documents and decision tree for the .XXX public comment period. Forgive my inexperience and lack of history regarding this TLD, but can someone explain to me why the GAC Comments (either past or possible new) are a consideration in the decision tree? Why wouldn't any of the SO get equal opportunity to influence or weigh in on the decision outside of public comment? Thank you for enlightening me. Berry Berry Cobb Infinity Portals LLC 866.921.8891

2 1

RE: [bc-gnso] BC Draft Position on New TLD Registry Agreement Amendments DAG v3
by berrycobb＠infinityportals.com 26 Mar '10

26 Mar '10

Ron, Thank you for supplying us with the BC Position statement for RA Amendments. I support the position statement as outlined, and I have no changes to offer. Within this topic, I am grateful to ICANN for the more uniform approach to Ry Agreements, as opposed to the variance that exists across existing agreements. This should greatly enhance compliance efforts, etc... Equal thanks to Jon for his efforts. Thank you. Berry Cobb Infinity Portals LLC 866.921.8891 Dear Fellow Members, Please find the draft BC position on new TLD Registry Agreement Amendments attached. This draft position is open for discussion/amendment through April 1st, 2010. Thanks to Jon Nevitt for carrying the ball on this one! Kind regards, RA Ronald N. Andruff President RNA Partners, Inc. 220 Fifth Avenue New York, New York 10001 + 1 212 481 2820 ext. 11

4 3

BC Position Statement DRAFT - Baseline Registry Operations Report from KPMG - Action Required by 3/30
by berrycobb＠infinityportals.com 23 Mar '10

23 Mar '10

Sorry, outbound email issues....sending again to be certain, I will be disconnected most of tomorrow. BC, Attached is the first draft of the CBUC position statement for the Baseline Registry Operation report released by ICANN. Overall, I feel KPMG performed well and provided meaningful views of the data. It is ashamed that more participants were not a part of the sample data. My Registry operations experience is limited, so I ask the BC team to take a strong look at the report and the initial comments I provided. I especially invite our members that have direct Registry operations experience to enhance our position about this study and its future use by the gTLD Evaluation teams. This material is sure to have a direct impact to the next Draft Applicant Guidebook version 4 to be released just prior to Brussels. In a quick review, the following are what I believe to be sections of the DAGv3 where this study could influence the Application Evaluation Criteria, or the Application Process both of which will be used by the gTLD Evaluation teams. 1.2.2 Required Documents for Application 1.4.2 Application Form 2.1.2 Applicant Reviews 2.1.3 Registry Services Review 2.2.1 Technical/Operational or Financial Extended Evaluation 2.2.2 DNS Stability Extended Evaluation 2.2.3 Registry Services Extended Evaluation The comment period closes April 1st, so I ask for your quick turn-around. As Steve DelBianco eluded to in our last BC call, there are a large number of comment period closings converging at once. I thank you for your quick response. I will compile all feedback and incorporate changes on 3/30/2010. Berry Cobb Infinity Portals LLC San Jose, CA berrycobb(a)infinityportals.com http://infinityportals.com 866.921.8891

1 0