[Internal-cg] Revised RFP
adiel at afrinic.net
Thu Aug 14 12:03:07 UTC 2014
I’m fine with this version of the RFP. I ahve made few comment in the document that I have updated in Dropbox. I’m quite comfortable with the term “Operational Community” we should use something more inclusive than that. I also believe that we should use a language in the document that is less strong on the fact that we expecting proposals only from the 3 direct beneficiaries of IANA services (I share MM comment in that regard in the v.7 of the document).
On Aug 14, 2014, at 04:00 AM, Alissa Cooper <alissa at cooperw.in> wrote:
> Thanks. Comments in-line.
> On 8/13/14, 1:31 PM, "Milton L Mueller" <mueller at 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.
>> 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.
>>> -----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
>>> 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
>>> proposed, post-transition ones. However, by creating a table with a
>>> column and a “future” column for every element in the RFP, I think we
>>> be giving the communities the wrong impression that they should be
>>> about possible changes to all aspects of IANA. That is a much wider
>>> 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
>>> 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
>>> the communities for.
>>> So, in the attached version, I’ve done a re-organization. The document
>>> divided into two main parts: Introduction and Required Proposal
>>> The outline of the Required Proposal Elements section is as follows:
>>> I. Description of Community’s Use of IANA II. Existing, Pre-Transition
>>> A. Policy
>>> B. Oversight and Accountability
>>> III. Proposed Post-Transition Oversight and Accountability Arrangements
>>> Transition Implications V. Community Process
>>> I think this structure makes it more clear where we’re asking for
>>> of existing arrangements, and where we’re asking for proposed changes
>>> related to the transition (and specifically related to oversight and
>>> Some other changes I suggest:
>>> * I think we still need more clarity on who we’re asking for proposals
>>> and how many we expect to receive. I found the existing drafts muddled
>>> this point and tried to clarify. We might also still have some
>>> 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
>>> 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
>>> 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
>>> 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.
>>> 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
> Internal-cg mailing list
> Internal-cg at icann.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 313 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Internal-cg