[Internal-cg] Revised RFP

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). 

Thanks.

- a.
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.
> 
> 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 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
>> 
> 
> 
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140814/3df552c9/signature.asc>