URGENT: RE: [bc-gnso] for discussion on 9-Dec call: draft BC comment on registry proposal for Continuity Operations Instrument (COI)

[Marilyn Cade <marilynscade@xxxxxxxxxxx>]

just noting that aI just sent a notice to list that having a small ICANN conf. 
bridge delay. please give Bene a fw min to resolve. will try to start call at 
10 after/but may have a diff bridge from ICANN if they can't fix this 
problem.with apologies for delay. 
M


From: psc@xxxxxxxxxxx
To: mike@xxxxxxxxxxxxxx; sdelbianco@xxxxxxxxxxxxx; bc-gnso@xxxxxxxxx
Subject: RE: [bc-gnso] for discussion on 9-Dec call: draft BC comment on 
registry proposal for Continuity Operations Instrument (COI)
Date: Fri, 9 Dec 2011 14:56:13 +0000











Reaching back to 2007 GNSO  Principles seems to me of little relevance to the 
present discussion. That was a year before the Board approved going forward 
with new gTLDs, and also before three succeeding years
 of multiple drafts of the Applicant Guidebook were considered and amended 
before the Final version was approved in Singapore. The Principles have long 
been supplanted by the requirements of the Guidebook.
 
There will surely be other instances where deciding what is an implementation 
detail and what is substantive will be debatable. But in this case I think it’s 
pretty clear – COI is in the Guidebook, and COF is
 not a proposal for how best to implement COI but an entirely new and 
substitute approach for registrant protection in the event of registry failure 
(that in turn raises a host of other new issues related to a pooled insurance 
fund rather than individual registry
 letters of credit). 
 
I think it is clearly substantive, and that in turn raises the issue of whether 
and when we believe individual constituencies should be allowed to reopen 
substantive debate an Guidebook issues that appeared to
 be settled. 
 

Philip S. Corwin, Founding Principal
Virtualaw LLC
1155 F Street, NW
Suite 1050
Washington, DC 20004
202-559-8597/Direct
202-559-8750/Fax
202-255-6172/cell
 
"Luck is the residue of design" -- Branch Rickey

 


From: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx]
On Behalf Of icann@xxxxxxxxxxxxxx

Sent: Friday, December 09, 2011 12:42 AM

To: 'Steve DelBianco'; 'Bc GNSO list '

Subject: RE: [bc-gnso] for discussion on 9-Dec call: draft BC comment on 
registry proposal for Continuity Operations Instrument (COI)


 
Yes.  But as Phil says, the COI requirement was approved by the Board as part 
of the Guidebook, so presumably would take Board action to amend.  Certainly 
would take Board action to adopt COF.  I had thought
 there was going to be a Board meeting today with that on the agenda.  Does 
anyone know if it happened and whether this was discussed?
 

Mike Rodenbaugh
RODENBAUGH LAW
tel/fax: +1.415.738.8087
http://rodenbaugh.com


 


From:
owner-bc-gnso@xxxxxxxxx 
[mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of Steve DelBianco

Sent: Thursday, December 08, 2011 7:50 PM

To: 'Bc GNSO list '

Subject: Re: [bc-gnso] for discussion on 9-Dec call: draft BC comment on 
registry proposal for Continuity Operations Instrument (COI)


 



Good point, Mike.   In the 2007 
Principles I found these two relevant items:



 



A set of capability criteria for a new gTLD registry applicant must be used to 
provide an assurance that an applicant has the capability to meets its 
obligations under the terms of ICANN’s registry agreement.





 


Applicants must be able to demonstrate their financial and organisational 
operational capability.


 



If that's all GNSO said about it, wouldn't we conclude that the Continuity of 
Operations instrument is an implementation detail?


 


--Steve




 


 


From:
Mike Rodenbaugh <icann@xxxxxxxxxxxxxx>

Organization: Rodenbaugh Law

Reply-To: <mike@xxxxxxxxxxxxxx>

Date: Thu, 8 Dec 2011 19:13:57 -0800

To: Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>, 'Bc GNSO list ' 
<bc-gnso@xxxxxxxxx>

Subject: RE: [bc-gnso] for discussion on 9-Dec call: draft BC comment on 
registry proposal for Continuity Operations Instrument (COI)


 



Thanks Steve.  How does the COF tie back to the original principles that were 
agreed by the Council and the Board by supermajority?  If not specifically 
required in those principles, then by definition it is
 an implementation detail… albeit a big one.
 
 


From:
owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx]
On Behalf Of Steve DelBianco

