Dear All, i have reviewed the latest version of the RFP v7, the document follow and formatting is good. 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. 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 ). 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 . How ICG will review/manage submitted proposals ? 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 . 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 . I have updated v7 in dropbox with my above comments. Regards, Mohamed On Fri, Aug 15, 2014 at 8:13 AM, Russ Mundy <mundy@tislabs.com> wrote:
Folks,
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.
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).
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.
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.
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).
As a related point, I do prefer the structure of version 7 over earlier versions.
Thoughts and responses are very welcome.
Regards,
Russ
On Aug 14, 2014, at 04:00 AM, Alissa Cooper <alissa@cooperw.in> wrote:
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
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Hi All, Mohamed beat me to it, so I have applied the amendments/comments I was working on on top of his and posted back in dropbox. I’d like to make a couple of explanatory notes, though: 1. There seems to be a tendency to widen the number of fronts: I am concerned that, if we open to all stakeholder communities, we are essentially bypassing the focus on the three functions as centres of thinking. The more I have thought about this, the more I see little value for any community NOT to submit its own proposal(s) whereas we really need the different groups to work with all affected stakeholders on their bit of the puzzle. I thought (really believed) that were working on the operational lead approach expecting each to adopt its own process with its affected parties and other stakeholders. I hope that we can keep to this approach. 2. I’ve noted in a previous mail on this document that there are a number of ccTLDs who do not (and will not) engage with ICANN. I’m happy for us not to encourage individual or small-group submissions, but we have to understand that there is a high probability that we will get input, so there is no point in trying to discourage them. But we do need to think about how this might be dealt with and pose our questions to the wider community in a different form. One way might be to offer a “fast track” approach to identify specific problems or requirements that they feel need to be addressed. 3. I was left puzzled by references to an input from Daniel which I was not able to find. I have commented on this paragraph somewhat in the dark (apologies if I’ve missed the point), but it does seem to me to be important for us to use the current NTIA/ICANN as the current basis. This is then reflected in a couple of comments in the last section, on maintaining the framework for service delivery and on the clear separation of policy responsibility from the IANA. By the way, is it v0.7 (as in the file title) or v0.6 (as in the document)? Thanks Martin
I’ve reviewed v 0.7 with comments of Martin, Mohamed and Adiel, and am also addressing Russ Mundy’s observations on the RFP. First, an easy issue: nothing in the language referring to the IANA contract implies that anyone is “bound” by anything. It simply uses the current IANA contract as a uniform point of reference. Let me reproduce the language here: “In the interest of consistency, each community is encouraged to review and consider the current IANA Functions Contract between NTIA and ICANN when describing existing arrangements and proposing changes to existing arrangements.” I think that is clearly just asking for a consistent point of reference and we can dispose of this “don’t bind the operational communities” issue completely. The more difficult issue concerns the leading role of the operational communities and the possibility of multiple submissions. This problem challenges the concept that the ICG is a “non-decisional” body. If we decide who can and cannot submit proposals, we are in fact making a critical substantive decision, one that profoundly influences the nature of the proposals. On the other hand, if we allow or encourage proposals by anyone and everyone who feels like submitting one, we are put into the position of selecting among them and even modifying/reassembling them. So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected. I actually think the current draft finds the appropriate middle ground between this Scylla and Charybdis. It strongly encourages everyone to work together in an operational community-led process, but does not expressly prohibit other proposals. Here is the language: During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups. Only change I would suggest is that we change “expected” to “required” in the first line. To Mohamed, I would say that the operational communities HAVE TO be considered the primary stakeholders in the transition, because they are the people who rely on the IANA functions in a direct, operational sense and its functionality and responsiveness is a life or death matter for them. --MM From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Martin Boyle Sent: Friday, August 15, 2014 11:28 AM To: Mohamed El Bashir; internal-cg@icann.org Internal Subject: Re: [Internal-cg] Revised RFP Hi All, Mohamed beat me to it, so I have applied the amendments/comments I was working on on top of his and posted back in dropbox. I’d like to make a couple of explanatory notes, though: 1. There seems to be a tendency to widen the number of fronts: I am concerned that, if we open to all stakeholder communities, we are essentially bypassing the focus on the three functions as centres of thinking. The more I have thought about this, the more I see little value for any community NOT to submit its own proposal(s) whereas we really need the different groups to work with all affected stakeholders on their bit of the puzzle. I thought (really believed) that were working on the operational lead approach expecting each to adopt its own process with its affected parties and other stakeholders. I hope that we can keep to this approach. 2. I’ve noted in a previous mail on this document that there are a number of ccTLDs who do not (and will not) engage with ICANN. I’m happy for us not to encourage individual or small-group submissions, but we have to understand that there is a high probability that we will get input, so there is no point in trying to discourage them. But we do need to think about how this might be dealt with and pose our questions to the wider community in a different form. One way might be to offer a “fast track” approach to identify specific problems or requirements that they feel need to be addressed. 3. I was left puzzled by references to an input from Daniel which I was not able to find. I have commented on this paragraph somewhat in the dark (apologies if I’ve missed the point), but it does seem to me to be important for us to use the current NTIA/ICANN as the current basis. This is then reflected in a couple of comments in the last section, on maintaining the framework for service delivery and on the clear separation of policy responsibility from the IANA. By the way, is it v0.7 (as in the file title) or v0.6 (as in the document)? Thanks Martin
I agree fully with Milton here. Thanks, Keith Drazek On Aug 15, 2014, at 12:38 PM, "Milton L Mueller" <mueller@syr.edu<mailto:mueller@syr.edu>> wrote: I’ve reviewed v 0.7 with comments of Martin, Mohamed and Adiel, and am also addressing Russ Mundy’s observations on the RFP. First, an easy issue: nothing in the language referring to the IANA contract implies that anyone is “bound” by anything. It simply uses the current IANA contract as a uniform point of reference. Let me reproduce the language here: “In the interest of consistency, each community is encouraged to review and consider the current IANA Functions Contract between NTIA and ICANN when describing existing arrangements and proposing changes to existing arrangements.” I think that is clearly just asking for a consistent point of reference and we can dispose of this “don’t bind the operational communities” issue completely. The more difficult issue concerns the leading role of the operational communities and the possibility of multiple submissions. This problem challenges the concept that the ICG is a “non-decisional” body. If we decide who can and cannot submit proposals, we are in fact making a critical substantive decision, one that profoundly influences the nature of the proposals. On the other hand, if we allow or encourage proposals by anyone and everyone who feels like submitting one, we are put into the position of selecting among them and even modifying/reassembling them. So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected. I actually think the current draft finds the appropriate middle ground between this Scylla and Charybdis. It strongly encourages everyone to work together in an operational community-led process, but does not expressly prohibit other proposals. Here is the language: During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups. Only change I would suggest is that we change “expected” to “required” in the first line. To Mohamed, I would say that the operational communities HAVE TO be considered the primary stakeholders in the transition, because they are the people who rely on the IANA functions in a direct, operational sense and its functionality and responsiveness is a life or death matter for them. --MM From: internal-cg-bounces@icann.org<mailto:internal-cg-bounces@icann.org> [mailto:internal-cg-bounces@icann.org] On Behalf Of Martin Boyle Sent: Friday, August 15, 2014 11:28 AM To: Mohamed El Bashir; internal-cg@icann.org<mailto:internal-cg@icann.org> Internal Subject: Re: [Internal-cg] Revised RFP Hi All, Mohamed beat me to it, so I have applied the amendments/comments I was working on on top of his and posted back in dropbox. I’d like to make a couple of explanatory notes, though: 1. There seems to be a tendency to widen the number of fronts: I am concerned that, if we open to all stakeholder communities, we are essentially bypassing the focus on the three functions as centres of thinking. The more I have thought about this, the more I see little value for any community NOT to submit its own proposal(s) whereas we really need the different groups to work with all affected stakeholders on their bit of the puzzle. I thought (really believed) that were working on the operational lead approach expecting each to adopt its own process with its affected parties and other stakeholders. I hope that we can keep to this approach. 2. I’ve noted in a previous mail on this document that there are a number of ccTLDs who do not (and will not) engage with ICANN. I’m happy for us not to encourage individual or small-group submissions, but we have to understand that there is a high probability that we will get input, so there is no point in trying to discourage them. But we do need to think about how this might be dealt with and pose our questions to the wider community in a different form. One way might be to offer a “fast track” approach to identify specific problems or requirements that they feel need to be addressed. 3. I was left puzzled by references to an input from Daniel which I was not able to find. I have commented on this paragraph somewhat in the dark (apologies if I’ve missed the point), but it does seem to me to be important for us to use the current NTIA/ICANN as the current basis. This is then reflected in a couple of comments in the last section, on maintaining the framework for service delivery and on the clear separation of policy responsibility from the IANA. By the way, is it v0.7 (as in the file title) or v0.6 (as in the document)? Thanks Martin _______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
Interesting points, Milton. Especially with regard to: "So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected." Personally I do not believe the ICG can totally insulate itself from making material decisions (or “choices”) on the proposals, regardless of the path chosen. Even if submissions are limited to the smallest possible number, there are bound to be minor differences between them that require some degree of reconciliation by the ICG. Thanks— J. From: Milton L Mueller <mueller@syr.edu<mailto:mueller@syr.edu>> Date: Friday, August 15, 2014 at 11:38 To: ICG List <internal-cg@icann.org<mailto:internal-cg@icann.org>> Subject: Re: [Internal-cg] Revised RFP I’ve reviewed v 0.7 with comments of Martin, Mohamed and Adiel, and am also addressing Russ Mundy’s observations on the RFP. First, an easy issue: nothing in the language referring to the IANA contract implies that anyone is “bound” by anything. It simply uses the current IANA contract as a uniform point of reference. Let me reproduce the language here: “In the interest of consistency, each community is encouraged to review and consider the current IANA Functions Contract between NTIA and ICANN when describing existing arrangements and proposing changes to existing arrangements.” I think that is clearly just asking for a consistent point of reference and we can dispose of this “don’t bind the operational communities” issue completely. The more difficult issue concerns the leading role of the operational communities and the possibility of multiple submissions. This problem challenges the concept that the ICG is a “non-decisional” body. If we decide who can and cannot submit proposals, we are in fact making a critical substantive decision, one that profoundly influences the nature of the proposals. On the other hand, if we allow or encourage proposals by anyone and everyone who feels like submitting one, we are put into the position of selecting among them and even modifying/reassembling them. So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected. I actually think the current draft finds the appropriate middle ground between this Scylla and Charybdis. It strongly encourages everyone to work together in an operational community-led process, but does not expressly prohibit other proposals. Here is the language: During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups. Only change I would suggest is that we change “expected” to “required” in the first line. To Mohamed, I would say that the operational communities HAVE TO be considered the primary stakeholders in the transition, because they are the people who rely on the IANA functions in a direct, operational sense and its functionality and responsiveness is a life or death matter for them. --MM From: internal-cg-bounces@icann.org<mailto:internal-cg-bounces@icann.org> [mailto:internal-cg-bounces@icann.org] On Behalf Of Martin Boyle Sent: Friday, August 15, 2014 11:28 AM To: Mohamed El Bashir; internal-cg@icann.org<mailto:internal-cg@icann.org> Internal Subject: Re: [Internal-cg] Revised RFP Hi All, Mohamed beat me to it, so I have applied the amendments/comments I was working on on top of his and posted back in dropbox. I’d like to make a couple of explanatory notes, though: 1. There seems to be a tendency to widen the number of fronts: I am concerned that, if we open to all stakeholder communities, we are essentially bypassing the focus on the three functions as centres of thinking. The more I have thought about this, the more I see little value for any community NOT to submit its own proposal(s) whereas we really need the different groups to work with all affected stakeholders on their bit of the puzzle. I thought (really believed) that were working on the operational lead approach expecting each to adopt its own process with its affected parties and other stakeholders. I hope that we can keep to this approach. 2. I’ve noted in a previous mail on this document that there are a number of ccTLDs who do not (and will not) engage with ICANN. I’m happy for us not to encourage individual or small-group submissions, but we have to understand that there is a high probability that we will get input, so there is no point in trying to discourage them. But we do need to think about how this might be dealt with and pose our questions to the wider community in a different form. One way might be to offer a “fast track” approach to identify specific problems or requirements that they feel need to be addressed. 3. I was left puzzled by references to an input from Daniel which I was not able to find. I have commented on this paragraph somewhat in the dark (apologies if I’ve missed the point), but it does seem to me to be important for us to use the current NTIA/ICANN as the current basis. This is then reflected in a couple of comments in the last section, on maintaining the framework for service delivery and on the clear separation of policy responsibility from the IANA. By the way, is it v0.7 (as in the file title) or v0.6 (as in the document)? Thanks Martin
Dear All .. I still have to go through the latest version of the RFP but would like to make a few remarks in light of this thread of discussion: - Like Mohamed, Adiel and maybe others, I hope we can encourage and convince the community with the importance and benefits of early discussions and consolidated submissions without setting a hard limit of 3 or 4 proposals; which I believe is somehow reflected in the sentence referenced in Milton's email below .. I also support changing "expected" to "required" as suggested by Milton .. - Similar to what Martin said regarding ccTLDs who do not engage with ICANN, there may be also governments who do not engage with ICANN and still want to submit their views .. Moreover there may be governments who already engage with ICANN and would still like to put their proposals on record .. I'm not saying this should be encouraged but saying we cannot but accept such submissions .. - The above suggestions do not diminish the importance of the 3/4 proposals of the operational communities .. I do apologize if the above points have already been addressed and settled .. Furthermore, I believe it's important to discuss Milton's below statement which summarizes the situation perfectly well .. I believe ICG should not "make a decision limiting who can submit" (rather encourage and convince) .. On the other hand ICG should, to the extent possible, avoid making "a decision about which proposals are selected" as it already has a limited role of integrating and consolidating all inputs into one proposal .. Accordingly, in case of conflicting views, selections may be settled either by how broadly a proposal is supported or preferably by reverting back to the (relevant) communities to make the choice .. In all cases, in a perfect situation, we should work on allowing iterations of public comment periods (as many as needed and as time allows) to fine tune the final proposal, make selections whenever necessary and ensure broadest community support .. Kind Regards --Manal From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of James M. Bladel Sent: Friday, August 15, 2014 7:51 PM To: Milton L Mueller; internal-cg@icann.org Internal Subject: Re: [Internal-cg] Revised RFP Interesting points, Milton. Especially with regard to: "So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected." Personally I do not believe the ICG can totally insulate itself from making material decisions (or "choices") on the proposals, regardless of the path chosen. Even if submissions are limited to the smallest possible number, there are bound to be minor differences between them that require some degree of reconciliation by the ICG. Thanks- J. From: Milton L Mueller <mueller@syr.edu> Date: Friday, August 15, 2014 at 11:38 To: ICG List <internal-cg@icann.org> Subject: Re: [Internal-cg] Revised RFP I've reviewed v 0.7 with comments of Martin, Mohamed and Adiel, and am also addressing Russ Mundy's observations on the RFP. First, an easy issue: nothing in the language referring to the IANA contract implies that anyone is "bound" by anything. It simply uses the current IANA contract as a uniform point of reference. Let me reproduce the language here: "In the interest of consistency, each community is encouraged to review and consider the current IANA Functions Contract between NTIA and ICANN when describing existing arrangements and proposing changes to existing arrangements." I think that is clearly just asking for a consistent point of reference and we can dispose of this "don't bind the operational communities" issue completely. The more difficult issue concerns the leading role of the operational communities and the possibility of multiple submissions. This problem challenges the concept that the ICG is a "non-decisional" body. If we decide who can and cannot submit proposals, we are in fact making a critical substantive decision, one that profoundly influences the nature of the proposals. On the other hand, if we allow or encourage proposals by anyone and everyone who feels like submitting one, we are put into the position of selecting among them and even modifying/reassembling them. So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected. I actually think the current draft finds the appropriate middle ground between this Scylla and Charybdis. It strongly encourages everyone to work together in an operational community-led process, but does not expressly prohibit other proposals. Here is the language: During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups. Only change I would suggest is that we change "expected" to "required" in the first line. To Mohamed, I would say that the operational communities HAVE TO be considered the primary stakeholders in the transition, because they are the people who rely on the IANA functions in a direct, operational sense and its functionality and responsiveness is a life or death matter for them. --MM From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Martin Boyle Sent: Friday, August 15, 2014 11:28 AM To: Mohamed El Bashir; internal-cg@icann.org Internal Subject: Re: [Internal-cg] Revised RFP Hi All, Mohamed beat me to it, so I have applied the amendments/comments I was working on on top of his and posted back in dropbox. I'd like to make a couple of explanatory notes, though: 1. There seems to be a tendency to widen the number of fronts: I am concerned that, if we open to all stakeholder communities, we are essentially bypassing the focus on the three functions as centres of thinking. The more I have thought about this, the more I see little value for any community NOT to submit its own proposal(s) whereas we really need the different groups to work with all affected stakeholders on their bit of the puzzle. I thought (really believed) that were working on the operational lead approach expecting each to adopt its own process with its affected parties and other stakeholders. I hope that we can keep to this approach. 2. I've noted in a previous mail on this document that there are a number of ccTLDs who do not (and will not) engage with ICANN. I'm happy for us not to encourage individual or small-group submissions, but we have to understand that there is a high probability that we will get input, so there is no point in trying to discourage them. But we do need to think about how this might be dealt with and pose our questions to the wider community in a different form. One way might be to offer a "fast track" approach to identify specific problems or requirements that they feel need to be addressed. 3. I was left puzzled by references to an input from Daniel which I was not able to find. I have commented on this paragraph somewhat in the dark (apologies if I've missed the point), but it does seem to me to be important for us to use the current NTIA/ICANN as the current basis. This is then reflected in a couple of comments in the last section, on maintaining the framework for service delivery and on the clear separation of policy responsibility from the IANA. By the way, is it v0.7 (as in the file title) or v0.6 (as in the document)? Thanks Martin
Dear All ..
I still have to go through the latest version of the RFP but would like to make a few remarks in light of this thread of discussion: - Like Mohamed, Adiel and maybe others, I hope we can encourage and convince the community with the importance and benefits of early discussions and consolidated submissions without setting a hard limit of 3 or 4 proposals; which I believe is somehow reflected in the sentence referenced in Milton’s email below .. I also support changing “expected” to “required” as suggested by Milton .. - Similar to what Martin said regarding ccTLDs who do not engage with ICANN, there may be also governments who do not engage with ICANN and still want to submit their views .. Moreover there may be governments who already engage with ICANN and would still like to put their proposals on record .. I’m not saying this should be encouraged but saying we cannot but accept such submissions .. - The above suggestions do not diminish the importance of the 3/4 proposals of the operational communities .. I do apologize if the above points have already been addressed and settled ..
I agree with Manal's 3 points above.
Furthermore, I believe it’s important to discuss Milton’s below statement which summarizes the situation perfectly well .. I believe ICG should not “make a decision limiting who can submit” (rather encourage and convince) .. On the other hand ICG should, to the extent possible, avoid making “a decision about which proposals are selected” as it already has a limited role of integrating and consolidating all inputs into one proposal .. Accordingly, in case of conflicting views, selections may be settled either by how broadly a proposal is supported or preferably by reverting back to the (relevant) communities to make the choice .. In all cases, in a perfect situation, we should work on allowing iterations of public comment periods (as many as needed and as time allows) to fine tune the final proposal, make selections whenever necessary and ensure broadest community support ..
Agreed regarding the theoretical perfect situation, but we cannot rely on the communities to grant us this luxury. I believe we will inevitably need to make judgements/decisions at some level (as James said), and the difficult of doing that will depend on the specifics. On submissions, I think we cannot rule out anyone in advance; we can only strongly direct people to community processes. Can we draw a clear distinction between the sources of proposals: for instance while we will work to fully reconcile the community proposals, we will consider other proposals and make best efforts to incorporate them, and attempt to note where this has not been possible (and all will go on the public record of course). We should probably also note that we will work within the target timeframes established, and make our best efforts to fully consider all inputs received. It is not possible to guarantee this when we have no idea how many proposals we will see. Paul.
Kind Regards --Manal
From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of James M. Bladel Sent: Friday, August 15, 2014 7:51 PM To: Milton L Mueller; internal-cg@icann.org Internal Subject: Re: [Internal-cg] Revised RFP
Interesting points, Milton. Especially with regard to:
"So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected."
Personally I do not believe the ICG can totally insulate itself from making material decisions (or “choices”) on the proposals, regardless of the path chosen. Even if submissions are limited to the smallest possible number, there are bound to be minor differences between them that require some degree of reconciliation by the ICG.
Thanks—
J.
From: Milton L Mueller <mueller@syr.edu> Date: Friday, August 15, 2014 at 11:38 To: ICG List <internal-cg@icann.org> Subject: Re: [Internal-cg] Revised RFP
I’ve reviewed v 0.7 with comments of Martin, Mohamed and Adiel, and am also addressing Russ Mundy’s observations on the RFP.
First, an easy issue: nothing in the language referring to the IANA contract implies that anyone is “bound” by anything. It simply uses the current IANA contract as a uniform point of reference. Let me reproduce the language here:
“In the interest of consistency, each community is encouraged to review and consider the current IANA Functions Contract between NTIA and ICANN when describing existing arrangements and proposing changes to existing arrangements.”
I think that is clearly just asking for a consistent point of reference and we can dispose of this “don’t bind the operational communities” issue completely.
The more difficult issue concerns the leading role of the operational communities and the possibility of multiple submissions. This problem challenges the concept that the ICG is a “non-decisional” body. If we decide who can and cannot submit proposals, we are in fact making a critical substantive decision, one that profoundly influences the nature of the proposals. On the other hand, if we allow or encourage proposals by anyone and everyone who feels like submitting one, we are put into the position of selecting among them and even modifying/reassembling them.
So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected.
I actually think the current draft finds the appropriate middle ground between this Scylla and Charybdis. It strongly encourages everyone to work together in an operational community-led process, but does not expressly prohibit other proposals. Here is the language:
During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups.
Only change I would suggest is that we change “expected” to “required” in the first line.
To Mohamed, I would say that the operational communities HAVE TO be considered the primary stakeholders in the transition, because they are the people who rely on the IANA functions in a direct, operational sense and its functionality and responsiveness is a life or death matter for them. --MM
From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Martin Boyle Sent: Friday, August 15, 2014 11:28 AM To: Mohamed El Bashir; internal-cg@icann.org Internal Subject: Re: [Internal-cg] Revised RFP
Hi All,
Mohamed beat me to it, so I have applied the amendments/comments I was working on on top of his and posted back in dropbox.
I’d like to make a couple of explanatory notes, though:
1. There seems to be a tendency to widen the number of fronts: I am concerned that, if we open to all stakeholder communities, we are essentially bypassing the focus on the three functions as centres of thinking. The more I have thought about this, the more I see little value for any community NOT to submit its own proposal(s) whereas we really need the different groups to work with all affected stakeholders on their bit of the puzzle. I thought (really believed) that were working on the operational lead approach expecting each to adopt its own process with its affected parties and other stakeholders. I hope that we can keep to this approach.
2. I’ve noted in a previous mail on this document that there are a number of ccTLDs who do not (and will not) engage with ICANN. I’m happy for us not to encourage individual or small-group submissions, but we have to understand that there is a high probability that we will get input, so there is no point in trying to discourage them. But we do need to think about how this might be dealt with and pose our questions to the wider community in a different form. One way might be to offer a “fast track” approach to identify specific problems or requirements that they feel need to be addressed.
3. I was left puzzled by references to an input from Daniel which I was not able to find. I have commented on this paragraph somewhat in the dark (apologies if I’ve missed the point), but it does seem to me to be important for us to use the current NTIA/ICANN as the current basis. This is then reflected in a couple of comments in the last section, on maintaining the framework for service delivery and on the clear separation of policy responsibility from the IANA.
By the way, is it v0.7 (as in the file title) or v0.6 (as in the document)?
Thanks
Martin
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
I see your point Paul and agree that "as many iterations as we can" is too much to ask within the tight timeframe we have but, to the extent possible, even one more shorter public comment period may help us resolve issues and increase consensus .. Anyway, if this won't be feasible then I support the approach you suggested below, and agree that it's early to guarantee since we have no idea how many proposals we will receive .. Kind Regards --Manal -----Original Message----- From: Paul Wilson [mailto:pwilson@apnic.net] Sent: Monday, August 18, 2014 2:05 AM To: Manal Ismail; James M. Bladel Cc: Milton L Mueller; ICG Subject: Re: [Internal-cg] Revised RFP
Dear All ..
I still have to go through the latest version of the RFP but would like to make a few remarks in light of this thread of discussion: - Like Mohamed, Adiel and maybe others, I hope we can encourage and convince the community with the importance and benefits of early discussions and consolidated submissions without setting a hard limit of 3 or 4 proposals; which I believe is somehow reflected in the sentence referenced in Milton's email below .. I also support changing "expected" to "required" as suggested by Milton .. - Similar to what Martin said regarding ccTLDs who do not engage with ICANN, there may be also governments who do not engage with ICANN and still want to submit their views .. Moreover there may be governments who already engage with ICANN and would still like to put their proposals on record .. I'm not saying this should be encouraged but saying we cannot but accept such submissions .. - The above suggestions do not diminish the importance of the 3/4 proposals of the operational communities .. I do apologize if the above points have already been addressed and settled ..
I agree with Manal's 3 points above.
Furthermore, I believe it's important to discuss Milton's below
statement which summarizes the situation perfectly well .. I believe ICG should not "make a decision limiting who can submit" (rather encourage and convince) .. On the other hand ICG should, to the extent possible, avoid making "a decision about which proposals are selected" as it already has a limited role of integrating and consolidating all inputs into one proposal .. Accordingly, in case of conflicting views, selections may be settled either by how broadly a proposal is supported or preferably by reverting back to the (relevant) communities to make the choice .. In all cases, in a perfect situation, we should work on allowing iterations of public comment periods (as many as needed and as time allows) to fine tune the final proposal, make selections whenever necessary and ensure broadest community support .. Agreed regarding the theoretical perfect situation, but we cannot rely on the communities to grant us this luxury. I believe we will inevitably need to make judgements/decisions at some level (as James said), and the difficult of doing that will depend on the specifics. On submissions, I think we cannot rule out anyone in advance; we can only strongly direct people to community processes. Can we draw a clear distinction between the sources of proposals: for instance while we will work to fully reconcile the community proposals, we will consider other proposals and make best efforts to incorporate them, and attempt to note where this has not been possible (and all will go on the public record of course). We should probably also note that we will work within the target timeframes established, and make our best efforts to fully consider all inputs received. It is not possible to guarantee this when we have no idea how many proposals we will see. Paul.
Kind Regards --Manal
From: internal-cg-bounces@icann.org
[mailto:internal-cg-bounces@icann.org] On Behalf Of James M. Bladel
Sent: Friday, August 15, 2014 7:51 PM To: Milton L Mueller; internal-cg@icann.org Internal Subject: Re: [Internal-cg] Revised RFP
Interesting points, Milton. Especially with regard to:
"So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected."
Personally I do not believe the ICG can totally insulate itself from making material decisions (or "choices") on the proposals, regardless of the path chosen. Even if submissions are limited to the smallest possible number, there are bound to be minor differences between them that require some degree of reconciliation by the ICG.
Thanks-
J.
From: Milton L Mueller <mueller@syr.edu> Date: Friday, August 15, 2014 at 11:38 To: ICG List <internal-cg@icann.org> Subject: Re: [Internal-cg] Revised RFP
I've reviewed v 0.7 with comments of Martin, Mohamed and Adiel, and am also addressing Russ Mundy's observations on the RFP.
First, an easy issue: nothing in the language referring to the IANA contract implies that anyone is "bound" by anything. It simply uses the current IANA contract as a uniform point of reference. Let me reproduce the language here:
"In the interest of consistency, each community is encouraged to review and consider the current IANA Functions Contract between NTIA and ICANN when describing existing arrangements and proposing changes to existing arrangements."
I think that is clearly just asking for a consistent point of reference and we can dispose of this "don't bind the operational communities" issue completely.
The more difficult issue concerns the leading role of the operational communities and the possibility of multiple submissions. This problem challenges the concept that the ICG is a "non-decisional" body. If we decide who can and cannot submit proposals, we are in fact making a critical substantive decision, one that profoundly influences the nature of the proposals. On the other hand, if we allow or encourage proposals by anyone and everyone who feels like submitting one, we are put into the position of selecting among them and even modifying/reassembling them.
So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected.
I actually think the current draft finds the appropriate middle ground between this Scylla and Charybdis. It strongly encourages everyone to work together in an operational community-led process, but does not expressly prohibit other proposals. Here is the language:
During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups.
Only change I would suggest is that we change "expected" to "required" in the first line.
To Mohamed, I would say that the operational communities HAVE TO be considered the primary stakeholders in the transition, because they are the people who rely on the IANA functions in a direct, operational sense and its functionality and responsiveness is a life or death matter for them. --MM
From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Martin Boyle Sent: Friday, August 15, 2014 11:28 AM To: Mohamed El Bashir; internal-cg@icann.org Internal Subject: Re: [Internal-cg] Revised RFP
Hi All,
Mohamed beat me to it, so I have applied the amendments/comments I was working on on top of his and posted back in dropbox.
I'd like to make a couple of explanatory notes, though:
1. There seems to be a tendency to widen the number of fronts: I am concerned that, if we open to all stakeholder communities, we are essentially bypassing the focus on the three functions as centres of thinking. The more I have thought about this, the more I see little value for any community NOT to submit its own proposal(s) whereas we really need the different groups to work with all affected stakeholders on their bit of the puzzle. I thought (really believed) that were working on the operational lead approach expecting each to adopt its own process with its affected parties and other stakeholders. I hope that we can keep to this approach.
2. I've noted in a previous mail on this document that there are a number of ccTLDs who do not (and will not) engage with ICANN. I'm happy for us not to encourage individual or small-group submissions, but we have to understand that there is a high probability that we will get input, so there is no point in trying to discourage them. But we do need to think about how this might be dealt with and pose our questions to the wider community in a different form. One way might be to offer a "fast track" approach to identify specific problems or requirements that they feel need to be addressed.
3. I was left puzzled by references to an input from Daniel which I was not able to find. I have commented on this paragraph somewhat in the dark (apologies if I've missed the point), but it does seem to me to be important for us to use the current NTIA/ICANN as the current basis. This is then reflected in a couple of comments in the last section, on maintaining the framework for service delivery and on the clear separation of policy responsibility from the IANA.
By the way, is it v0.7 (as in the file title) or v0.6 (as in the document)?
Thanks
Martin
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Agree with Manal's position. Jean-Jacques. ----- Mail original ----- De: "Manal Ismail" <manal@tra.gov.eg> À: "Paul Wilson" <pwilson@apnic.net>, "James M. Bladel" <jbladel@godaddy.com> Cc: "ICG" <internal-cg@icann.org> Envoyé: Lundi 18 Août 2014 01:39:57 Objet: Re: [Internal-cg] Revised RFP I see your point Paul and agree that "as many iterations as we can" is too much to ask within the tight timeframe we have but, to the extent possible, even one more shorter public comment period may help us resolve issues and increase consensus .. Anyway, if this won't be feasible then I support the approach you suggested below, and agree that it's early to guarantee since we have no idea how many proposals we will receive .. Kind Regards --Manal -----Original Message----- From: Paul Wilson [mailto:pwilson@apnic.net] Sent: Monday, August 18, 2014 2:05 AM To: Manal Ismail; James M. Bladel Cc: Milton L Mueller; ICG Subject: Re: [Internal-cg] Revised RFP
Dear All ..
I still have to go through the latest version of the RFP but would like to make a few remarks in light of this thread of discussion: - Like Mohamed, Adiel and maybe others, I hope we can encourage and convince the community with the importance and benefits of early discussions and consolidated submissions without setting a hard limit of 3 or 4 proposals; which I believe is somehow reflected in the sentence referenced in Milton's email below .. I also support changing "expected" to "required" as suggested by Milton .. - Similar to what Martin said regarding ccTLDs who do not engage with ICANN, there may be also governments who do not engage with ICANN and still want to submit their views .. Moreover there may be governments who already engage with ICANN and would still like to put their proposals on record .. I'm not saying this should be encouraged but saying we cannot but accept such submissions .. - The above suggestions do not diminish the importance of the 3/4 proposals of the operational communities .. I do apologize if the above points have already been addressed and settled ..
I agree with Manal's 3 points above.
Furthermore, I believe it's important to discuss Milton's below
statement which summarizes the situation perfectly well .. I believe ICG should not "make a decision limiting who can submit" (rather encourage and convince) .. On the other hand ICG should, to the extent possible, avoid making "a decision about which proposals are selected" as it already has a limited role of integrating and consolidating all inputs into one proposal .. Accordingly, in case of conflicting views, selections may be settled either by how broadly a proposal is supported or preferably by reverting back to the (relevant) communities to make the choice .. In all cases, in a perfect situation, we should work on allowing iterations of public comment periods (as many as needed and as time allows) to fine tune the final proposal, make selections whenever necessary and ensure broadest community support .. Agreed regarding the theoretical perfect situation, but we cannot rely on the communities to grant us this luxury. I believe we will inevitably need to make judgements/decisions at some level (as James said), and the difficult of doing that will depend on the specifics. On submissions, I think we cannot rule out anyone in advance; we can only strongly direct people to community processes. Can we draw a clear distinction between the sources of proposals: for instance while we will work to fully reconcile the community proposals, we will consider other proposals and make best efforts to incorporate them, and attempt to note where this has not been possible (and all will go on the public record of course). We should probably also note that we will work within the target timeframes established, and make our best efforts to fully consider all inputs received. It is not possible to guarantee this when we have no idea how many proposals we will see. Paul.
Kind Regards --Manal
From: internal-cg-bounces@icann.org
[mailto:internal-cg-bounces@icann.org] On Behalf Of James M. Bladel
Sent: Friday, August 15, 2014 7:51 PM To: Milton L Mueller; internal-cg@icann.org Internal Subject: Re: [Internal-cg] Revised RFP
Interesting points, Milton. Especially with regard to:
"So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected."
Personally I do not believe the ICG can totally insulate itself from making material decisions (or "choices") on the proposals, regardless of the path chosen. Even if submissions are limited to the smallest possible number, there are bound to be minor differences between them that require some degree of reconciliation by the ICG.
Thanks-
J.
From: Milton L Mueller <mueller@syr.edu> Date: Friday, August 15, 2014 at 11:38 To: ICG List <internal-cg@icann.org> Subject: Re: [Internal-cg] Revised RFP
I've reviewed v 0.7 with comments of Martin, Mohamed and Adiel, and am also addressing Russ Mundy's observations on the RFP.
First, an easy issue: nothing in the language referring to the IANA contract implies that anyone is "bound" by anything. It simply uses the current IANA contract as a uniform point of reference. Let me reproduce the language here:
"In the interest of consistency, each community is encouraged to review and consider the current IANA Functions Contract between NTIA and ICANN when describing existing arrangements and proposing changes to existing arrangements."
I think that is clearly just asking for a consistent point of reference and we can dispose of this "don't bind the operational communities" issue completely.
The more difficult issue concerns the leading role of the operational communities and the possibility of multiple submissions. This problem challenges the concept that the ICG is a "non-decisional" body. If we decide who can and cannot submit proposals, we are in fact making a critical substantive decision, one that profoundly influences the nature of the proposals. On the other hand, if we allow or encourage proposals by anyone and everyone who feels like submitting one, we are put into the position of selecting among them and even modifying/reassembling them.
So, take your pick: make a decision limiting who can submit, or make a decision about which proposals are selected.
I actually think the current draft finds the appropriate middle ground between this Scylla and Charybdis. It strongly encourages everyone to work together in an operational community-led process, but does not expressly prohibit other proposals. Here is the language:
During the development of their proposals, the operational communities are expected to consult and work with other affected parties; likewise, other affected parties are strongly encouraged to participate in community processes, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups.
Only change I would suggest is that we change "expected" to "required" in the first line.
To Mohamed, I would say that the operational communities HAVE TO be considered the primary stakeholders in the transition, because they are the people who rely on the IANA functions in a direct, operational sense and its functionality and responsiveness is a life or death matter for them. --MM
From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Martin Boyle Sent: Friday, August 15, 2014 11:28 AM To: Mohamed El Bashir; internal-cg@icann.org Internal Subject: Re: [Internal-cg] Revised RFP
Hi All,
Mohamed beat me to it, so I have applied the amendments/comments I was working on on top of his and posted back in dropbox.
I'd like to make a couple of explanatory notes, though:
1. There seems to be a tendency to widen the number of fronts: I am concerned that, if we open to all stakeholder communities, we are essentially bypassing the focus on the three functions as centres of thinking. The more I have thought about this, the more I see little value for any community NOT to submit its own proposal(s) whereas we really need the different groups to work with all affected stakeholders on their bit of the puzzle. I thought (really believed) that were working on the operational lead approach expecting each to adopt its own process with its affected parties and other stakeholders. I hope that we can keep to this approach.
2. I've noted in a previous mail on this document that there are a number of ccTLDs who do not (and will not) engage with ICANN. I'm happy for us not to encourage individual or small-group submissions, but we have to understand that there is a high probability that we will get input, so there is no point in trying to discourage them. But we do need to think about how this might be dealt with and pose our questions to the wider community in a different form. One way might be to offer a "fast track" approach to identify specific problems or requirements that they feel need to be addressed.
3. I was left puzzled by references to an input from Daniel which I was not able to find. I have commented on this paragraph somewhat in the dark (apologies if I've missed the point), but it does seem to me to be important for us to use the current NTIA/ICANN as the current basis. This is then reflected in a couple of comments in the last section, on maintaining the framework for service delivery and on the clear separation of policy responsibility from the IANA.
By the way, is it v0.7 (as in the file title) or v0.6 (as in the document)?
Thanks
Martin
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
participants (8)
-
Drazek, Keith -
James M. Bladel -
Manal Ismail -
Martin Boyle -
Milton L Mueller -
Mohamed El Bashir -
Paul Wilson -
Subrenat, Jean-Jacques