[Internal-cg] FW: Further RFP revision

Alissa Cooper alissa at cooperw.in
Mon Aug 25 18:20:31 UTC 2014

Hi Manal,

I think this is still to be determined. My inclination would be to
integrate the proposals first, but this is not a decision we have to make


On 8/24/14, 11:41 AM, "Manal Ismail" <manal at tra.gov.eg> wrote:

>I'm a bit confused with respect to input from 'interested parties' other
>than the 'Operational Communities', after Dec. 31st ..
>Are we going to allow comments on the individual proposals submitted or
>integrate them first then call for comments on the unified version? Or is
>it still to be decided?
>Apologies if this has already been discussed and I overlooked the
>decision ..
>Kind Regards
>-----Original Message-----
>From: internal-cg-bounces at icann.org
>[mailto:internal-cg-bounces at icann.org] On Behalf Of joseph alhadeff
>Sent: Saturday, August 23, 2014 9:22 PM
>To: internal-cg at icann.org
>Subject: Re: [Internal-cg] FW: Further RFP revision
>That's an acceptable comproimse.
>On 8/23/2014 11:33 AM, Milton L Mueller wrote:
>> I oppose having a public comment period on the RFP. The RFP is not the
>>kind of document for which general public comments make sense.
>> I think we can use the less formal network model of interaction
>>instead; i.e., individual ICG members share the penultimate draft with
>>the people they represent and get some reaction over the next few days.
>>> -----Original Message-----
>>> From: Alissa Cooper [mailto:alissa at cooperw.in]
>>> Sent: Friday, August 22, 2014 5:44 PM
>>> To: Milton L Mueller; joseph alhadeff; internal-cg at icann.org
>>> Subject: Re: [Internal-cg] FW: Further RFP revision
>>> 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 credibility.
>>> 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
>>> Alissa
>>> On 8/22/14, 1:07 PM, "Milton L Mueller" <mueller at syr.edu> wrote:
>>>> Joe,
>>>> 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
>>>> 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?
>>>> --MM
>>>> 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
>>>> Milton:
>>>> 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.
>>>> Joe
>>>> 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
>>>>> 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
>>>>> Message-----From:
>>>>> 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
>>>>> <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
>>>> <pwilson at apnic.net> <mailto:pwilson at apnic.net> wrote: Apologies for
>>>> the delay, a new RFP revision is now online:
>>>> https://www.dropbox.com/s/4d2izh5jobgyu48/IANA%20Transition%20RFP%
>>>> <https://www.dropbox.com/s/4d2izh5jobgyu48/IANA%20Transition%20RFP%2
>>> 5>20v0
>>>> 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.
>>>> ________________________________________________________________
>>> _______
>>>> _Pa 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/inter
>>>> nal -cg _______________________________________________Internal-cg
>>> mailing
>>>> listInternal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/inter
>>>> nal -cg  _______________________________________________Internal-cg
>>> mailing
>>>> listInternal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/inter
>>>> nal
>>>> -cg
>>>> _______________________________________________Internal-cg mailing
>>>> listInternal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/inter
>>>> nal
>>>> -cg
>>>> _______________________________________________
>>>> Internal-cg mailing list
>>>> Internal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/internal-
>>>> cg
>> _______________________________________________
>> Internal-cg mailing list
>> Internal-cg at icann.org
>> https://mm.icann.org/mailman/listinfo/internal-cg
>Internal-cg mailing list
>Internal-cg at icann.org
>Internal-cg mailing list
>Internal-cg at icann.org

More information about the Internal-cg mailing list