Thanks. Comments in-line. On 8/13/14, 1:31 PM, "Milton L Mueller" <mueller@syr.edu> wrote:
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,
I’m fine with this, with the caveat that I think it should just be listed in words in Section I. It’s highly likely that the proposal for protocol parameters will come in the form of ASCII text (as all IETF documents do), and reproducing a checkbox in ASCII seems unnecessary. So I would suggest that the first sentence of Section I should say: "This section should identify your community as names, numbers, or protocol parameters, and it should list the specific, distinct IANA services or activities your community relies on."
and I think we still need to ask them about overlaps or interdependencies among the IANA services requirements across communities.
Agreed.
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.
I will start a separate thread on this. Alissa
--MM
-----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: Wednesday, August 13, 2014 3:19 PM To: Milton L Mueller; internal-cg@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@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@icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg