[Internal-cg] Revised RFP

Wed Aug 13 20:31:52 UTC 2014

Nice job on the whole! Your approach to mapping transitions, which builds on mine, is simpler. 
I approve of the use of the charter language on operational communities. 

In the attached version, I've accepted the changes I think are uncontroversial, so as to produce a cleaner document; made a few minor changes, and added some comments that address questions raised by Alissa.

Only major changes are, I still think we need a checkbox at the beginning telling us what community the proposal is coming form, and I think we still need to ask them about overlaps or interdependencies among the IANA services requirements across communities. 

Also, I agree with you that we will need to discuss who we expect to receive proposals from, I make a few comments on that.

--MM

> -----Original Message-----
> From: Alissa Cooper [mailto:alissa at cooperw.in]
> Sent: Wednesday, August 13, 2014 3:19 PM
> To: Milton L Mueller; internal-cg at icann.org
> Subject: Re: [Internal-cg] Revised RFP
> 
> Hi all,
> 
> I reviewed the various RFP versions, including the version that Milton
> recently sent. I’ve attached and uploaded to Dropbox my own suggested
> version. I know there is a danger in suggesting yet another different format,
> but let me try to explain my thinking.
> 
> I sympathize with Milton’s concern that the community proposals need to
> make a clear distinction between existing, pre-transition arrangements and
> proposed, post-transition ones. However, by creating a table with a “now”
> column and a “future” column for every element in the RFP, I think we would
> be giving the communities the wrong impression that they should be thinking
> about possible changes to all aspects of IANA. That is a much wider scope
> than what we have all agreed to work on and what NTIA is asking for, I
> believe. Of course discussions about stewardship transition may (and already
> have) spurred discussions about changes to other aspects, which is great, but
> I don’t think those things are in the scope of what we specifically are asking
> the communities for.
> 
> So, in the attached version, I’ve done a re-organization. The document is
> divided into two main parts: Introduction and Required Proposal Elements.
> The outline of the Required Proposal Elements section is as follows:
> 
> I. Description of Community’s Use of IANA II. Existing, Pre-Transition
> Arrangements
> 	A. Policy
> 	B. Oversight and Accountability
> III. Proposed Post-Transition Oversight and Accountability Arrangements IV.
> Transition Implications V. Community Process
> 
> I think this structure makes it more clear where we’re asking for descriptions
> of existing arrangements, and where we’re asking for proposed changes
> related to the transition (and specifically related to oversight and
> accountability).
> 
> Some other changes I suggest:
> 
> * I think we still need more clarity on who we’re asking for proposals from
> and how many we expect to receive. I found the existing drafts muddled on
> this point and tried to clarify. We might also still have some disagreements
> about this — good topic for discussion on the call next week. In any event, I
> adopted the “operational communities” language from the charter so that
> we can be consistent.
> 
> * On Russ Mundy’s point about the current contract: I agree with Daniel that
> we can’t really require the communities to leverage the existing contract any
> more than they want to. So I softened this language a bit.
> 
> * In the Required Proposal Elements sections, I tried to re-use as many of the
> existing bullet points/table rows as possible, but for many of them I found
> myself wondering what the bullets actually meant. I think this is not the best
> sign, since as an IETF participant I wouldn’t necessarily know what to put in a
> protocol parameters proposal in response to this RFP. So I tried to elaborate
> on the bullet points somewhat. I may or may not have captured their
> intended meaning, and I put comments in on some of them when I really
> didn’t know what they were aiming towards.
> 
> Best,
> Alissa
> 
> 
> On 8/11/14, 1:33 PM, "Milton L Mueller" <mueller at syr.edu> wrote:
> 
> 
> >Dear colleagues
> >I spent some time thinking about the RFP and how it could be improved
> >and came up with the attached draft, which is also in Dropbox.
> >I changed some language in the preamble, with some comments in Word
> >explaining why.
> >
> >The main change, however is one of format. I think when commnities fill
> >out this form we will need a clear distinction between what their
> >requirements, policy processes, etc. are NOW, and what they are
> >proposing to CHANGE. Therefore I have  created a series of tables that
> >lines up Current arrangements from Proposed arrangements. This should
> >make it clearer what exactly they are proposing to change and what the
> >implications might be.
> >
> >
> >Take a look
> >
> >Milton L Mueller
> >Professor, Syracuse University School of Information Studies Internet
> >Governance Project http://internetgovernance.org
> >
> >
> >
> >
> >
> >_______________________________________________
> >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 v07 (ALC-MM).docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 39827 bytes
Desc: IANA Transition RFP v07 (ALC-MM).docx
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140813/e1d81377/IANATransitionRFPv07ALC-MM.docx>