How many proposals? and ccTLDs/gTLDs
Over in the thread about the communities RFP [1], some of us have been discussing how many proposals the ICG should request and expect. We also discussed this in London. My feeling is that as far as full community proposals — i.e., documents that contain all five sections of the latest RFP proposal [2], fully completed — we should be open to receiving either 3 proposals (names, numbers, protocol parameters) or 4 proposals (gTLDs, ccTLDs, numbers, protocol parameters).
From all the discussions I’ve had with ccTLD folks, it seems as though both their current arrangements and what they may potentially propose for post-transition arrangements could differ from what gets proposed for gTLDs (although not necessarily in incompatible ways). I think we should be open to this possibility. Of course, we would expect the ccTLD community and the gTLD community to work together to try to align themselves on areas of overlap, in the same way that we expect all of the other communities to do so. And our preference would still be for 3 proposals rather than 4.
Saying that we should be open to accepting 3 or 4 full proposals is *not* the same as saying we should be open to receiving 10 or 20, where any stakeholder can submit a full proposal. I don’t think this would be productive, and I don’t know what we as the ICG would do with proposals that do not come from the operational communities. Of course, we want individual stakeholders to be able to provide input and feedback, and I think we’ve done a good job of outlining our expectations as far as how that will work in the charter. But soliciting input is different from soliciting a full proposal for any of the functions — those should come from the operational communities. This leaves the case Milton has pointed out, where an operational community splits into two or three groups that produce separate proposals for the same function. Again, this is not ideal, and I think we should set the expectation that we want to receive at most 1 proposal from each operational community (with the caveat above about ccTLDs vs. gTLDs). If it turns out that we get two or three proposals for the same function from different factions of the same community, we’ll have to deal with that then (I don’t know how), but the expectation we should set from the outset is for uniformity within each community. One way to smooth over the potential faction problem would be to build on one of the requirements we already have in the RFP (Section V), which is for the communities to provide an assessment of the consensus level and a description of areas of contention or disagreement. If a particular community develops a minority faction with a counter-proposal to what the rest of the community proposes, it could be documented there (and we would probably want to elaborate that better in the RFP). But I think this would only work if the counter-proposal could be viewed as a minority opinion, and I’m not sure if that’s a plausible scenario for any of the communities. Thoughts? I mostly want to jump start this discussion among the names folks, as I expect it to be fairly straightforward the protocol parameters community to produce a single proposal, and the same for numbers. Thanks, Alissa [1] http://mm.icann.org/pipermail/internal-cg/2014-August/000869.html [2] https://www.dropbox.com/s/ztrzblyax0540m5/IANA%20Transition%20RFP%20v07%20%2 8ALC-MM%29.docx
I have spent quite some time thinking about these issues while working on the description of IANA that SSAC has created that you will see shortly. In reality the IANA functions include many different things, and not only three or four. That said, one can quite easily divide the things in three (or four) categories although exactly where the border is between them depends who is drawing the lines. This is a complicating factor that might trigger multiple proposals coming in for the same function, although those reasons I think are easy to resolve. So, what do I think? I think I agree with you Alissa that we stay with "three categories", names, numbers and protocol parameters. But as each one of them can be viewed as containing more than one sub category of "things", we MIGHT have to look at each sub category independent from the others. ccTLD/gTLD is just one example. Because whether there are subcategories or not might even be part of the suggestion itself we get, I even think it is wrong by us forcing the subcategories to be "invisible". But this also explains why I also agree with Alissa why 20 or 50 different proposals is wrong (ccTLDs in Asian region should not be a different subcategory from ccTLDs in Europe). Suggestion: We do request proposals from the three main categories of tasks, names, numbers or protocol parameters. If the proposal and/or area is designed such that the category is to be divided in sub categories (like gTLDs and ccTLDs), that is acceptable although clarifications how the subcategories are related (and not) to each other should be explained. Patrik On 14 aug 2014, at 02:53, Alissa Cooper <alissa@cooperw.in> wrote:
Over in the thread about the communities RFP [1], some of us have been discussing how many proposals the ICG should request and expect. We also discussed this in London.
My feeling is that as far as full community proposals — i.e., documents that contain all five sections of the latest RFP proposal [2], fully completed — we should be open to receiving either 3 proposals (names, numbers, protocol parameters) or 4 proposals (gTLDs, ccTLDs, numbers, protocol parameters). From all the discussions I’ve had with ccTLD folks, it seems as though both their current arrangements and what they may potentially propose for post-transition arrangements could differ from what gets proposed for gTLDs (although not necessarily in incompatible ways). I think we should be open to this possibility. Of course, we would expect the ccTLD community and the gTLD community to work together to try to align themselves on areas of overlap, in the same way that we expect all of the other communities to do so. And our preference would still be for 3 proposals rather than 4.
Saying that we should be open to accepting 3 or 4 full proposals is *not* the same as saying we should be open to receiving 10 or 20, where any stakeholder can submit a full proposal. I don’t think this would be productive, and I don’t know what we as the ICG would do with proposals that do not come from the operational communities. Of course, we want individual stakeholders to be able to provide input and feedback, and I think we’ve done a good job of outlining our expectations as far as how that will work in the charter. But soliciting input is different from soliciting a full proposal for any of the functions — those should come from the operational communities.
This leaves the case Milton has pointed out, where an operational community splits into two or three groups that produce separate proposals for the same function. Again, this is not ideal, and I think we should set the expectation that we want to receive at most 1 proposal from each operational community (with the caveat above about ccTLDs vs. gTLDs). If it turns out that we get two or three proposals for the same function from different factions of the same community, we’ll have to deal with that then (I don’t know how), but the expectation we should set from the outset is for uniformity within each community.
One way to smooth over the potential faction problem would be to build on one of the requirements we already have in the RFP (Section V), which is for the communities to provide an assessment of the consensus level and a description of areas of contention or disagreement. If a particular community develops a minority faction with a counter-proposal to what the rest of the community proposes, it could be documented there (and we would probably want to elaborate that better in the RFP). But I think this would only work if the counter-proposal could be viewed as a minority opinion, and I’m not sure if that’s a plausible scenario for any of the communities.
Thoughts? I mostly want to jump start this discussion among the names folks, as I expect it to be fairly straightforward the protocol parameters community to produce a single proposal, and the same for numbers.
Thanks, Alissa
[1] http://mm.icann.org/pipermail/internal-cg/2014-August/000869.html [2] https://www.dropbox.com/s/ztrzblyax0540m5/IANA%20Transition%20RFP%20v07%20%2... _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Hi all, I generally agree that we should discourage multiple submissions but asking communities to work together on shared proposals. In this light I would note that the ccNSO is working with the GNSO in the development of a cross-community working group to prepare a common position. However, there are significant differences between ccTLDs and gTLDs and I would agree with Patrik that we should not "[force] the subcategories to be "invisible"." If we do, people will assume that we do not properly appreciate the complexity of the issues and we will lose credibility in their eyes. I'd like to throw in an additional dimension, though: there is a significant number of ccTLDs who are not members of the ccNSO. Non-members include India, Pakistan, Bangladesh, Ghana, Angola, Hungary & Denmark, for example. Some of these non-ccNSO ccTLDs do not and will not interact with ICANN (because of national sovereignty issues or because they do not accept ICANN as having any policy authority) and we can expect them to want to put in their views. (The ccNSO has assembled a mailing list to keep these registries informed and the regional ccTLD organisations could also provide a route to engage.) It would be good to suggest that they work together on this, but we might see individual input. Best Martin From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Patrik Fältström Sent: 14 August 2014 05:26 To: Alissa Cooper Cc: ICG Subject: Re: [Internal-cg] How many proposals? and ccTLDs/gTLDs I have spent quite some time thinking about these issues while working on the description of IANA that SSAC has created that you will see shortly. In reality the IANA functions include many different things, and not only three or four. That said, one can quite easily divide the things in three (or four) categories although exactly where the border is between them depends who is drawing the lines. This is a complicating factor that might trigger multiple proposals coming in for the same function, although those reasons I think are easy to resolve. So, what do I think? I think I agree with you Alissa that we stay with "three categories", names, numbers and protocol parameters. But as each one of them can be viewed as containing more than one sub category of "things", we MIGHT have to look at each sub category independent from the others. ccTLD/gTLD is just one example. Because whether there are subcategories or not might even be part of the suggestion itself we get, I even think it is wrong by us forcing the subcategories to be "invisible". But this also explains why I also agree with Alissa why 20 or 50 different proposals is wrong (ccTLDs in Asian region should not be a different subcategory from ccTLDs in Europe). Suggestion: We do request proposals from the three main categories of tasks, names, numbers or protocol parameters. If the proposal and/or area is designed such that the category is to be divided in sub categories (like gTLDs and ccTLDs), that is acceptable although clarifications how the subcategories are related (and not) to each other should be explained. Patrik On 14 aug 2014, at 02:53, Alissa Cooper <alissa@cooperw.in<mailto:alissa@cooperw.in>> wrote: Over in the thread about the communities RFP [1], some of us have been discussing how many proposals the ICG should request and expect. We also discussed this in London. My feeling is that as far as full community proposals - i.e., documents that contain all five sections of the latest RFP proposal [2], fully completed - we should be open to receiving either 3 proposals (names, numbers, protocol parameters) or 4 proposals (gTLDs, ccTLDs, numbers, protocol parameters). From all the discussions I've had with ccTLD folks, it seems as though both their current arrangements and what they may potentially propose for post-transition arrangements could differ from what gets proposed for gTLDs (although not necessarily in incompatible ways). I think we should be open to this possibility. Of course, we would expect the ccTLD community and the gTLD community to work together to try to align themselves on areas of overlap, in the same way that we expect all of the other communities to do so. And our preference would still be for 3 proposals rather than 4. Saying that we should be open to accepting 3 or 4 full proposals is *not* the same as saying we should be open to receiving 10 or 20, where any stakeholder can submit a full proposal. I don't think this would be productive, and I don't know what we as the ICG would do with proposals that do not come from the operational communities. Of course, we want individual stakeholders to be able to provide input and feedback, and I think we've done a good job of outlining our expectations as far as how that will work in the charter. But soliciting input is different from soliciting a full proposal for any of the functions - those should come from the operational communities. This leaves the case Milton has pointed out, where an operational community splits into two or three groups that produce separate proposals for the same function. Again, this is not ideal, and I think we should set the expectation that we want to receive at most 1 proposal from each operational community (with the caveat above about ccTLDs vs. gTLDs). If it turns out that we get two or three proposals for the same function from different factions of the same community, we'll have to deal with that then (I don't know how), but the expectation we should set from the outset is for uniformity within each community. One way to smooth over the potential faction problem would be to build on one of the requirements we already have in the RFP (Section V), which is for the communities to provide an assessment of the consensus level and a description of areas of contention or disagreement. If a particular community develops a minority faction with a counter-proposal to what the rest of the community proposes, it could be documented there (and we would probably want to elaborate that better in the RFP). But I think this would only work if the counter-proposal could be viewed as a minority opinion, and I'm not sure if that's a plausible scenario for any of the communities. Thoughts? I mostly want to jump start this discussion among the names folks, as I expect it to be fairly straightforward the protocol parameters community to produce a single proposal, and the same for numbers. Thanks, Alissa [1] http://mm.icann.org/pipermail/internal-cg/2014-August/000869.html [2] https://www.dropbox.com/s/ztrzblyax0540m5/IANA%20Transition%20RFP%20v07%20%2... _______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
I like Alissa and Patrik's approach, and favor working towards 3 or 4 proposals. As Alissa pointed out, if we do get more sub-groups submitting proposals, I believe the requirements in Section V of the RFP, where we ask the communities to provide an assessment of the consensus and a description of areas of contention, will be critical to managing this. Lynn On Aug 14, 2014, at 12:25 AM, Patrik Fältström <paf@frobbit.se> wrote: <snip>
Suggestion:
We do request proposals from the three main categories of tasks, names, numbers or protocol parameters. If the proposal and/or area is designed such that the category is to be divided in sub categories (like gTLDs and ccTLDs), that is acceptable although clarifications how the subcategories are related (and not) to each other should be explained.
Patrik
On 14 aug 2014, at 02:53, Alissa Cooper <alissa@cooperw.in> wrote:
Over in the thread about the communities RFP [1], some of us have been discussing how many proposals the ICG should request and expect. We also discussed this in London.
My feeling is that as far as full community proposals — i.e., documents that contain all five sections of the latest RFP proposal [2], fully completed — we should be open to receiving either 3 proposals (names, numbers, protocol parameters) or 4 proposals (gTLDs, ccTLDs, numbers, protocol parameters). From all the discussions I’ve had with ccTLD folks, it seems as though both their current arrangements and what they may potentially propose for post-transition arrangements could differ from what gets proposed for gTLDs (although not necessarily in incompatible ways). I think we should be open to this possibility. Of course, we would expect the ccTLD community and the gTLD community to work together to try to align themselves on areas of overlap, in the same way that we expect all of the other communities to do so. And our preference would still be for 3 proposals rather than 4.
Saying that we should be open to accepting 3 or 4 full proposals is *not* the same as saying we should be open to receiving 10 or 20, where any stakeholder can submit a full proposal. I don’t think this would be productive, and I don’t know what we as the ICG would do with proposals that do not come from the operational communities. Of course, we want individual stakeholders to be able to provide input and feedback, and I think we’ve done a good job of outlining our expectations as far as how that will work in the charter. But soliciting input is different from soliciting a full proposal for any of the functions — those should come from the operational communities.
This leaves the case Milton has pointed out, where an operational community splits into two or three groups that produce separate proposals for the same function. Again, this is not ideal, and I think we should set the expectation that we want to receive at most 1 proposal from each operational community (with the caveat above about ccTLDs vs. gTLDs). If it turns out that we get two or three proposals for the same function from different factions of the same community, we’ll have to deal with that then (I don’t know how), but the expectation we should set from the outset is for uniformity within each community.
One way to smooth over the potential faction problem would be to build on one of the requirements we already have in the RFP (Section V), which is for the communities to provide an assessment of the consensus level and a description of areas of contention or disagreement. If a particular community develops a minority faction with a counter-proposal to what the rest of the community proposes, it could be documented there (and we would probably want to elaborate that better in the RFP). But I think this would only work if the counter-proposal could be viewed as a minority opinion, and I’m not sure if that’s a plausible scenario for any of the communities.
Thoughts? I mostly want to jump start this discussion among the names folks, as I expect it to be fairly straightforward the protocol parameters community to produce a single proposal, and the same for numbers.
Thanks, Alissa
[1] http://mm.icann.org/pipermail/internal-cg/2014-August/000869.html [2] https://www.dropbox.com/s/ztrzblyax0540m5/IANA%20Transition%20RFP%20v07%20%2... _______________________________________________ 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
In the current version, where we have the communities check boxes, I think our reference to the non-customer communities is confusing. We welcome comments of all on all of our documents, like our RFP and concepts of what should be in a proposal, but are we asking non-customer stakeholders to provide proposals? I think proposal suggestions/comments of non-customer stakeholder communities would be most relevant as part of the proposal development process or on the proposals once submitted? The check boxes look like we are asking for non-customer communities to submit proposals? I would certainly encourage them to submit comments on the RFP if we have missing elements and on community proposals either in their development or to us once they are received. I have tried to download the latest version of the document to provide some edits, but I get read error messages after download, has anyone else had that problem? Joe On 8/17/2014 9:32 PM, Lynn St.Amour wrote:
I like Alissa and Patrik's approach, and favor working towards 3 or 4 proposals.
As Alissa pointed out, if we do get more sub-groups submitting proposals, I believe the requirements in Section V of the RFP, where we ask the communities to provide an assessment of the consensus and a description of areas of contention, will be critical to managing this.
Lynn
On Aug 14, 2014, at 12:25 AM, Patrik Fältström <paf@frobbit.se> wrote:
<snip>
Suggestion:
We do request proposals from the three main categories of tasks, names, numbers or protocol parameters. If the proposal and/or area is designed such that the category is to be divided in sub categories (like gTLDs and ccTLDs), that is acceptable although clarifications how the subcategories are related (and not) to each other should be explained.
Patrik
On 14 aug 2014, at 02:53, Alissa Cooper <alissa@cooperw.in> wrote:
Over in the thread about the communities RFP [1], some of us have been discussing how many proposals the ICG should request and expect. We also discussed this in London.
My feeling is that as far as full community proposals — i.e., documents that contain all five sections of the latest RFP proposal [2], fully completed — we should be open to receiving either 3 proposals (names, numbers, protocol parameters) or 4 proposals (gTLDs, ccTLDs, numbers, protocol parameters). From all the discussions I’ve had with ccTLD folks, it seems as though both their current arrangements and what they may potentially propose for post-transition arrangements could differ from what gets proposed for gTLDs (although not necessarily in incompatible ways). I think we should be open to this possibility. Of course, we would expect the ccTLD community and the gTLD community to work together to try to align themselves on areas of overlap, in the same way that we expect all of the other communities to do so. And our preference would still be for 3 proposals rather than 4.
Saying that we should be open to accepting 3 or 4 full proposals is *not* the same as saying we should be open to receiving 10 or 20, where any stakeholder can submit a full proposal. I don’t think this would be productive, and I don’t know what we as the ICG would do with proposals that do not come from the operational communities. Of course, we want individual stakeholders to be able to provide input and feedback, and I think we’ve done a good job of outlining our expectations as far as how that will work in the charter. But soliciting input is different from soliciting a full proposal for any of the functions — those should come from the operational communities.
This leaves the case Milton has pointed out, where an operational community splits into two or three groups that produce separate proposals for the same function. Again, this is not ideal, and I think we should set the expectation that we want to receive at most 1 proposal from each operational community (with the caveat above about ccTLDs vs. gTLDs). If it turns out that we get two or three proposals for the same function from different factions of the same community, we’ll have to deal with that then (I don’t know how), but the expectation we should set from the outset is for uniformity within each community.
One way to smooth over the potential faction problem would be to build on one of the requirements we already have in the RFP (Section V), which is for the communities to provide an assessment of the consensus level and a description of areas of contention or disagreement. If a particular community develops a minority faction with a counter-proposal to what the rest of the community proposes, it could be documented there (and we would probably want to elaborate that better in the RFP). But I think this would only work if the counter-proposal could be viewed as a minority opinion, and I’m not sure if that’s a plausible scenario for any of the communities.
Thoughts? I mostly want to jump start this discussion among the names folks, as I expect it to be fairly straightforward the protocol parameters community to produce a single proposal, and the same for numbers.
Thanks, Alissa
[1] http://mm.icann.org/pipermail/internal-cg/2014-August/000869.html [2] https://www.dropbox.com/s/ztrzblyax0540m5/IANA%20Transition%20RFP%20v07%20%2... _______________________________________________ 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
Dear All, I agree with Joe We must be clear on what we asking for and know ,if any reply received from non customer communities, how we could treat them .We should be carefull not to creat any trap or any bottle neck for ourselves. By the I have not been able to have final version with revision mark BUT NOT COMMENTS ON THE MARGIN which we do not know how we should treat them Does someone have any information on what I am asking for Regards KAVOUSS 2014-08-18 6:18 GMT+02:00 joseph alhadeff <joseph.alhadeff@oracle.com>:
In the current version, where we have the communities check boxes, I think our reference to the non-customer communities is confusing. We welcome comments of all on all of our documents, like our RFP and concepts of what should be in a proposal, but are we asking non-customer stakeholders to provide proposals? I think proposal suggestions/comments of non-customer stakeholder communities would be most relevant as part of the proposal development process or on the proposals once submitted? The check boxes look like we are asking for non-customer communities to submit proposals? I would certainly encourage them to submit comments on the RFP if we have missing elements and on community proposals either in their development or to us once they are received.
I have tried to download the latest version of the document to provide some edits, but I get read error messages after download, has anyone else had that problem?
Joe
On 8/17/2014 9:32 PM, Lynn St.Amour wrote:
I like Alissa and Patrik's approach, and favor working towards 3 or 4 proposals.
As Alissa pointed out, if we do get more sub-groups submitting proposals, I believe the requirements in Section V of the RFP, where we ask the communities to provide an assessment of the consensus and a description of areas of contention, will be critical to managing this.
Lynn
On Aug 14, 2014, at 12:25 AM, Patrik Fältström <paf@frobbit.se> wrote:
<snip>
Suggestion:
We do request proposals from the three main categories of tasks, names, numbers or protocol parameters. If the proposal and/or area is designed such that the category is to be divided in sub categories (like gTLDs and ccTLDs), that is acceptable although clarifications how the subcategories are related (and not) to each other should be explained.
Patrik
On 14 aug 2014, at 02:53, Alissa Cooper <alissa@cooperw.in> wrote:
Over in the thread about the communities RFP [1], some of us have been
discussing how many proposals the ICG should request and expect. We also discussed this in London.
My feeling is that as far as full community proposals — i.e., documents that contain all five sections of the latest RFP proposal [2], fully completed — we should be open to receiving either 3 proposals (names, numbers, protocol parameters) or 4 proposals (gTLDs, ccTLDs, numbers, protocol parameters). From all the discussions I’ve had with ccTLD folks, it seems as though both their current arrangements and what they may potentially propose for post-transition arrangements could differ from what gets proposed for gTLDs (although not necessarily in incompatible ways). I think we should be open to this possibility. Of course, we would expect the ccTLD community and the gTLD community to work together to try to align themselves on areas of overlap, in the same way that we expect all of the other communities to do so. And our preference would still be for 3 proposals rather than 4.
Saying that we should be open to accepting 3 or 4 full proposals is *not* the same as saying we should be open to receiving 10 or 20, where any stakeholder can submit a full proposal. I don’t think this would be productive, and I don’t know what we as the ICG would do with proposals that do not come from the operational communities. Of course, we want individual stakeholders to be able to provide input and feedback, and I think we’ve done a good job of outlining our expectations as far as how that will work in the charter. But soliciting input is different from soliciting a full proposal for any of the functions — those should come from the operational communities.
This leaves the case Milton has pointed out, where an operational community splits into two or three groups that produce separate proposals for the same function. Again, this is not ideal, and I think we should set the expectation that we want to receive at most 1 proposal from each operational community (with the caveat above about ccTLDs vs. gTLDs). If it turns out that we get two or three proposals for the same function from different factions of the same community, we’ll have to deal with that then (I don’t know how), but the expectation we should set from the outset is for uniformity within each community.
One way to smooth over the potential faction problem would be to build on one of the requirements we already have in the RFP (Section V), which is for the communities to provide an assessment of the consensus level and a description of areas of contention or disagreement. If a particular community develops a minority faction with a counter-proposal to what the rest of the community proposes, it could be documented there (and we would probably want to elaborate that better in the RFP). But I think this would only work if the counter-proposal could be viewed as a minority opinion, and I’m not sure if that’s a plausible scenario for any of the communities.
Thoughts? I mostly want to jump start this discussion among the names folks, as I expect it to be fairly straightforward the protocol parameters community to produce a single proposal, and the same for numbers.
Thanks, Alissa
[1] http://mm.icann.org/pipermail/internal-cg/2014-August/000869.html [2] https://www.dropbox.com/s/ztrzblyax0540m5/IANA% 20Transition%20RFP%20v07%20%28ALC-MM%29.docx _______________________________________________ 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
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Fully agree with "As Alissa pointed out, if we do get more sub-groups submitting proposals, I believe the requirements in Section V of the RFP, where we ask the communities to provide an assessment of the consensus and a description of areas of contention, will be critical to managing this." Martin Sent from my iPhone
On 18 Aug 2014, at 04:10, "Lynn St.Amour" <Lynn@lstamour.org> wrote:
I like Alissa and Patrik's approach, and favor working towards 3 or 4 proposals.
As Alissa pointed out, if we do get more sub-groups submitting proposals, I believe the requirements in Section V of the RFP, where we ask the communities to provide an assessment of the consensus and a description of areas of contention, will be critical to managing this.
Lynn
On Aug 14, 2014, at 12:25 AM, Patrik Fältström <paf@frobbit.se> wrote:
<snip>
Suggestion:
We do request proposals from the three main categories of tasks, names, numbers or protocol parameters. If the proposal and/or area is designed such that the category is to be divided in sub categories (like gTLDs and ccTLDs), that is acceptable although clarifications how the subcategories are related (and not) to each other should be explained.
Patrik
On 14 aug 2014, at 02:53, Alissa Cooper <alissa@cooperw.in> wrote:
Over in the thread about the communities RFP [1], some of us have been discussing how many proposals the ICG should request and expect. We also discussed this in London.
My feeling is that as far as full community proposals — i.e., documents that contain all five sections of the latest RFP proposal [2], fully completed — we should be open to receiving either 3 proposals (names, numbers, protocol parameters) or 4 proposals (gTLDs, ccTLDs, numbers, protocol parameters). From all the discussions I’ve had with ccTLD folks, it seems as though both their current arrangements and what they may potentially propose for post-transition arrangements could differ from what gets proposed for gTLDs (although not necessarily in incompatible ways). I think we should be open to this possibility. Of course, we would expect the ccTLD community and the gTLD community to work together to try to align themselves on areas of overlap, in the same way that we expect all of the other communities to do so. And our preference would still be for 3 proposals rather than 4.
Saying that we should be open to accepting 3 or 4 full proposals is *not* the same as saying we should be open to receiving 10 or 20, where any stakeholder can submit a full proposal. I don’t think this would be productive, and I don’t know what we as the ICG would do with proposals that do not come from the operational communities. Of course, we want individual stakeholders to be able to provide input and feedback, and I think we’ve done a good job of outlining our expectations as far as how that will work in the charter. But soliciting input is different from soliciting a full proposal for any of the functions — those should come from the operational communities.
This leaves the case Milton has pointed out, where an operational community splits into two or three groups that produce separate proposals for the same function. Again, this is not ideal, and I think we should set the expectation that we want to receive at most 1 proposal from each operational community (with the caveat above about ccTLDs vs. gTLDs). If it turns out that we get two or three proposals for the same function from different factions of the same community, we’ll have to deal with that then (I don’t know how), but the expectation we should set from the outset is for uniformity within each community.
One way to smooth over the potential faction problem would be to build on one of the requirements we already have in the RFP (Section V), which is for the communities to provide an assessment of the consensus level and a description of areas of contention or disagreement. If a particular community develops a minority faction with a counter-proposal to what the rest of the community proposes, it could be documented there (and we would probably want to elaborate that better in the RFP). But I think this would only work if the counter-proposal could be viewed as a minority opinion, and I’m not sure if that’s a plausible scenario for any of the communities.
Thoughts? I mostly want to jump start this discussion among the names folks, as I expect it to be fairly straightforward the protocol parameters community to produce a single proposal, and the same for numbers.
Thanks, Alissa
[1] http://mm.icann.org/pipermail/internal-cg/2014-August/000869.html [2] https://www.dropbox.com/s/ztrzblyax0540m5/IANA%20Transition%20RFP%20v07%20%2... _______________________________________________ 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
+1 to Lynn, Alissa and Patrik. On 18 Aug 2014, at 11:32 am, Lynn St.Amour <Lynn@LStAmour.org> wrote:
I like Alissa and Patrik's approach, and favor working towards 3 or 4 proposals.
As Alissa pointed out, if we do get more sub-groups submitting proposals, I believe the requirements in Section V of the RFP, where we ask the communities to provide an assessment of the consensus and a description of areas of contention, will be critical to managing this.
Lynn
On Aug 14, 2014, at 12:25 AM, Patrik Fältström <paf@frobbit.se> wrote:
<snip>
Suggestion:
We do request proposals from the three main categories of tasks, names, numbers or protocol parameters. If the proposal and/or area is designed such that the category is to be divided in sub categories (like gTLDs and ccTLDs), that is acceptable although clarifications how the subcategories are related (and not) to each other should be explained.
Patrik
On 14 aug 2014, at 02:53, Alissa Cooper <alissa@cooperw.in> wrote:
Over in the thread about the communities RFP [1], some of us have been discussing how many proposals the ICG should request and expect. We also discussed this in London.
My feeling is that as far as full community proposals — i.e., documents that contain all five sections of the latest RFP proposal [2], fully completed — we should be open to receiving either 3 proposals (names, numbers, protocol parameters) or 4 proposals (gTLDs, ccTLDs, numbers, protocol parameters). From all the discussions I’ve had with ccTLD folks, it seems as though both their current arrangements and what they may potentially propose for post-transition arrangements could differ from what gets proposed for gTLDs (although not necessarily in incompatible ways). I think we should be open to this possibility. Of course, we would expect the ccTLD community and the gTLD community to work together to try to align themselves on areas of overlap, in the same way that we expect all of the other communities to do so. And our preference would still be for 3 proposals rather than 4.
Saying that we should be open to accepting 3 or 4 full proposals is *not* the same as saying we should be open to receiving 10 or 20, where any stakeholder can submit a full proposal. I don’t think this would be productive, and I don’t know what we as the ICG would do with proposals that do not come from the operational communities. Of course, we want individual stakeholders to be able to provide input and feedback, and I think we’ve done a good job of outlining our expectations as far as how that will work in the charter. But soliciting input is different from soliciting a full proposal for any of the functions — those should come from the operational communities.
This leaves the case Milton has pointed out, where an operational community splits into two or three groups that produce separate proposals for the same function. Again, this is not ideal, and I think we should set the expectation that we want to receive at most 1 proposal from each operational community (with the caveat above about ccTLDs vs. gTLDs). If it turns out that we get two or three proposals for the same function from different factions of the same community, we’ll have to deal with that then (I don’t know how), but the expectation we should set from the outset is for uniformity within each community.
One way to smooth over the potential faction problem would be to build on one of the requirements we already have in the RFP (Section V), which is for the communities to provide an assessment of the consensus level and a description of areas of contention or disagreement. If a particular community develops a minority faction with a counter-proposal to what the rest of the community proposes, it could be documented there (and we would probably want to elaborate that better in the RFP). But I think this would only work if the counter-proposal could be viewed as a minority opinion, and I’m not sure if that’s a plausible scenario for any of the communities.
Thoughts? I mostly want to jump start this discussion among the names folks, as I expect it to be fairly straightforward the protocol parameters community to produce a single proposal, and the same for numbers.
Thanks, Alissa
[1] http://mm.icann.org/pipermail/internal-cg/2014-August/000869.html [2] https://www.dropbox.com/s/ztrzblyax0540m5/IANA%20Transition%20RFP%20v07%20%2... _______________________________________________ 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
participants (7)
-
Alissa Cooper -
joseph alhadeff -
Kavouss Arasteh -
Lynn St.Amour -
Martin Boyle -
Patrik Fältström -
Paul Wilson