[Internal-cg] FW: Further RFP revision

Alissa Cooper alissa at cooperw.in
Fri Aug 22 21:43:42 UTC 2014

Milton, all,

Attached is a v12 that tries to clarify further what the ICG is requesting
and how comments can be provided (Dropbox seems to be having an outage, I
will upload later). I also carried forward some of Manal’s edits and
edited Section IV based on Narelle’s email.

There is one issue that Joe has raised that I don’t think needs to be
explained in the RFP document itself but that we do need to decide about,
which is whether we will solicit public comments about the contents of the
RFP. Here is my assessment of that question:

On the one hand, I feel like we have some independent authority here. If
we ask for comments on the RFP and get comments back that say “half of the
things you’re asking for are unnecessary,” I don’t think we should
necessarily take them out. We were selected to deliver something credible
to NTIA and I think it’s our decision as to what parts add up to

On the other hand, someone might point out things that we missed. Of
course any of the communities could and should provide additional
information they think is appropriate in their proposal components — it’s
not like we’re going to ignore some section of a proposal document we
receive because we didn’t explicitly ask for it. We already ask for as
much explanatory material as they want to give. So I’m not sure those
kinds of comments will add a lot of value either.

Personally, I’m in a situation where I’m receiving pointed emails from
IETF folks who are wondering why the RFP hasn’t been published yet so they
can align their work with the RFP. So I’m sensitive to getting something
out the door ASAP. And I do not think people will be pleased if we publish
the RFP on, say, next Thursday with a 1-week comment period that overlaps
almost entirely with people’s travel to and participation in the IGF.

So my opinion is that a specific public comment period on the contents of
the RFP is not strictly necessary. But, if others think it is, perhaps we
could publish the draft next week and circulate it to the communities,
with the caveat that people can send comments about the RFP content itself
to icg-forum at icann.org with a deadline in the second week of September,
and we may choose to update the RFP based on those comments after that. I
think the former is preferable though.


On 8/22/14, 1:07 PM, "Milton L Mueller" <mueller at syr.edu> wrote:

