ICANN ICANN Email List Archives

[bc-gnso]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • 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)
  • From: <icann@xxxxxxxxxxxxxx>
  • Date: Thu, 8 Dec 2011 21:42:01 -0800

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> 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
<http://gnso.icann.org/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm>  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
<https://www.icann.org/en/public-comment/rysg-proposal-cof-17oct11-en.htm> .


 

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



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy