[Internal-cg] Revised RFP

Drazek, Keith kdrazek at verisign.com
Fri Aug 15 17:09:56 UTC 2014

I agree fully with Milton here.

Keith Drazek

On Aug 15, 2014, at 12:38 PM, "Milton L Mueller" <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:

I’ve reviewed v 0.7 with comments of Martin, Mohamed and Adiel, and am also addressing Russ Mundy’s observations on the RFP.

First, an easy issue: nothing in the language referring to the IANA contract implies that anyone is “bound” by anything. It simply uses the current IANA contract as a uniform point of reference. Let me reproduce the language here:

“In the interest of consistency, each community is encouraged to review and consider the current IANA Functions Contract between NTIA and ICANN when describing existing arrangements and proposing changes to existing arrangements.”

I think that is clearly just asking for a consistent point of reference and we can dispose of this “don’t bind the operational communities” issue completely.

The more difficult issue concerns the leading role of the operational communities and the possibility of multiple submissions. This problem challenges the concept that the ICG is a “non-decisional” body. If we decide who can and cannot submit proposals, we are in fact making a critical substantive decision, one that profoundly influences the nature of the proposals. On the other hand, if we allow or encourage proposals by anyone and everyone who feels like submitting one, we are put into the position of selecting among them and even modifying/reassembling them.

So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected.

I actually think the current draft finds the appropriate middle ground between this Scylla and Charybdis. It strongly encourages everyone to work together in an operational community-led process, but does not expressly prohibit other proposals. Here is the language:

During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups.

Only change I would suggest is that we change “expected” to “required” in the first line.

To Mohamed, I would say that the operational communities HAVE TO be considered the primary stakeholders in the transition, because they are the people who rely on the IANA functions in a direct, operational sense and its functionality and responsiveness  is a life or death matter for them.

From: internal-cg-bounces at icann.org<mailto:internal-cg-bounces at icann.org> [mailto:internal-cg-bounces at icann.org] On Behalf Of Martin Boyle
Sent: Friday, August 15, 2014 11:28 AM
To: Mohamed El Bashir; internal-cg at icann.org<mailto:internal-cg at icann.org> Internal
Subject: Re: [Internal-cg] Revised RFP

Hi All,

Mohamed beat me to it, so I have applied the amendments/comments I was working on on top of his and posted back in dropbox.

I’d like to make a couple of explanatory notes, though:

1.      There seems to be a tendency to widen the number of fronts:  I am concerned that, if we open to all stakeholder communities, we are essentially bypassing the focus on the three functions as centres of thinking.  The more I have thought about this, the more I see little value for any community NOT to submit its own proposal(s) whereas we really need the different groups to work with all affected stakeholders on their bit of the puzzle.  I thought (really believed) that were working on the operational lead approach expecting each to adopt its own process with its affected parties and other stakeholders.  I hope that we can keep to this approach.

2.      I’ve noted in a previous mail on this document that there are a number of ccTLDs who do not (and will not) engage with ICANN.  I’m happy for us not to encourage individual or small-group submissions, but we have to understand that there is a high probability that we will get input, so there is no point in trying to discourage them.  But we do need to think about how this might be dealt with and pose our questions to the wider community in a different form.  One way might be to offer a “fast track” approach to identify specific problems or requirements that they feel need to be addressed.

3.      I was left puzzled by references to an input from Daniel which I was not able to find.  I have commented on this paragraph somewhat in the dark (apologies if I’ve missed the point), but it does seem to me to be important for us to use the current NTIA/ICANN as the current basis.  This is then reflected in a couple of comments in the last section, on maintaining the framework for service delivery and on the clear separation of policy responsibility from the IANA.

By the way, is it v0.7 (as in the file title) or v0.6 (as in the document)?



Internal-cg mailing list
Internal-cg at icann.org<mailto:Internal-cg at icann.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140815/79c8d2c3/attachment.html>

More information about the Internal-cg mailing list