Sent: Thursday, December 08, 2011 6:35 PM

To: 'Bc GNSO list '

Subject: [bc-gnso] for discussion on 9-Dec call: draft BC comment on registry 
proposal for Continuity Operations Instrument (COI)


 



On 3-Dec I circulated Draft 2 of the BC comment on the registries' proposal for 
a Continuity of Operations Fund. 


 


This week, Sarah Deutsch offered some clarifying edits.  In his note (below) 
Phil Corwin argues against describing the COF as an implementation detail (see 
Phil's argument below).   I believe Phil's requested change
 merits a brief discussion during tomorrow's BC member call.   (see Draft 3 
attached)


 


These comments were due one week ago so let's try to close this topic tomorrow.


 


--Steve


 



 





 


From:
Phil Corwin <psc@xxxxxxxxxxx>

Date: Mon, 5 Dec 2011 17:22:33 +0000

To: Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>, 'Bc GNSO list ' 
<bc-gnso@xxxxxxxxx>

Subject: RE: for expedited review: draft BC comment on registry proposal for 
Continuity Operations Instrument (COI)


 



Steve:
 
I believe that this document is much improved and have no objection to it.
 
In particular, I appreciate the fact that the document no longer states that 
the BC plans to file a letter advocating additional changes to the new gTLD 
program’s trademark protection requirements – a subject
 that will first be discussed among BC members in the upcoming conference call 
scheduled for Friday, December 9.
 
However, I would like to propose that the comment be strengthened. In that 
regard, I would propose that the sentence in point #2 that presently reads “We
are not supportive of the approach presented by the Registry Constituency. “ 
should be altered to state “We
oppose the approach presented by the Registry Constituency”.
 
I am also concerned by the last sentence in the first paragraph of the 
background section – “The BC notes this new approach to considering potential 
improvements in
implementation details for the new gTLD Program and provides comments on this 
topic.” This seems to concede that the Registry Constituency’s COF proposal is 
a mere implementation detail when, in fact, I believe it would be a significant 
substantive change
 in the new gTLD program that goes far beyond an implementation detail. The 
Registry Constituency was well aware of the COI requirement before the Board 
approved the new gTLD program in Singapore, and if registries had significant 
concerns with it they should
 gave raised them before the Board vote rather than urging a “yes” vote on the 
AG then before the Board. I would propose that the sentence be changed to 
reflect a BC position that COF is far more than an implementation detail and is 
not properly on the table
 at all.
 
As previously stated, I have significant doubts about ICANN’s ability to 
effectively implement a COF approach because other industry-wide shared risk 
insurance pools --  such as, in the U.S., the FCIC, SIPC,
 and state insurance funds – require a supportive structure of pervasive 
regulation to ameliorate the moral hazard that inevitably arises when an 
industry participant can shift the consequences of its risk-taking to others. I 
do not believe it would be proper
 for ICANN to assume such a role – nor am I confident it could successfully 
undertake it, given continuing concerns regarding its ability to effectively 
enforce its bilateral contracts with registries. Also, as the BC statement 
notes, a COI offers substantially
 greater prospects for registrant protection in the event of a registry failure.
 
But the issue is much larger than whether the COF proposal has merit. The issue 
is whether it is properly on the table at all
– the issue, in fact, is what should be the proper means going forward to 
consider significant substantive changes in the new gTLD program (as distinct 
from addressing implementation details of the current requirements reflected in 
the Applicant Guidebook
 and standard registry contract).
 
Here’s my problem – we constantly refer to and support ICANN’s 
multi-stakeholder policy-making process – but the word “process” implies a 
standard undertaking with a beginning, middle, and end, at the end of
 which things are settled for at least some reasonable amount of time. If ICANN 
had never been spun out of the Commerce Department it would be a government 
agency and its rulemaking process would be under the Administrative Procedures 
Act. The APA provides
 a well-understood process – there is an advance notice of proposed rulemaking 
which solicits initial comments, then there is promulgation of a proposed rule 
which solicits further comments, then there may even be one or two more 
publications of an altered
 rule reflecting the comments received (and along the way there may have been 
one or more public hearings to solicit oral input) – but in the end there is a 
Final Rule and it is really final, and the grounds for judicial challenge of 
that Rule are well understood
 and quite narrow. Now it may be proper for the ICANN process to be more 
flexible than that – but in the end it should produce a result with a 
reasonable degree of finality.
 
We all have concerns about various aspects of the final Applicant Guidebook, 
even though the process of developing it took three years and at various points 
had a make-it-up-as-you-go-along procedural quality
 . But if any constituency can propose major changes to the AG just months 
after its adoption by the Board – and COF, again, appears to be a major 
substantive departure from COI, not a mere implementation detail – then the 
ICANN process is never final at all,
 nothing is ever settled for even a brief interval. That is really no process 
at all because it provides no reliable finality.  And that in turn, in my 
opinion, raises further questions about ICANN’s overall credibility as an 
organization.

 
There’s also a need to move on from the new gTLD program (aside from monitoring 
its launch and fleshing out details of its implementation) and engage on to the 
many other substantive issues challenging ICANN.
 If the Registries can advocate COF, and if any other Constituency can also 
propose major substantive changes in the program, then we are going to be back 
into the same disputes that were the focus of discussion of three years and 
that will be a major distraction
 from other pressing issues. Each of us has only so much personal bandwidth to 
devote to ICANN policy matters.
 
To make clear, I have no problem with further refining the COI, such as 
considering lower financial commitments based on registry type or experience, 
as these seem to be legitimate implementation details.
 
Summing up, I propose that:
·        
The BC change its position on COF from “Not supportive of” to “opposes”.
·        
The BC take the position that COF is a significant AG substantive change and 
proposed replacement for COI, and therefore not an implementation detail of COI.
·        
The BC engage in a constituency discussion of when and under what procedures 
significant substantive changes in the new gTLD program – as opposed to mere 
implementation of the program as approved by
 the Board – can properly be put on the table for consideration, as well as 
what the process and standard should be for considering and incorporating them.
 
Regards to all,
Philip
 
 
 


From:
owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx]
On Behalf Of Steve DelBianco

Sent: Saturday, December 03, 2011 5:29 PM

To: 'Bc GNSO list '

Subject: [bc-gnso] Re: for expedited review: draft BC comment on registry 
proposal for Continuity Operations Instrument (COI)


 



Rapporteur Jon Nevett incorporated Marilyn's edits into the attached DRAFT 2.  
I also adjusted the opening section to address a concern expressed by Phil 
Corwin today:




The BC notes this new approach to considering potential improvements in 
implementation details for the new gTLD Program
 and provides comments on this topic.
 


Also attached is a redline comparing draft 1 and 2. 



 


If any BC member objects to the BC filing this Draft 2 comment , please REPLY 
ALL and explain your objections.   If any member objections are noted by 
midnight
 UTC on 7-Dec, we will ask the membership to vote on the comments.


 


If no objections are noted, we will post the attached draft to ICANN on 9-Dec.


   



Thanks to Marilyn and Jon for their work on these comments. 


 


 


From:
Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>

Date: Fri, 2 Dec 2011 22:43:19 -0500

To: 'Bc GNSO list ' <bc-gnso@xxxxxxxxx>

Subject: FW: for expedited review: draft BC comment on registry proposal for 
Continuity Operations Instrument (COI)


 










Last night, Marilyn Cade submitted extensive edits to our draft comments on the 
Continuity of Operations Fund proposal from the Registries.   See second 
attachment and
 Marilyn's summary of her comments below.


 


Per the plan I sent this week, we will now allow 7 additional days of review 
time, with a target date to submit by next Friday 9-Dec.   That would make us 
just one week
 late for ICANN's comment deadline.


 


Rapporteur Jon Nevett will take first look at Marilyn's edits and will 
circulate a new version over the weekend.


 



From: marilynscade@xxxxxxxxxxx

To: bcprivate@xxxxxxxxx

Subject: IMPORTANT: SEE PROPOSED CHANGES/EDITS IN THE BC DRAFT: for expedited 
review: draft BC comment on registry proposal for Continuity Operations 
Instrument (COI)

