[Internal-cg] FW: Further RFP revision

Manal Ismail manal at tra.gov.eg
Sun Aug 24 18:41:15 UTC 2014

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 though.
>> 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 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?
>>> --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 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
>>>> 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 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:
>>> 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

More information about the Internal-cg mailing list