RE: [bc-gnso] Comments from Marilyn Cade: Another Last Call: BC Position - Baseline Registry Operations Report

[Marilyn Cade <marilynscade@xxxxxxxxxxx>]

NO  worries.
Barry, a couple of thoughts. 
first, I seem to have been more confused than illuminating. 
The point I was trying to make is that actually the cc's that 'mirror' gTLDs 
are not 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. 
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.

> - Discussion Point 1 - I will be happy to include what is needed here.  
>   However, I am confused by the reasoning supplied.  It only mentions  
> why people may register domains in a ccTLD and not in reference to  
> comparing an operating model from a ccTLD with other TLDs.  I  
> understand the operating models to be drastically different both  
> technically and in business operations.  I have very little experience  
> here....so I am wide open for suggested language for the "Survey  
> Demographics."
> 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 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. 
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. 

> - Discussion Point 2 - Outsourcing of Compliance.  The study reveals  
> that small Registries outsource their compliance.  It does not suggest  
> that ICANN outsource its compliance.  Therefore, I think the last  
> bullet with "Survey Demographics" in our position statement stands as  
> is.  ICANN should take a close look as this to ensure it is done  
> correctly.  I do not oppose outsourcing it, but doing so does increase  
> risk and ICANN should have a pulse as to WHEN and HOW.
> 
> Thank you for the feedback again.  Please advise of any other changes.
> 
> B
> 
> Berry Cobb
> infinity Portals LLC
> 866.921.8891
> 
> 
> 
> Quoting Marilyn Cade <marilynscade@xxxxxxxxxxx>:
> 
> >
> >
> > 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@xxxxxxxxxxxxx
> >> To: bc-GNSO@xxxxxxxxx
> >>
> >> 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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> >> http://infinityportals.com <http://infinityportals.com/>
> >> 866.921.8891
> >>
> >>
> >
> >
> >
> >
> 
>