>Here I think we need to distinguish between actual proposals, which the
>RFP solicits and attempts to structure, and public comments on the
>proposal(s) that
> we put together. 
>E.g., when you talk about a group addressing “a specific issue of
>interest such as accountability”, it sounds to me like you are talking
>about people reacting
> to specific proposals that have actually been made. In that case, they
>can review the proposals and assess the adequacy with which they address,
>say, the accountability issue, and submit comments during the public
>comment period accordingly.
>What I fear is that your current language will encourage groups to
>inundate the ICG with comments like “We think accountability is important
>and ICANN needs
> more of it” BEFORE any proposals have actually been made – as if WE were
>the ones developing the proposal. We cannot do anything with such
>comments. Either people concoct and propose specific institutional, legal
>and operational changes that enhance accountability
> (in which case they are helping to develop a proposal) or they are just
>expressing opinions, which is only helpful to us if these opinions are
>about specific proposals that we have before us.
>Do you understand my concern here?
>From: internal-cg-bounces at icann.org [mailto:internal-cg-bounces at icann.org]
>On Behalf Of joseph alhadeff
>Sent: Friday, August 22, 2014 3:41 PM
>To: internal-cg at icann.org
>Subject: Re: [Internal-cg] FW: Further RFP revision
>I have been a strong proponent of making sure that proposals are
>developed only in the communities, but I am not convinced that those
>processes will necessarily be accessible beyond the normal members of and
>participants to that community.  If there is a specific
> issue of interest, such as accountability, and there is a specific
>opinion on that I think we need to be open to those comments.  We can try
>to make the timing of more general stakeholder comments coincide with the
>publication of the proposal for comments,
> but we need a section that better addresses how we are open to comments
>outside of the drafting communities and how and when they can participate
>in our process.
>On 8/22/2014 3:19 PM, Alissa Cooper wrote:
>Forwarding on behalf of Milton who is having list email issues ... On
>8/22/14, 11:25 AM, "Milton L Mueller" <mueller at syr.edu>
><mailto:mueller at syr.edu> wrote:  -----Original Message-----From: Milton L
>MuellerSent: Friday, August 22, 2014 11:04 AMTo: 'Alissa Cooper';
>internal-cg at icann.orgSubject: RE: [Internal-cg] Further RFP revision
>Alas, there are still some unresolved issues here. I still have to insist
>that the first and second paragraphs containlanguage that cover the same
>topic, but provide different meanings andthus open to door to conflicting
>interpretations that could cause ustrouble. We need to choose one or the
>other of the meanings and deletethe other.  Here is an exegesis:
>>From the middle of paragraph 1: "Other parties may provide comments to
>>the ICG on particular aspects thatmay be covered by proposals that may
>>be of significant interest to them,for review by the ICG as time and
>>resources permit. The ICG will directcomments received from other
>>parties to the relevant operationalcommunities as appropriate."
>>Paragraph 2:  "During the development of their proposals, the
>>operational communitiesare expected to consult and work with other
>>affected parties; likewise,other affected parties are strongly
>>encouraged to participate incommunity processes, as the ICG is requiring
>>proposals that haveconsensus support from a broad range of stakeholder
>>groups." My view is that the material from paragraph 1 must be deleted
>>so as tonot confuse people and undermine the message in paragraph 2. As
>>it is written now, the material in paragraph 1 invites parties toprovide
>>"comments" to us on "proposals" (note the _plural_ form) that arebeing
>>considered by the operational communities. To me, this seems toinvite
>>people to provide ongoing commentary on the ideas being consideredby the
>>operational communities as they develop a proposal or
>>consideralternatives. That is not what we want. We want finished,
>>agreedproposals.  Paragraph 2 is much clearer about what we want. It
>>"strongly encourages"affected parties to participate in the operational
>>community process forthe same of "consensus support from a broad range
>>of...groups," but itdoes not completely close the door to the receipt of
>>finished alternativeproposals where consensus is not possible. I really
>>think that section of paragraph 1 and paragraph 2 arearticulating
>>separate models of response and we cannot allow the RFP tobe released
>>with such a critical ambiguity in it. I also made a few minor changes,
>>related to labeling IIA as Policy sourceand the second bullet point
>>under IIB I also responded to Martin's comments about his nervousness.
>>My point isthat various proposals might come up with different ways of
>>excluding orseparating policy from IANA implementation. Since we can’t
>>use theexisting method (NTIA contract) to do so, this section is simply
>>askingthem to explain the implications of their changes for existing
>>policyarrangements. However, we may be able to finesse this issue,
>>because itsays almost the same thing as bullet point 2 in section II B.
>>So do weneed it at all? Finally, a word about "testing." I don't know
>>what kind of a paralleluniverse the rest of you live in, but in the
>>world I have become familiarwith as a social scientist, there is no
>>"testing" of legal andinstitutional accountability arrangements. We can
>>project or estimatebased on past experience, but that is all. If there
>>are technical andoperational changes called for by a proposal, yes, we
>>can talk aboutpre-testing them in some kind of laboratory set up. But
>>asking people to"test" what will happen if the NTIA is not there and
>>some otheraccountability mechanism is, is asking for the impossible. So
>>I havealtered the language to deal with this.   -----Original
>>internal-cg-bounces at icann.org[mailto:internal-cg-bounces at icann.org]On
>>Behalf Of Alissa CooperSent: Thursday, August 21, 2014 8:40 PMTo: joseph
>>alhadeff; internal-cg at icann.orgSubject: Re: [Internal-cg] Further RFP
>>revision I took one more stab at this — v10 attached and uploaded. There
>>was some new text in v09(jha) about how people should feel freeto
>>comment to us about transparency, completeness, etc. I think thatis true
>>as a general matter, but that is not what we are asking forspecifically
>>in this RFP.That is what we will ask for — from anyone who cares to
>>answer — afterwe have the proposal components submitted (by December
>>:)).So I removed that text. I also found the new first paragraph quite
>>confusing — it said we areissuing this RFP “for consideration” by all
>>parties, which makes itsound like we’re asking people to comment on the
>>RFP itself, ratherthan submit proposals. So, I did some editing on the
>>first twoparagraphs, and also tried to work in the good suggestion from
>>Manalthat we re-emphasize that we will direct comments to the
>>operationalcommunities where we can. Here is how the first two
>>paragraphs read now: "The IANA Stewardship Transition Coordination Group
>>(ICG)  is seekingcomplete formal responses to this Request for Proposals
>>(RFP) from the“operational communities” of IANA (i.e., those with direct
>>operationalor service relationships with IANA; namely names, numbers,
>>protocolparameters). Other interested and affected parties are
>>stronglyencouraged to provide their inputs through open processes run by
>>theseoperational communities.  Other parties may provide comments to
>>theICG on particular aspects that may be covered by proposals that may
>>beof significant interest to them, for review by  the ICG as time
>>andresources permit. The ICG will direct comments received from
>>otherparties to the relevant operational communities as appropriate.
>>During the development of their proposals, the operational
>>communitiesare expected to consult and work with other affected
>>parties;likewise, other affected parties are strongly encouraged
>>toparticipate in community processes, as the ICG is requiring
>>proposalsthat have consensus support from a broad range of stakeholder
>>groups.” In section 0, I edited “change” to “address” in "Identify
>>whichcategory of the IANA functions this submission proposes to
>>change”since some communities might propose no changes. In section 4 I
>>still think there are three bullet points that needelaboration, of just
>>one sentence each, because they are not clear ontheir face: ·Continuity
>>of service requirements·Risks·Service integration aspects  For example,
>>“Risks” seems so vague that each community could write anovel about them
>>and not be complete. What are we really looking forhere? Thanks,Alissa
>>On 8/19/14, 8:50 AM, "joseph alhadeff" <joseph.alhadeff at oracle.com>
>><mailto:joseph.alhadeff at oracle.com>wrote: I have uploaded v9(jha) with a
>>few suggested edits to further clarifythe operational vs impacted
>>communities comment process... Also aquestion of whether testing should
>>be limited to Section III - arethose the only changes contemplated that
>>could impact stability andfunctionality? I think we are getting pretty
>>close to a final draft... JoeOn 8/19/2014 11:05 AM, Milton L Mueller
>>wrote:Paul:Done. It is uploaded as docx as version 09. Also proposed
>>someminor clarity changes to the preamble and added a comment
>>respondingto Martin's nervousness. We can't have Martin being nervous.
>>Milton L MuellerLaura J and L. Douglas Meredith Professor Syracuse
>>UniversitySchool of Information
>>Studieshttp://faculty.ischool.syr.edu/mueller/   -----Original
>>Message-----From: internal-cg-bounces at icann.org
>>[mailto:internal-cg-bounces at icann.org] On Behalf Of Paul WilsonSent:
>>Tuesday, August 19, 2014 10:05 AMTo: ICGSubject: Re: [Internal-cg]
>>Further RFP revision Milton, thanks for your comments on the "section 0"
>>part.  thisadds some  needed clarity about the whole orientation of this
>process. If you can, please make further edits to the version 8
>documentlinked below. Paul.     On 19 Aug 2014, at 9:30 pm, Paul Wilson
><pwilson at apnic.net> <mailto:pwilson at apnic.net> wrote: Apologies for the
>delay, a new RFP revision is now online:
>8.docx Paul     On 19 Aug 2014, at 8:52 pm, Paul Wilson
><pwilson at apnic.net> <mailto:pwilson at apnic.net> wrote: Dear all, I am in
>the process of reconciling all inputs on the latest RFPdocument,
>and will have a clean version available in Dropbox shortly.My intention
>is to go run this document sequentially duringtonight's
>meeting, seeking ICG members' views and suggestions.Thanks, Paul.
>ul Wilson, Director-General, APNIC <dg at apnic.net>
><mailto:dg at apnic.net>http://www.apnic.net
>    +61 7
>38583100 See you at APNIC 38!http://conference.apnic.net/38
>_______________________________________________Internal-cg mailing
>listInternal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg
>_______________________________________________Internal-cg mailing
>listInternal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg
> _______________________________________________Internal-cg mailing
>listInternal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg
>_______________________________________________Internal-cg mailing
>listInternal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg
>Internal-cg mailing list
>Internal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: IANA Transition RFP v12.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 43823 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140822/5ce1200a/IANATransitionRFPv12.docx>

More information about the Internal-cg mailing list