<div dir="ltr"><div><div>Dear All, <br><br></div>i have reviewed the latest version of the RFP v7, the document follow and formatting is good.<br></div><p class="">following up the recent comments from Adiel, milton and Alissa, I am concerned that we are planning to limit the proposals
submissions only the 3 or 4 operational communities, this approach will sending a negative message to the global internet community observing this process and will rise questions about the
transparency, inclusiveness and objective of the process.</p>
<p class="">The current NTIA/ICANN IANA function contract (clause C.1.3 ) identify a list of “interested and
affected communities” which ICANN should consult/engage with in matters related
to IANA Functions ( this include naming, numbering, protocol, end users communities ), both the affected "operational" interested "non-operational" communities should be able to submit proposals to ICG ( if they wish to do so ).</p>
<p class="">The interested "non-operational" communities are already represented in ICG, the community should decide submit a proposal ( following the RFP requirements and NTIA principles ) or participate in the affected "operational" communities proposal development process and not submit its own proposal .</p>
<p class="">How ICG will review/manage submitted proposals ? <br>we are encouraging the communities to consult with their stakeholders and sub-committees in the process of the proposal development, if a proposal is submitted directly to ICG not through the communities channel, we should be able to direct vendor "submitter" to the community process and not consider the proposal as it dose not meet the submission requirements .<br>
</p><p class="">ICG is expected to be reviewing the proposals submitted by the communities ( either 3 - 4 from the operational communities and/or 2 if interested communities wished to do so .</p><p class="">I have updated v7 in dropbox with my above comments.</p>
<p class="">Regards,<br>Mohamed<br></p>On Fri, Aug 15, 2014 at 8:13 AM, Russ Mundy <span dir="ltr"><<a href="mailto:mundy@tislabs.com" target="_blank">mundy@tislabs.com</a>></span> wrote:<br><div><div><div><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Folks,<br>
<br>
I realize that there have been some folks questioning the need to request/suggest that the operational communities' proposals make reference to the ICANN proposal portion of the IANA Functions Contract. I believe there was only one email from Daniel questioning the need for this reference but there were a couple of comments in version 6 revision associated with deleting the wording from the RFP.<br>
<br>
In our current draft Charter, we commit to " • (ii) Assess the outputs of the three operational communities for compatibility and interoperability". For the ICG to meet this commitment, we must have some common point of reference used by all the operational communities in preparing their respective proposals or we will not be able to meet commitment (ii).<br>
<br>
Each of the operational communities has a different central focus and varying degrees of documentation of their own processes but each overlaps the other to various degrees. The current RFP provides a good structure for the proposals but the actual content of each proposal will almost certainly reflect each community's central focus and processes. Since there is no common reference point for the communities, it is very unlikely that the proposals will provide enough details in their content for us (the ICG) to assess compatibility and interoperability of the 3 (or 4) operational communities' proposals.<br>
<br>
The ICG does not have the time to produce a substantially more detailed RFP where we could expect comparable proposal content from the operational communities. I believe that the various versions of the RFP will provide common format but will not provide comparable information. I believe that the solution is to ask that the proposals make appropriate references to the only document that describes current operational implementation of all the operational communities i.e., the ICANN proposal portion of the IANA Functions Contract.<br>
<br>
Meeting commitment (ii) will be a challenge even with a single point of reference for all proposals from the operational community. However, without a single point of reference, it will not be possible for the ICG to actually meet commitment (ii).<br>
<br>
As a related point, I do prefer the structure of version 7 over earlier versions.<br>
<br>
Thoughts and responses are very welcome.<br>
<br>
Regards,<br>
<br>
Russ<br>
<div class=""><div class="h5"><br>
><br>
> On Aug 14, 2014, at 04:00 AM, Alissa Cooper <<a href="mailto:alissa@cooperw.in">alissa@cooperw.in</a>> wrote:<br>
><br>
>> Thanks. Comments in-line.<br>
>><br>
>> On 8/13/14, 1:31 PM, "Milton L Mueller" <<a href="mailto:mueller@syr.edu">mueller@syr.edu</a>> wrote:<br>
>><br>
>>> Nice job on the whole! Your approach to mapping transitions, which builds<br>
>>> on mine, is simpler.<br>
>>> I approve of the use of the charter language on operational communities.<br>
>>><br>
>>> In the attached version, I've accepted the changes I think are<br>
>>> uncontroversial, so as to produce a cleaner document; made a few minor<br>
>>> changes, and added some comments that address questions raised by Alissa.<br>
>>><br>
>>> Only major changes are, I still think we need a checkbox at the beginning<br>
>>> telling us what community the proposal is coming form,<br>
>><br>
>> I’m fine with this, with the caveat that I think it should just be listed<br>
>> in words in Section I. It’s highly likely that the proposal for protocol<br>
>> parameters will come in the form of ASCII text (as all IETF documents do),<br>
>> and reproducing a checkbox in ASCII seems unnecessary. So I would suggest<br>
>> that the first sentence of Section I should say:<br>
>><br>
>> "This section should identify your community as names, numbers, or<br>
>> protocol parameters, and it should list the specific, distinct IANA<br>
>> services or activities your community relies on."<br>
>><br>
>><br>
>>> and I think we still need to ask them about overlaps or interdependencies<br>
>>> among the IANA services requirements across communities.<br>
>><br>
>> Agreed.<br>
>><br>
>>><br>
>>><br>
>>> Also, I agree with you that we will need to discuss who we expect to<br>
>>> receive proposals from, I make a few comments on that.<br>
>><br>
>> I will start a separate thread on this.<br>
>><br>
>> Alissa<br>
>><br>
>>><br>
>>> --MM<br>
>>><br>
>>>> -----Original Message-----<br>
>>>> From: Alissa Cooper [mailto:<a href="mailto:alissa@cooperw.in">alissa@cooperw.in</a>]<br>
>>>> Sent: Wednesday, August 13, 2014 3:19 PM<br>
>>>> To: Milton L Mueller; <a href="mailto:internal-cg@icann.org">internal-cg@icann.org</a><br>
>>>> Subject: Re: [Internal-cg] Revised RFP<br>
>>>><br>
>>>> Hi all,<br>
>>>><br>
>>>> I reviewed the various RFP versions, including the version that Milton<br>
>>>> recently sent. I’ve attached and uploaded to Dropbox my own suggested<br>
>>>> version. I know there is a danger in suggesting yet another different<br>
>>>> format,<br>
>>>> but let me try to explain my thinking.<br>
>>>><br>
>>>> I sympathize with Milton’s concern that the community proposals need to<br>
>>>> make a clear distinction between existing, pre-transition arrangements<br>
>>>> and<br>
>>>> proposed, post-transition ones. However, by creating a table with a<br>
>>>> “now”<br>
>>>> column and a “future” column for every element in the RFP, I think we<br>
>>>> would<br>
>>>> be giving the communities the wrong impression that they should be<br>
>>>> thinking<br>
>>>> about possible changes to all aspects of IANA. That is a much wider<br>
>>>> scope<br>
>>>> than what we have all agreed to work on and what NTIA is asking for, I<br>
>>>> believe. Of course discussions about stewardship transition may (and<br>
>>>> already<br>
>>>> have) spurred discussions about changes to other aspects, which is<br>
>>>> great, but<br>
>>>> I don’t think those things are in the scope of what we specifically are<br>
>>>> asking<br>
>>>> the communities for.<br>
>>>><br>
>>>> So, in the attached version, I’ve done a re-organization. The document<br>
>>>> is<br>
>>>> divided into two main parts: Introduction and Required Proposal<br>
>>>> Elements.<br>
>>>> The outline of the Required Proposal Elements section is as follows:<br>
>>>><br>
>>>> I. Description of Community’s Use of IANA II. Existing, Pre-Transition<br>
>>>> Arrangements<br>
>>>> A. Policy<br>
>>>> B. Oversight and Accountability<br>
>>>> III. Proposed Post-Transition Oversight and Accountability Arrangements<br>
>>>> IV.<br>
>>>> Transition Implications V. Community Process<br>
>>>><br>
>>>> I think this structure makes it more clear where we’re asking for<br>
>>>> descriptions<br>
>>>> of existing arrangements, and where we’re asking for proposed changes<br>
>>>> related to the transition (and specifically related to oversight and<br>
>>>> accountability).<br>
>>>><br>
>>>> Some other changes I suggest:<br>
>>>><br>
>>>> * I think we still need more clarity on who we’re asking for proposals<br>
>>>> from<br>
>>>> and how many we expect to receive. I found the existing drafts muddled<br>
>>>> on<br>
>>>> this point and tried to clarify. We might also still have some<br>
>>>> disagreements<br>
>>>> about this — good topic for discussion on the call next week. In any<br>
>>>> event, I<br>
>>>> adopted the “operational communities” language from the charter so that<br>
>>>> we can be consistent.<br>
>>>><br>
>>>> * On Russ Mundy’s point about the current contract: I agree with Daniel<br>
>>>> that<br>
>>>> we can’t really require the communities to leverage the existing<br>
>>>> contract any<br>
>>>> more than they want to. So I softened this language a bit.<br>
>>>><br>
>>>> * In the Required Proposal Elements sections, I tried to re-use as many<br>
>>>> of the<br>
>>>> existing bullet points/table rows as possible, but for many of them I<br>
>>>> found<br>
>>>> myself wondering what the bullets actually meant. I think this is not<br>
>>>> the best<br>
>>>> sign, since as an IETF participant I wouldn’t necessarily know what to<br>
>>>> put in a<br>
>>>> protocol parameters proposal in response to this RFP. So I tried to<br>
>>>> elaborate<br>
>>>> on the bullet points somewhat. I may or may not have captured their<br>
>>>> intended meaning, and I put comments in on some of them when I really<br>
>>>> didn’t know what they were aiming towards.<br>
>>>><br>
>>>> Best,<br>
>>>> Alissa<br>
>>>><br>
>>>><br>
>>>> On 8/11/14, 1:33 PM, "Milton L Mueller" <<a href="mailto:mueller@syr.edu">mueller@syr.edu</a>> wrote:<br>
>>>><br>
>>>><br>
>>>>> Dear colleagues<br>
>>>>> I spent some time thinking about the RFP and how it could be improved<br>
>>>>> and came up with the attached draft, which is also in Dropbox.<br>
>>>>> I changed some language in the preamble, with some comments in Word<br>
>>>>> explaining why.<br>
>>>>><br>
>>>>> The main change, however is one of format. I think when commnities fill<br>
>>>>> out this form we will need a clear distinction between what their<br>
>>>>> requirements, policy processes, etc. are NOW, and what they are<br>
>>>>> proposing to CHANGE. Therefore I have created a series of tables that<br>
>>>>> lines up Current arrangements from Proposed arrangements. This should<br>
>>>>> make it clearer what exactly they are proposing to change and what the<br>
>>>>> implications might be.<br>
>>>>><br>
>>>>><br>
>>>>> Take a look<br>
>>>>><br>
>>>>> Milton L Mueller<br>
>>>>> Professor, Syracuse University School of Information Studies Internet<br>
>>>>> Governance Project <a href="http://internetgovernance.org" target="_blank">http://internetgovernance.org</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Internal-cg mailing list<br>
>>>>> Internal-cg@icann.orghttps://<a href="http://mm.icann.org/mailman/listinfo/internal-cg" target="_blank">mm.icann.org/mailman/listinfo/internal-cg</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Internal-cg mailing list<br>
>> <a href="mailto:Internal-cg@icann.org">Internal-cg@icann.org</a><br>
>> <a href="https://mm.icann.org/mailman/listinfo/internal-cg" target="_blank">https://mm.icann.org/mailman/listinfo/internal-cg</a><br>
><br>
> _______________________________________________<br>
> Internal-cg mailing list<br>
> <a href="mailto:Internal-cg@icann.org">Internal-cg@icann.org</a><br>
> <a href="https://mm.icann.org/mailman/listinfo/internal-cg" target="_blank">https://mm.icann.org/mailman/listinfo/internal-cg</a><br>
<br>
</div></div><br>_______________________________________________<br>
Internal-cg mailing list<br>
<a href="mailto:Internal-cg@icann.org">Internal-cg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/internal-cg" target="_blank">https://mm.icann.org/mailman/listinfo/internal-cg</a><br>
<br></blockquote></div><br></div></div></div></div></div>