<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
NO worries.<div><br></div><div>Barry, a couple of thoughts. </div><div><br></div><div>first, I seem to have been more confused than illuminating. </div><div><br></div><div>The point I was trying to make is that actually the cc's that 'mirror' gTLDs are <b>not</b> the best to analyze. those are small cc's and are 'atypical', often operated by a party not sanctioned by the local government, and in some cases, affiliated with a gTLD registry as a back engine. a random group of cc's makes sense, but also, others that should be analyzed are those that have over 100,000 in registration, a sampling again at 500,000, and again at over 1 million in registrations, such as de; .uk' .ca, etc. </div><div><br></div><div>I only mentioned that business users register in many cc's for business reasons to note that our members have a keen interest in the cc's, not just in gTLDs. :-) sorry to confuse the issues.</div><div><br></div><div><br>> - Discussion Point 1 - I will be happy to include what is needed here. <br>> However, I am confused by the reasoning supplied. It only mentions <br>> why people may register domains in a ccTLD and not in reference to <br>> comparing an operating model from a ccTLD with other TLDs. I <br>> understand the operating models to be drastically different both <br>> technically and in business operations. I have very little experience <br>> here....so I am wide open for suggested language for the "Survey <br>> Demographics."<br>> </div><div>Comments on this point: I am amazed that ICANN considers it 'acceptable' to outsource compliance, and actually don't even understand how that works. I ran a health care business for a global corporation and believe me, I didn't outsource that!, even though we were a small business. To hear that small registries </div><div>outsource their compliance with ICANN registry requirements is quite .... startling and dismaying. I appreciate your calling this to my attention and to other BC members. Outsourcing is actually expensive, for a small enterprise. IF one actually defines the unique needs of the small enterprise. I am not confident that there are well experienced parties 'on every block' that can deal with compliance with ICANN registry requirements, thus, this doesn't actually make financial sense to me. </div><div><br></div><div>The BC should not support outsourcing of key compliance requirements. Thus, the study that suggests that small registries are outsourcing compliance may need to be questioned in the following way: before accepting outsourcing of compliance with ICANN requirements, a thorough analysis will be needed to determine whether this results in acceptable compliance, adds costs to ICANN to try to determine effective compliance, or disadvantages registrants in measureable ways. </div><div><br></div><div><br>> - Discussion Point 2 - Outsourcing of Compliance. The study reveals <br>> that small Registries outsource their compliance. It does not suggest <br>> that ICANN outsource its compliance. Therefore, I think the last <br>> bullet with "Survey Demographics" in our position statement stands as <br>> is. ICANN should take a close look as this to ensure it is done <br>> correctly. I do not oppose outsourcing it, but doing so does increase <br>> risk and ICANN should have a pulse as to WHEN and HOW.<br>> <br>> Thank you for the feedback again. Please advise of any other changes.<br>> <br>> B<br>> <br>> Berry Cobb<br>> infinity Portals LLC<br>> 866.921.8891<br>> <br>> <br>> <br>> Quoting Marilyn Cade <marilynscade@hotmail.com>:<br>> <br>> ><br>> ><br>> > Barry, Steve,<br>> > Thanks Barry, for your work on this. I have a couple of <br>> > suggestions, and point out a couple of editorial changes that you <br>> > will want to make. I provide several suggestions ,and put into bold <br>> > some of the key words/and new proposed language to try to make this <br>> > easier to understand and follow.<br>> > Overall great job. A few critical changes proposed.<br>> > For the longer term, I know that there are other discussions to be <br>> > had about a 'template' or 'templates' for BC policy positions and, <br>> > I do hope that you will play a leadership role in that process.<br>> > On the substance of this comment, I would suggest that you change <br>> > the legend on some of the elements to !. For instance, although the <br>> > category: "Reserves" says no comment, actually the BC does have a <br>> > comment. Capital Expenditures: says no comments, but does offer a <br>> > very important comment. Continuity Planning, legend says no comment, <br>> > but we do have a comment. I'd just suggest changing the legend to <br>> > "!", and editing out the /NO comment on those issues.<br>> > Finally, I wanted to call your attention and others to the need to <br>> > have a category that is 'brands related gTLD registry'. Youcould <br>> > add a footnote to 'registry population', noting that there may be a <br>> > category of registries that are operated by a brand holder, for <br>> > their subscribers, or employees, and that this category is not <br>> > addressed, to date, in ICANN's work.<br>> ><br>> ><br>> > In the Survey Demographics section. The first bullet point needs to <br>> > have an edit in the last reference to the ccTLDs. it should read <br>> > "..... under different contractual obligations to ICANN than ccTLDs. <br>> > I think you mean ... "than gTLDs".<br>> > Discussion Point: I spent a good deal of time studying ccTLDs when <br>> > I was chairing the first WHOIS Task Force. The working methods of <br>> > the cc's are indeed a good barometer for learning. Sometimes this is <br>> > not well understood by business users who primarily register in <br>> > cc's defensively. And, there are other factors that limit the <br>> > exposure of business users to the ccTLD managers -- e.g. while we <br>> > once held dialogues with the cc's that has gone by the wayside and <br>> > the primary focus is on the gTLDs. And, then the reality is that <br>> > the gTLDs registries often believe that they are the 'rightful <br>> > choice' for back engines for future gTLDs and even for ccTLDs. As <br>> > BC, we need to agnostic about business preferences. Business uses <br>> > can register in either gTLDs or ccTLDs and need to have a broadened <br>> > understanding of the role and activities of the ccTLDs for many <br>> > reasons. I'd propose that we soften the comments about the cc's.<br>> > For instance, I disagree with the proposal that the review of cc's <br>> > be limited to those ccTLDs that mimic gTLDs -- I do not agree. That <br>> > would eliminate .de; .uk, and .ca, and .cn, for example, all of <br>> > which are large and complex ccTLDS, often more complex and <br>> > technically sophisticated than many of the smaller gTLDs. A few <br>> > cc's are marketed as 'global' TLDs, and that has disconcerted, or <br>> > annoyed some gTLD registries. That is a perspective of gTLD <br>> > registries that may not not actually serve the broader global <br>> > business user communities' interest. For instance, if you are a <br>> > small Kenyan business, you may both prefer to register in .ky and <br>> > find advantage in doing so. You may also want to register in a gTLD <br>> > as well, however. Global business users are registering in ccTLDs in <br>> > many cases to have identity in the country they are doing business <br>> > in. Understanding cc's practices is a 'good thing'.<br>> > I'd prefer to strike the statement "Perhaps ccTLDs that mimic a gTLD <br>> > should be chosen'. Instead, I'd propose that the BC statement <br>> > read: The CBUC supports the inclusion of ccTLDs in this study and <br>> > is interested in ensuring that the sample is fully representative <br>> > of different practices and models, including analyzing different <br>> > 'sizes" of cc TLD registries.<br>> > In your bullet about slide 4, the language seems to need some editing.<br>> > Finally, I do not support ICANN's outsourcing of compliance, and I <br>> > suggest that the BC should not support that. The present position <br>> > offered could be strengthened by changing the statement to proposed <br>> > new statement:<br>> > "Enforcement and compliance should remain a primary function of <br>> > ICANN itself. Outsourcing of such functions may create <br>> > vulnerabilities for ICANN to fulfull its core responsibilities and <br>> > any proposed outsourcing should be carefully studied, and the <br>> > subject of further public comment before proceeding with any such <br>> > initiatives. ICANN may be proposing an initial cost savings approach <br>> > that will ultimately harm the registrants and limit ICANN's ability <br>> > to fulfill its core responsibilities. "<br>> > Technical and Network Architecture: This BC statement could use the <br>> > same footnore reference mentioned above regarding brands registries.<br>> ><br>> ><br>> ><br>> ><br>> >> Date: Tue, 30 Mar 2010 18:57:58 -0400<br>> >> Subject: [bc-gnso] Another Last Call: BC Position - Baseline <br>> >> Registry Operations Report<br>> >> From: sdelbianco@netchoice.org<br>> >> To: bc-GNSO@icann.org<br>> >><br>> >> Another Last Call before closing on a BC comment.<br>> >><br>> >> Attached is the draft BC position regarding the report on Baseline Registry<br>> >> Operations.<br>> >><br>> >> Berry Cobb circulated the draft back on 23-Mar (see below). Išve signaled<br>> >> my agreement.<br>> >><br>> >> Absent objections by COB tomorrow, we will file as consensus BC comments on<br>> >> 1-Apr-2010.<br>> >><br>> >> --Steve<br>> >><br>> >> On 3/23/10 3:16 AM, "Berry Cobb" <berrycobb@infinityportals.com> wrote:<br>> >><br>> >> BC,<br>> >><br>> >> Attached is the first draft of the CBUC position statement for the Baseline<br>> >> Registry Operation report released by ICANN. Overall, I feel KPMG performed<br>> >> well and provided meaningful views of the data. It is ashamed that more<br>> >> participants were not a part of the sample data.<br>> >><br>> >> My Registry operations experience is limited, so I ask the BC team to take a<br>> >> strong look at the report and the initial comments I provided. I especially<br>> >> invite our members that have direct Registry operations experience<br>> >> to enhance our position about this study and its future use by the gTLD<br>> >> Evaluation teams.<br>> >><br>> >> This material is sure to have a direct impact to the next Draft Applicant<br>> >> Guidebook version 4 to be released just prior to Brussels. In a<br>> >> quick review, the following are what I believe to be sections of the DAGv3<br>> >> where this study could influence the Application Evaluation Criteria, or<br>> >> the Application Process both of which will be used by the gTLD Evaluation<br>> >> teams.<br>> >><br>> >> 1.2.2 Required Documents for Application<br>> >> 1.4.2 Application Form<br>> >> 2.1.2 Applicant Reviews<br>> >> 2.1.3 Registry Services Review<br>> >> 2.2.1 Technical/Operational or Financial Extended Evaluation<br>> >> 2.2.2 DNS Stability Extended Evaluation<br>> >> 2.2.3 Registry Services Extended Evaluation<br>> >><br>> >> The comment period closes April 1st, so I ask for your quick<br>> >> turn-around. As Steve DelBianco eluded to in our last BC call, there are a<br>> >> large number of comment period closings converging at once. I thank you for<br>> >> your quick response. I will compile all feedback and incorporate changes on<br>> >> 3/30/2010.<br>> >><br>> >><br>> >> Berry Cobb<br>> >> Infinity Portals LLC<br>> >> San Jose, CA<br>> >> mailto:berrycobb@infinityportals.com<br>> >> http://infinityportals.com <http://infinityportals.com/><br>> >> 866.921.8891<br>> >><br>> >><br>> ><br>> ><br>> ><br>> ><br>> <br>> <br></div> </body>
</html>