Date: Thu, 1 Dec 2011 10:49:10 -0500




 
I propose several changes  and an enhancement about why the BC cares about this 
topic, and also note that we would like similar opportunity to achieve changes 
in the
 new gTLD program -- regarding IPR protections. I will send a separate email 
about that topic, based on discussions with Steve, Sarah, and others about the 
existing call for improvements in that area. [Separate email]. My comments are 
as an individual member
 of the BC on this BC position statement. 
 
The changes I propose to this draft are consistent with BC's positions 
regarding priority of protecting registrants and users. 
 
See 2, where I added ICANN's responsibiilty to act in the public interest.
3. I explicitly stated that we do not support the Regy proposal. That was 
missing from our statement. 
I also said that improvements could be made in the COI. See 4.
5. I also added in that the BC fears a high risk of failure of some of the new 
gTLDs. 
6. I added that we expect there to be appropriate legal agreements in the 
contracts that would allow for the protection of registered names. 
 
I deleted the old 7, which seemed to say on the one hand, and then on the other 
hand. The purpose of this statement is to either support the Registry proposal, 
or
 oppose it. I oppose it, for the reasons I noted in my edits. I do think that 
COI can be improved, especially as it regards 'brands' gTLDs. 
 
I was also concerned in reading the transcript of the actual panel in Dakar -- 
I was not able to attend in person -- the panel looked heavily stacked toward 
supporters
 of the new gTLD program.  However, the important news may be that if ICANN 
will accept suggested changes form a single constituency, we should be 
aggressively be addressing our call for changes in Trademark protection. 
 
Marilyn Cade



 


 







 





 


From:
Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>

Date: Wed, 30 Nov 2011 18:29:48 -0500

To: 'Bc GNSO list ' <bc-gnso@xxxxxxxxx>

Subject: FW: for expedited review: draft BC comment on registry proposal for 
Continuity Operations Instrument (COI)


 






Thanks to all for engaging in the email discussion over these comments.


 


However, I don't think we've seen any specific edits on the draft circulated 
last Tuesday 22-Nov.  


 


Ron and Phil proposed a more extensive critique of the Guidebook's COI plan, 
but the scope of this comment is reacting to the Registry proposal for an 
alternative mechanism
 (COF).  I would strongly suggest that Ron and Phil individually submit their 
concerns to ICANN, of course.


 


Mike Palage advised us to be careful about conflicts of interest, so I propose 
a simple way to do this quickly and transparently:


 



If any BC member
objects to the BC filing the attached draft comment , please REPLY ALL and 
indicate your objection and reason.   If any member objections are noted by 
midnight UTC on 1-Dec, we will extend the process and ask the membership to 
vote on alternate versions
 of BC comments.   This would mean our comments are submitted late, but might 
still be considered.


 


If no objections are noted we will post the attached draft to ICANN on the 
closing date of 2-Dec.


   



Thanks again for engaging in this discussion.


 


--Steve 


(vice chair for policy coordination)


 


 




From:
Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>

Date: Tue, 22 Nov 2011 19:04:17 -0500

To: "'bc-GNSO@xxxxxxxxx GNSO list'" <bc-gnso@xxxxxxxxx>

Subject: for expedited review: draft BC comment on registry proposal for 
Continuity Operations Instrument (COI)


 







Per discussion in Dakar and on our 10-Nov member call, here is a draft of BC 
comments on the a proposed
 alternative to the for Continuity Operations Instrument in the new gTLD 
Program.


 


Jon Nevett prepared this draft. 


 




This comment period and docs are described

here. 


 


These comments are due 2-Dec, giving us 10 days for review and approval.   This 
is less than the 14-day period required in our charter,
 so I am requesting an expedited review period.  If any member has substantive 
objections to the expedited review, we can go to 14 days and submit our 
comments after the ICANN due date.


 


All BC members are invited to suggest edits.     Please use track changes and 
circulate to BC list.   


 



Thanks again to Jon for taking the lead on this.


 


 


Steve DelBianco


vice chair for policy coordination, BC
















No virus found in this message.

Checked by AVG - www.avg.com

Version: 10.0.1411 / Virus Database: 2102/4055 - Release Date: 12/03/11








No virus found in this message.

Checked by AVG - www.avg.com

Version: 10.0.1415 / Virus Database: 2102/4067 - Release Date: 12/08/11