I thought it would be useful to start discussion of some of the topics that the group needs to deal with. I’m sending you some thoughts on the timeline of events looking forward. This is a rough draft and for discussion purposes only. Please comment! — What is described below reads as one timeline, but it may be important to understand that we actually have multiple parallel efforts: protocol parameters, addresses, and names. These efforts have several points of linkage, but allowing parallel operation is probably a good idea. As a result, the timeline may run at slightly different speeds for the different parts. The NTIA has said that the September 2015 deadline is not firm, and that they could extend contracts and prolong the process beyond that. I do believe, however, that there are several reasons why getting done by then is at least useful if not even necessary. First of all, I think we all need a goal. And open-ended timelines lead to open-ended discussions. Second, people, administrations, political climate, etc. may change. So I think we should work towards September 30, 2015. But of course, we also want a good proposal to go forward. In thinking about what is needed before completion, I think see at least the following tasks: 1. Communities: Communities coming up with plans. 2. Coordination and alignment. This includes possible iteration and even going back to the communities. It also includes, possibly, some acceptance phase with the global community for the assembled plan. For instance, the assembled complete plan should probably be something that the customers of IANA are happy with. In other words, coordination can be lead by the coordination group, but it likely includes a lot of work also in the communities. 3. Test run. We may want to show off that the system can actually run in the proposed way for a while. 4. NTIA evaluation and approval process. The community processes are in my opinion the most important ones, and should involve most of the work. In addition, they tend to run for long times. For instance, the simplest IETF last call would be a month already. We also want to give time to the NTIA to do what they need to do. And we should not optimistically assume that there is no need to adjust and iterate over the initially submitted plans. Which may include some additional time confirming with various communities that changes are OK. I’m a little unclear how much testing/demonstration we need. Arguably, the IETF probably runs the system it needs already. But there are other parts where some re-organisation and re-thinking is needed. Not really clear to me how much confidence building would be needed for those parts. Does anyone have thoughts on this? In general, I think we should run this process as the much ourselves as possible, and have everything (including criteria fulfilment) very clearly spelled out for the NTIA, rather leaving any substantial work for them. But they’ll still need some time to process. And we might again need to come back and change something. I guess what I’m coming to is trying to get going pretty early, so that we can iterate in later stages. The tasks are obviously overlapping. For instance, the coordination group should do coordination from day 1, by understanding what the communities are doing and pointing out if they are going into conflicting directions or if there are parts that are not being addressed. So here is one possible overall timeline: Step 1: Communities' work - ready by Dec 30, 2014 (6 months) Step 2: Coordination and alignment, including iteration - ready by March 30, 2015 (+3 months) Step 3: Acceptance and communication - ready by May 30, 2015 (+2 months) Step 4: Testing - ready by July 30, 2015 (+ 2 months) Step 5: NTIA evaluation and acceptance - ready by September 30, 2015 (+2 months)
Colleagues: Perhaps the first step is a publication and comment on our operational processes, objectives and input methodology, including consultation mechanisms for those of us representing constituencies. That might give people some comfort in relation to the transparency of our own group's operation? This is likely implied in 1 and 2, but I think we should be more explicit. I understand that this may be more relevant to work other than our own, but issues of optics and comfort with the fairness, inclusiveness and transparency of the process have been huge issues as of late in IG discussions... Joe On 7/10/2014 1:00 PM, Jari Arkko wrote:
I thought it would be useful to start discussion of some of the topics that the group needs to deal with. I'm sending you some thoughts on the timeline of events looking forward. This is a rough draft and for discussion purposes only. Please comment!
---
What is described below reads as one timeline, but it may be important to understand that we actually have multiple parallel efforts: protocol parameters, addresses, and names. These efforts have several points of linkage, but allowing parallel operation is probably a good idea. As a result, the timeline may run at slightly different speeds for the different parts.
The NTIA has said that the September 2015 deadline is not firm, and that they could extend contracts and prolong the process beyond that. I do believe, however, that there are several reasons why getting done by then is at least useful if not even necessary. First of all, I think we all need a goal. And open-ended timelines lead to open-ended discussions. Second, people, administrations, political climate, etc. may change. So I think we should work towards September 30, 2015. But of course, we also want a good proposal to go forward.
In thinking about what is needed before completion, I think see at least the following tasks:
1. Communities: Communities coming up with plans.
2. Coordination and alignment. This includes possible iteration and even going back to the communities. It also includes, possibly, some acceptance phase with the global community for the assembled plan. For instance, the assembled complete plan should probably be something that the customers of IANA are happy with. In other words, coordination can be lead by the coordination group, but it likely includes a lot of work also in the communities.
3. Test run. We may want to show off that the system can actually run in the proposed way for a while.
4. NTIA evaluation and approval process.
The community processes are in my opinion the most important ones, and should involve most of the work. In addition, they tend to run for long times. For instance, the simplest IETF last call would be a month already. We also want to give time to the NTIA to do what they need to do. And we should not optimistically assume that there is no need to adjust and iterate over the initially submitted plans. Which may include some additional time confirming with various communities that changes are OK.
I'm a little unclear how much testing/demonstration we need. Arguably, the IETF probably runs the system it needs already. But there are other parts where some re-organisation and re-thinking is needed. Not really clear to me how much confidence building would be needed for those parts. Does anyone have thoughts on this?
In general, I think we should run this process as the much ourselves as possible, and have everything (including criteria fulfilment) very clearly spelled out for the NTIA, rather leaving any substantial work for them. But they'll still need some time to process. And we might again need to come back and change something.
I guess what I'm coming to is trying to get going pretty early, so that we can iterate in later stages.
The tasks are obviously overlapping. For instance, the coordination group should do coordination from day 1, by understanding what the communities are doing and pointing out if they are going into conflicting directions or if there are parts that are not being addressed.
So here is one possible overall timeline:
Step 1: Communities' work - ready by Dec 30, 2014 (6 months)
Step 2: Coordination and alignment, including iteration - ready by March 30, 2015 (+3 months)
Step 3: Acceptance and communication - ready by May 30, 2015 (+2 months)
Step 4: Testing - ready by July 30, 2015 (+ 2 months)
Step 5: NTIA evaluation and acceptance - ready by September 30, 2015 (+2 months)
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Thanks Joe. I think your suggestions are constructive and would help support predictability of process(es). Regards, Keith -------------------------------------------- Keith Drazek Vice President Public Policy & Government Relations Verisign, Inc. +1-571-377-9182 kdrazek@verisign.com<mailto:kdrazek@verisign.com> From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of joseph alhadeff Sent: Thursday, July 10, 2014 1:13 PM To: internal-cg@icann.org Subject: Re: [Internal-cg] Timeline Colleagues: Perhaps the first step is a publication and comment on our operational processes, objectives and input methodology, including consultation mechanisms for those of us representing constituencies. That might give people some comfort in relation to the transparency of our own group's operation? This is likely implied in 1 and 2, but I think we should be more explicit. I understand that this may be more relevant to work other than our own, but issues of optics and comfort with the fairness, inclusiveness and transparency of the process have been huge issues as of late in IG discussions... Joe On 7/10/2014 1:00 PM, Jari Arkko wrote: I thought it would be useful to start discussion of some of the topics that the group needs to deal with. I'm sending you some thoughts on the timeline of events looking forward. This is a rough draft and for discussion purposes only. Please comment! - What is described below reads as one timeline, but it may be important to understand that we actually have multiple parallel efforts: protocol parameters, addresses, and names. These efforts have several points of linkage, but allowing parallel operation is probably a good idea. As a result, the timeline may run at slightly different speeds for the different parts. The NTIA has said that the September 2015 deadline is not firm, and that they could extend contracts and prolong the process beyond that. I do believe, however, that there are several reasons why getting done by then is at least useful if not even necessary. First of all, I think we all need a goal. And open-ended timelines lead to open-ended discussions. Second, people, administrations, political climate, etc. may change. So I think we should work towards September 30, 2015. But of course, we also want a good proposal to go forward. In thinking about what is needed before completion, I think see at least the following tasks: 1. Communities: Communities coming up with plans. 2. Coordination and alignment. This includes possible iteration and even going back to the communities. It also includes, possibly, some acceptance phase with the global community for the assembled plan. For instance, the assembled complete plan should probably be something that the customers of IANA are happy with. In other words, coordination can be lead by the coordination group, but it likely includes a lot of work also in the communities. 3. Test run. We may want to show off that the system can actually run in the proposed way for a while. 4. NTIA evaluation and approval process. The community processes are in my opinion the most important ones, and should involve most of the work. In addition, they tend to run for long times. For instance, the simplest IETF last call would be a month already. We also want to give time to the NTIA to do what they need to do. And we should not optimistically assume that there is no need to adjust and iterate over the initially submitted plans. Which may include some additional time confirming with various communities that changes are OK. I'm a little unclear how much testing/demonstration we need. Arguably, the IETF probably runs the system it needs already. But there are other parts where some re-organisation and re-thinking is needed. Not really clear to me how much confidence building would be needed for those parts. Does anyone have thoughts on this? In general, I think we should run this process as the much ourselves as possible, and have everything (including criteria fulfilment) very clearly spelled out for the NTIA, rather leaving any substantial work for them. But they'll still need some time to process. And we might again need to come back and change something. I guess what I'm coming to is trying to get going pretty early, so that we can iterate in later stages. The tasks are obviously overlapping. For instance, the coordination group should do coordination from day 1, by understanding what the communities are doing and pointing out if they are going into conflicting directions or if there are parts that are not being addressed. So here is one possible overall timeline: Step 1: Communities' work - ready by Dec 30, 2014 (6 months) Step 2: Coordination and alignment, including iteration - ready by March 30, 2015 (+3 months) Step 3: Acceptance and communication - ready by May 30, 2015 (+2 months) Step 4: Testing - ready by July 30, 2015 (+ 2 months) Step 5: NTIA evaluation and acceptance - ready by September 30, 2015 (+2 months) _______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
I agree to both of you. At this stage I wouldn’t question I wouldn’t question the timeline you suggest, Jari. There is definitely one needed which from time to time has to be reviewed in light of the Multistakeholder bottom-up process we’re going through. The communication part is essential, Here we should think about related mechanisms (e.g. public comments at certain milestones e.a.). TThis should be reflected in the timeline, too. Hear you later Wolf-Ulrich From: joseph alhadeff Sent: Thursday, July 10, 2014 7:12 PM To: internal-cg@icann.org Subject: Re: [Internal-cg] Timeline Colleagues: Perhaps the first step is a publication and comment on our operational processes, objectives and input methodology, including consultation mechanisms for those of us representing constituencies. That might give people some comfort in relation to the transparency of our own group's operation? This is likely implied in 1 and 2, but I think we should be more explicit. I understand that this may be more relevant to work other than our own, but issues of optics and comfort with the fairness, inclusiveness and transparency of the process have been huge issues as of late in IG discussions... Joe On 7/10/2014 1:00 PM, Jari Arkko wrote: I thought it would be useful to start discussion of some of the topics that the group needs to deal with. I’m sending you some thoughts on the timeline of events looking forward. This is a rough draft and for discussion purposes only. Please comment! — What is described below reads as one timeline, but it may be important to understand that we actually have multiple parallel efforts: protocol parameters, addresses, and names. These efforts have several points of linkage, but allowing parallel operation is probably a good idea. As a result, the timeline may run at slightly different speeds for the different parts. The NTIA has said that the September 2015 deadline is not firm, and that they could extend contracts and prolong the process beyond that. I do believe, however, that there are several reasons why getting done by then is at least useful if not even necessary. First of all, I think we all need a goal. And open-ended timelines lead to open-ended discussions. Second, people, administrations, political climate, etc. may change. So I think we should work towards September 30, 2015. But of course, we also want a good proposal to go forward. In thinking about what is needed before completion, I think see at least the following tasks: 1. Communities: Communities coming up with plans. 2. Coordination and alignment. This includes possible iteration and even going back to the communities. It also includes, possibly, some acceptance phase with the global community for the assembled plan. For instance, the assembled complete plan should probably be something that the customers of IANA are happy with. In other words, coordination can be lead by the coordination group, but it likely includes a lot of work also in the communities. 3. Test run. We may want to show off that the system can actually run in the proposed way for a while. 4. NTIA evaluation and approval process. The community processes are in my opinion the most important ones, and should involve most of the work. In addition, they tend to run for long times. For instance, the simplest IETF last call would be a month already. We also want to give time to the NTIA to do what they need to do. And we should not optimistically assume that there is no need to adjust and iterate over the initially submitted plans. Which may include some additional time confirming with various communities that changes are OK. I’m a little unclear how much testing/demonstration we need. Arguably, the IETF probably runs the system it needs already. But there are other parts where some re-organisation and re-thinking is needed. Not really clear to me how much confidence building would be needed for those parts. Does anyone have thoughts on this? In general, I think we should run this process as the much ourselves as possible, and have everything (including criteria fulfilment) very clearly spelled out for the NTIA, rather leaving any substantial work for them. But they’ll still need some time to process. And we might again need to come back and change something. I guess what I’m coming to is trying to get going pretty early, so that we can iterate in later stages. The tasks are obviously overlapping. For instance, the coordination group should do coordination from day 1, by understanding what the communities are doing and pointing out if they are going into conflicting directions or if there are parts that are not being addressed. So here is one possible overall timeline: Step 1: Communities' work - ready by Dec 30, 2014 (6 months) Step 2: Coordination and alignment, including iteration - ready by March 30, 2015 (+3 months) Step 3: Acceptance and communication - ready by May 30, 2015 (+2 months) Step 4: Testing - ready by July 30, 2015 (+ 2 months) Step 5: NTIA evaluation and acceptance - ready by September 30, 2015 (+2 months) _______________________________________________ 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
Here is a very early draft for a charter of the group, provided as one possible starting point for the discussion. Please comment. Jari, Russ, Alissa, Lynn — The coordination group has one deliverable, a proposal to the NTIA regarding the transition of NTIA’s stewardship of IANA functions to the multi-stakeholder community. The coordination group performs, as its name implies, coordination, among the communities that are affected by IANA functions. The IANA parameters fall into three categories: domain names, number resources, and other protocol parameters. While there is some overlap among these categories, they have their own communities of interest; it is easiest to have these communities proceed on the work in parallel. The coordination group has three main tasks: (i) Ensuring that the relevant communities are working on their part of the transition plans This involves informing, tracking progress, and highlighting the results or remaining issues. The role of a coordination group member during this phase is just - providing status updates about the progress of his or her community in developing their component, - coordinating which community will develop a transition proposal for each area of overlap (e.g., special-use registry) - reflecting to the rest of the coordination group the consensus within the member's own community. (ii) Assemble a complete proposal for the transition. This can begin when the reports from the coordination group members from each of the three communities come back with an answer of, "Yes, there is consensus within my community in support of the complete proposal." The assembly effort involves taking the proposals for the different components and verifying that they fulfil the intended full scope, meet the intended criteria, that there are no missing parts, and that the whole fits together. The CG might at some point detect problems with the component proposals. At that point the role of the CG is to communicate that back to the relevant communities so that they (the relevant communities) can address the issues. This step concludes when the coordination group achieves rough consensus that all conditions have been met. (iii) Information sharing and communication. This should be performed continuously throughout the process.
(Resent with a more proper subject line) Here is a very early draft for a charter of the group, provided as one possible starting point for the discussion. Please comment. Jari, Russ, Alissa, Lynn — The coordination group has one deliverable, a proposal to the NTIA regarding the transition of NTIA’s stewardship of IANA functions to the multi-stakeholder community. The coordination group performs, as its name implies, coordination, among the communities that are affected by IANA functions. The IANA parameters fall into three categories: domain names, number resources, and other protocol parameters. While there is some overlap among these categories, they have their own communities of interest; it is easiest to have these communities proceed on the work in parallel. The coordination group has three main tasks: (i) Ensuring that the relevant communities are working on their part of the transition plans This involves informing, tracking progress, and highlighting the results or remaining issues. The role of a coordination group member during this phase is just - providing status updates about the progress of his or her community in developing their component, - coordinating which community will develop a transition proposal for each area of overlap (e.g., special-use registry) - reflecting to the rest of the coordination group the consensus within the member's own community. (ii) Assemble a complete proposal for the transition. This can begin when the reports from the coordination group members from each of the three communities come back with an answer of, "Yes, there is consensus within my community in support of the complete proposal." The assembly effort involves taking the proposals for the different components and verifying that they fulfil the intended full scope, meet the intended criteria, that there are no missing parts, and that the whole fits together. The CG might at some point detect problems with the component proposals. At that point the role of the CG is to communicate that back to the relevant communities so that they (the relevant communities) can address the issues. This step concludes when the coordination group achieves rough consensus that all conditions have been met. (iii) Information sharing and communication. This should be performed continuously throughout the process.
Jari Thanks for getting this started. I will try to prepare some amendments but it might be better to start with a rationale that explains why I think it needs amending. I am afraid the CG will have to be a bit more proactive as the intermediary between these communities. You may not see this because your community (IETF, IAB, standards) deals with technical coordination, where there are strong incentives to cooperate and the value of cooperation/consensus almost always outweighs most other differences. I am afraid this is not true in the names world, where you are dealing primarily with politics, public policy issues, and conflicts between economic interests. Lots of zero sum games played in that space; true consensus is rare. The DNS does not define a "community of interest;" it refers to many communities of often conflicting interests. ICANN actually has three distinct organs for DNS policy development: the GNSO, the GAC and the board itself. ICANN staff both implements policy and actively manages the policy development process. One of those organs, the GNSO, consists of 4 separate Stakeholder Groups, and within 2 of the stakeholder groups there are 5 separate "constituencies" which usually vote as a bloc irrespective of the views of the other constituencies. Within the GAC, you have about 60 governments actively represented, and we know how diverse their views can be. This does not even mention the ccNSO, which represents over 100 cc registries with a level of autonomy from ICANN's contractual regime that makes them quite different from the gTLDs and which may (or may not) have economic or political interests aligned with their government. Thus, it makes little sense to ask the people on the CG from the names communities to "reflect to the rest of the coordination group the consensus within [their] own community". It is highly unlikely that a single proposal will emerge from the names communities; it is far more likely that you will get several proposals of various flavors with varying levels of support. Therefore, I think the CG has to be chartered to review and select from among those proposals: i) to provide a reality check on their workability, ii) to assess their compatibility and interoperability with the numbers and protocol part of the problem, and iii) to assess their levels of support. In other words, the CG will have to actively construct a proposal based on the "raw materials" we get from the names, numbers and protocol parameters worlds. Of course, if any one of those 3 segments rises in revolt at what we construct from their input, our charter should require us to change it. But I think we need more of a "consult - digest - propose - consult - modify" model than a "passively receive proposals and stick them together into a package" model. This does not mean voting, it does not mean we are a legislature, but it does mean that we will have to take responsibility for boiling down many diverse suggestions into workable proposals. Please don't shoot the messenger when I inform/warn you of this; what I say is based on 16 years of experience with ICANN, including careful observation of the differences in the initial formation of the 3 supporting organizations. If we define a slightly stronger charter but I prove to be wrong and the names, numbers nad protocol communities defy precedent and miraculously come together consense around a single proposal, we have lost nothing - and no one will be happier than me. But if I am right, we had better be prepared for it, don't you think? --MM
-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg- bounces@icann.org] On Behalf Of Jari Arkko Sent: Sunday, July 13, 2014 7:22 PM To: Internal-cg@icann.org Subject: [Internal-cg] Early draft for a charter
(Resent with a more proper subject line)
Here is a very early draft for a charter of the group, provided as one possible starting point for the discussion. Please comment.
Jari, Russ, Alissa, Lynn
-
The coordination group has one deliverable, a proposal to the NTIA regarding the transition of NTIA's stewardship of IANA functions to the multi- stakeholder community.
The coordination group performs, as its name implies, coordination, among the communities that are affected by IANA functions. The IANA parameters fall into three categories: domain names, number resources, and other protocol parameters. While there is some overlap among these categories, they have their own communities of interest; it is easiest to have these communities proceed on the work in parallel.
The coordination group has three main tasks:
(i) Ensuring that the relevant communities are working on their part of the transition plans
This involves informing, tracking progress, and highlighting the results or remaining issues.
The role of a coordination group member during this phase is just
- providing status updates about the progress of his or her community in developing their component, - coordinating which community will develop a transition proposal for each area of overlap (e.g., special-use registry) - reflecting to the rest of the coordination group the consensus within the member's own community.
(ii) Assemble a complete proposal for the transition.
This can begin when the reports from the coordination group members from each of the three communities come back with an answer of, "Yes, there is consensus within my community in support of the complete proposal."
The assembly effort involves taking the proposals for the different components and verifying that they fulfil the intended full scope, meet the intended criteria, that there are no missing parts, and that the whole fits together.
The CG might at some point detect problems with the component proposals. At that point the role of the CG is to communicate that back to the relevant communities so that they (the relevant communities) can address the issues.
This step concludes when the coordination group achieves rough consensus that all conditions have been met.
(iii) Information sharing and communication.
This should be performed continuously throughout the process.
Milton, thanks, I'm fine with your rationale for strengthening the charter and am willing to contribute. For the work of this group it seems really important to know the background of each participating member entity and the related process of contributing to the transition proposal. Eg as I mentioned on the call I'm representing a certain part (Commercial Stakeholder Group, CSG) of the GNSO, as Milton, Keith and James represent other parts. And since there are - to some extent diverse - constituencies I'll have counterparts there to communicate with to give and receive feedback from this community. In addition, discussion is going on as to create a cordination group within the GNSO (plus other stakeholders??). If that arises our charter may have to reflect this to avoid parallelism. Now, who should do the real work? I'm sure parts of our communities - if not all of them - expect this from us with the caveat to say yes, no or amend. There are many who'd like to call our work into question. Therefore we need good understanding for each other and a solid basis. Best regards Wolf-Ulrich -----Ursprüngliche Nachricht----- From: Milton L Mueller Sent: Monday, July 14, 2014 9:15 PM To: Internal-cg@icann.org Subject: Re: [Internal-cg] Early draft for a charter Jari Thanks for getting this started. I will try to prepare some amendments but it might be better to start with a rationale that explains why I think it needs amending. I am afraid the CG will have to be a bit more proactive as the intermediary between these communities. You may not see this because your community (IETF, IAB, standards) deals with technical coordination, where there are strong incentives to cooperate and the value of cooperation/consensus almost always outweighs most other differences. I am afraid this is not true in the names world, where you are dealing primarily with politics, public policy issues, and conflicts between economic interests. Lots of zero sum games played in that space; true consensus is rare. The DNS does not define a "community of interest;" it refers to many communities of often conflicting interests. ICANN actually has three distinct organs for DNS policy development: the GNSO, the GAC and the board itself. ICANN staff both implements policy and actively manages the policy development process. One of those organs, the GNSO, consists of 4 separate Stakeholder Groups, and within 2 of the stakeholder groups there are 5 separate "constituencies" which usually vote as a bloc irrespective of the views of the other constituencies. Within the GAC, you have about 60 governments actively represented, and we know how diverse their views can be. This does not even mention the ccNSO, which represents over 100 cc registries with a level of autonomy from ICANN's contractual regime that makes them quite different from the gTLDs and which may (or may not) have economic or political interests aligned with their government. Thus, it makes little sense to ask the people on the CG from the names communities to "reflect to the rest of the coordination group the consensus within [their] own community". It is highly unlikely that a single proposal will emerge from the names communities; it is far more likely that you will get several proposals of various flavors with varying levels of support. Therefore, I think the CG has to be chartered to review and select from among those proposals: i) to provide a reality check on their workability, ii) to assess their compatibility and interoperability with the numbers and protocol part of the problem, and iii) to assess their levels of support. In other words, the CG will have to actively construct a proposal based on the "raw materials" we get from the names, numbers and protocol parameters worlds. Of course, if any one of those 3 segments rises in revolt at what we construct from their input, our charter should require us to change it. But I think we need more of a "consult - digest - propose - consult - modify" model than a "passively receive proposals and stick them together into a package" model. This does not mean voting, it does not mean we are a legislature, but it does mean that we will have to take responsibility for boiling down many diverse suggestions into workable proposals. Please don't shoot the messenger when I inform/warn you of this; what I say is based on 16 years of experience with ICANN, including careful observation of the differences in the initial formation of the 3 supporting organizations. If we define a slightly stronger charter but I prove to be wrong and the names, numbers nad protocol communities defy precedent and miraculously come together consense around a single proposal, we have lost nothing - and no one will be happier than me. But if I am right, we had better be prepared for it, don't you think? --MM
-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg- bounces@icann.org] On Behalf Of Jari Arkko Sent: Sunday, July 13, 2014 7:22 PM To: Internal-cg@icann.org Subject: [Internal-cg] Early draft for a charter
(Resent with a more proper subject line)
Here is a very early draft for a charter of the group, provided as one possible starting point for the discussion. Please comment.
Jari, Russ, Alissa, Lynn
-
The coordination group has one deliverable, a proposal to the NTIA regarding the transition of NTIA's stewardship of IANA functions to the multi- stakeholder community.
The coordination group performs, as its name implies, coordination, among the communities that are affected by IANA functions. The IANA parameters fall into three categories: domain names, number resources, and other protocol parameters. While there is some overlap among these categories, they have their own communities of interest; it is easiest to have these communities proceed on the work in parallel.
The coordination group has three main tasks:
(i) Ensuring that the relevant communities are working on their part of the transition plans
This involves informing, tracking progress, and highlighting the results or remaining issues.
The role of a coordination group member during this phase is just
- providing status updates about the progress of his or her community in developing their component, - coordinating which community will develop a transition proposal for each area of overlap (e.g., special-use registry) - reflecting to the rest of the coordination group the consensus within the member's own community.
(ii) Assemble a complete proposal for the transition.
This can begin when the reports from the coordination group members from each of the three communities come back with an answer of, "Yes, there is consensus within my community in support of the complete proposal."
The assembly effort involves taking the proposals for the different components and verifying that they fulfil the intended full scope, meet the intended criteria, that there are no missing parts, and that the whole fits together.
The CG might at some point detect problems with the component proposals. At that point the role of the CG is to communicate that back to the relevant communities so that they (the relevant communities) can address the issues.
This step concludes when the coordination group achieves rough consensus that all conditions have been met.
(iii) Information sharing and communication.
This should be performed continuously throughout the process.
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Hi Milton, I’m glad we are digging into the details on this. I can appreciate the challenges in coming to consensus within the diverse names community. But I think there are some major drawbacks in what you suggest, so I’d like to probe on our options for addressing that challenge. I believe there are actually two challenges with coming to consensus in the names community: the diversity of views, and the lack of a cross-community decision mechanism that is trusted, or at least acknowledged, by all of the constituencies. My understanding is that competing policy proposals often get developed within separate constituencies, and since there is no cross-community decision mechanism, decisions ultimately get bumped up to the board, which is far from ideal for many reasons. For the IANA stewardship transition, I think the first key question is what the cross-community decision mechanism will be. I think such a mechanism is absolutely necessary. You have suggested that the CG should be that mechanism. I think this is problematic for a few reasons: 1. The CG contains members from outside the names community who, in my opinion, should not be put in the position of having authority over the transition plan substance for names. I count myself in that category — it is not appropriate for me, as an appointee of the IETF, to look at three different proposals for, say, transitioning oversight of ccTLDs, and decide which one is “best.” I don’t even know on what basis I would choose, and in any event it subjugates the agency of the relevant community to have outsiders choosing their fate. 2. The problem described above is a show-stopper for protocol parameters. That is, it will not be acceptable for the CG to modify the substance of an IETF community consensus proposal for protocol parameters if the IETF community produces such a proposal. The ultimate authority over the substance of the protocol parameters proposal must reside with the IETF community, not the CG. If the CG observes problems with any proposal it receives from the IETF, the remedy for that is to send the proposal back to the IETF community to get fixed, not to fix it ourselves. 3. If the core of the difficulty in the names community is that views are so diverse as to be irreconcilable, I’m not sure I understand why the subset of the CG reps from names organizations would be more likely to agree on one proposal than would the organizations they represent. Sure, there are fewer people in the CG than in the community, but that doesn’t necessarily imply that their views are any less entrenched (not saying that’s the case — I don’t know most of you or your views! — but just making an observation). 4. NTIA has specified that the final transition proposal needs to have broad community support. It’s not clear to me that, if presented with, say, four different proposals from four different constituency groups, the CG choosing one of them would actually result in a proposal that could be claimed to have broad community support. Same goes for if we stitch together pieces of different names proposals. In light of the above, I’m wondering about other options for creating a (somewhat) trusted cross-community decision mechanism for names. I can think of at least two. One idea would be to try to establish a single forum where all of the constituent groups engage with each other and each others’ proposals. Perhaps this could be the fledgling cross-community working group being established right now, or if some groups do not trust that structure, perhaps we in the CG could help to establish a neutral forum where this discussion could be had and where some community-wide decision-taking procedure could be established. Of course, depending on how that decision procedure works, the views may be too diverse to achieve a solution with broad community support, but better to make that attempt than have the small CG group declare one proposal the winner. A less preferable but perhaps still workable idea would be to establish a subcommittee of the CG comprised of the reps from the various names constituencies, and have that subcommittee serve as the decision function that you described (or as the consensus-caller in the single forum described above). This would eliminate problems #1 and #2 from the above list, although it may still suffer from problems #3 and #4. I will end this novel now. Looking forward to further discussion on the list and in person. Best, Alissa On 7/14/14, 12:15 PM, "Milton L Mueller" <mueller@syr.edu> wrote:
Jari Thanks for getting this started. I will try to prepare some amendments but it might be better to start with a rationale that explains why I think it needs amending.
I am afraid the CG will have to be a bit more proactive as the intermediary between these communities.
You may not see this because your community (IETF, IAB, standards) deals with technical coordination, where there are strong incentives to cooperate and the value of cooperation/consensus almost always outweighs most other differences.
I am afraid this is not true in the names world, where you are dealing primarily with politics, public policy issues, and conflicts between economic interests. Lots of zero sum games played in that space; true consensus is rare.
The DNS does not define a "community of interest;" it refers to many communities of often conflicting interests. ICANN actually has three distinct organs for DNS policy development: the GNSO, the GAC and the board itself. ICANN staff both implements policy and actively manages the policy development process. One of those organs, the GNSO, consists of 4 separate Stakeholder Groups, and within 2 of the stakeholder groups there are 5 separate "constituencies" which usually vote as a bloc irrespective of the views of the other constituencies. Within the GAC, you have about 60 governments actively represented, and we know how diverse their views can be. This does not even mention the ccNSO, which represents over 100 cc registries with a level of autonomy from ICANN's contractual regime that makes them quite different from the gTLDs and which may (or may not) have economic or political interests aligned with their government.
Thus, it makes little sense to ask the people on the CG from the names communities to "reflect to the rest of the coordination group the consensus within [their] own community". It is highly unlikely that a single proposal will emerge from the names communities; it is far more likely that you will get several proposals of various flavors with varying levels of support. Therefore, I think the CG has to be chartered to review and select from among those proposals: i) to provide a reality check on their workability, ii) to assess their compatibility and interoperability with the numbers and protocol part of the problem, and iii) to assess their levels of support.
In other words, the CG will have to actively construct a proposal based on the "raw materials" we get from the names, numbers and protocol parameters worlds. Of course, if any one of those 3 segments rises in revolt at what we construct from their input, our charter should require us to change it. But I think we need more of a "consult - digest - propose - consult - modify" model than a "passively receive proposals and stick them together into a package" model. This does not mean voting, it does not mean we are a legislature, but it does mean that we will have to take responsibility for boiling down many diverse suggestions into workable proposals.
Please don't shoot the messenger when I inform/warn you of this; what I say is based on 16 years of experience with ICANN, including careful observation of the differences in the initial formation of the 3 supporting organizations.
If we define a slightly stronger charter but I prove to be wrong and the names, numbers nad protocol communities defy precedent and miraculously come together consense around a single proposal, we have lost nothing - and no one will be happier than me. But if I am right, we had better be prepared for it, don't you think?
--MM
-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg- bounces@icann.org] On Behalf Of Jari Arkko Sent: Sunday, July 13, 2014 7:22 PM To: Internal-cg@icann.org Subject: [Internal-cg] Early draft for a charter
(Resent with a more proper subject line)
Here is a very early draft for a charter of the group, provided as one possible starting point for the discussion. Please comment.
Jari, Russ, Alissa, Lynn
-
The coordination group has one deliverable, a proposal to the NTIA regarding the transition of NTIA's stewardship of IANA functions to the multi- stakeholder community.
The coordination group performs, as its name implies, coordination, among the communities that are affected by IANA functions. The IANA parameters fall into three categories: domain names, number resources, and other protocol parameters. While there is some overlap among these categories, they have their own communities of interest; it is easiest to have these communities proceed on the work in parallel.
The coordination group has three main tasks:
(i) Ensuring that the relevant communities are working on their part of the transition plans
This involves informing, tracking progress, and highlighting the results or remaining issues.
The role of a coordination group member during this phase is just
- providing status updates about the progress of his or her community in developing their component, - coordinating which community will develop a transition proposal for each area of overlap (e.g., special-use registry) - reflecting to the rest of the coordination group the consensus within the member's own community.
(ii) Assemble a complete proposal for the transition.
This can begin when the reports from the coordination group members from each of the three communities come back with an answer of, "Yes, there is consensus within my community in support of the complete proposal."
The assembly effort involves taking the proposals for the different components and verifying that they fulfil the intended full scope, meet the intended criteria, that there are no missing parts, and that the whole fits together.
The CG might at some point detect problems with the component proposals. At that point the role of the CG is to communicate that back to the relevant communities so that they (the relevant communities) can address the issues.
This step concludes when the coordination group achieves rough consensus that all conditions have been met.
(iii) Information sharing and communication.
This should be performed continuously throughout the process.
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Thanks Alissa for the well-considered response. My replies below in line
-----Original Message----- board, which is far from ideal for many reasons. For the IANA stewardship transition, I think the first key question is what the cross-community decision mechanism will be. I think such a mechanism is absolutely necessary.
A Cross Community Working Group is being set up within ICANN. There are three problems with it: a) like the CG, it contains members from outside the names communities (e.g., RIRs, ASO, ALAC) b) its composition almost exactly mirrors that of the CG, only it is larger c) it is almost entirely ICANN oriented
You have suggested that the CG should be that mechanism.
Incorrect! Not at all what I proposed! Here is a simple cut and paste of what I proposed: I think the CG has to be chartered to review proposals: * to provide a reality check on their workability, * to assess their compatibility and interoperability with the numbers and protocol part of the problem, and * to assess their levels of support. In other words, my idea assumes that the CG is a "taker" not a "maker" of proposals, but it also evaluates them, and may need to tweak them to achieve compatibility. It does NOT propose to make the CG the mechanism for initial development of proposals. It DOES assume that whatever we do is subject to public comment. The difference is just that I am assuming (based on sober realism) that there is unlikely to be consensus among the DNS communities, and that there is still a need for assessment of the way the proposals coming out of the 3 communities relate to each other. I also believe that, given the size, complexity and non-DNS-based nature of the CCWG, that there will be a need for an independent assessment of the level of support enjoyed by proposals that emerge from the CCWG, and indeed, for all 3 sectors. The DNS part is also likely to receive input from non-ICANN based sources. IMHO, some of those proposals may need to be taken as seriously as whatever comes out of the CCWG. There is also some possibility that there will be US Congressional legislation that impacts our work.
2. The problem described above is a show-stopper for protocol parameters. That is, it will not be acceptable for the CG to modify the substance of an IETF community consensus proposal for protocol parameters if the IETF community produces such a proposal. The ultimate authority over the
Of course. Again, you are misunderstanding my conception of the role of the CG. If indeed a community produces a firm consensus then none of the problems I am worried about are invoked. The three functions mentioned above (check on workability, assessment of compatibility and interoperability, and levels of support) would not justify changing an IETF proposal that had consensus & was workable. If, however, there proved to be incompatibilities with the proposal coming out of IETF, DNS and numbers, then the the CG could send the proposal back to IETF with an explanation of what the problem was, and await modification. I am sure you would not suggest that an IETF solution should dictate the form or structure preferred by other communities?
substance of the protocol parameters proposal must reside with the IETF community, not the CG. If the CG observes problems with any proposal it receives from the IETF, the remedy for that is to send the proposal back to the IETF community to get fixed, not to fix it ourselves.
Exactly what I had in mind (see above).
3. If the core of the difficulty in the names community is that views are so diverse as to be irreconcilable, I’m not sure I understand why the subset of the CG reps from names organizations would be more likely to agree on one proposal than would the organizations they represent.
It is possible, of course, that both entities would be deadlocked; however, it is a well-known feature of politics and working groups that a smaller, higher-level committee one step removed from the direct constituencies may find it easier to find accord - especially since they are in more direct communication with each other and with the other communities. For a very rough analogy, think of the differences between the House and the Senate in the U.S. Congress, or the difference between an expert commission and a Congressional committee.
4. NTIA has specified that the final transition proposal needs to have broad community support. It’s not clear to me that, if presented with, say, four different proposals from four different constituency groups, the CG choosing one of them would actually result in a proposal that could be claimed to have broad community support. Same goes for if we stitch together pieces of different names proposals.
The CG is in the best position to assess which of the 4 has the most support and fits in the best with the other communities' plans, don't you think? And I think it is also in the best position to determine which modifications could be made in a viable proposal that had some, but not quite enough, support, to increase its standing. As for stitching together, there is no avoiding it -- even in the ideal case that you seem to be contemplaying, we will "stitch together" the DNS, numbers and protocol proposals into a single integrated proposal. And there will be a public comment period for reviewing whatever we do. Hope this clarifies my position, and I think it shows that we are not that far apart, I am, imho, simply a bit more detailed and realistic about what we are likely to face.
I will end this novel now.
Hope chapter 2 contains battle scenes, romance and a happy ending
Let me contribute an essay: When a person or group asks you to make a decision for them, it is never wise to just do as they ask. Sometimes it may be wise to help them see the question before them more clearly. Often it is best just to look at them patiently until they make up their minds. One person who has taught me this by example was Jon Postel. </essay> This says it all, so if pressed for time you can stop reading right here. ------ Application to the question being discussed: If the names communities cannot come to consensus about the transition of NTIA's role by themselves, then it would not be wise for the CG to have any part in doing this for them, even if the names communities ask for it. The best the CG can do is to produce a unified proposal from the parts that *do* have consensus in their respective communities and have those communities come to consensus about that unified proposal. It may be that the names communities do not realise what is at stake for them and that it is in their interest to agree on *something* within a reasonable time. If they cannot manage this by themselves then then the CG cannot make this happen magically and should not try. Rather the CG should make a proposal that leaves out the IANA functions concerning names and disband. If the names communities should find that they need help coming to consensus it is up to them to find that help somewhere, possibly in arbitration or some other process help. That is up to them. But if they come to us we should say 'No'. NB: This is not specific to "names". I just wrote it with reference to this particular thread. Summary: Daniel fully agrees with Alissa and substantially disagrees with Milton.
Colleagues: As was noted in the prep call different folks represent different constituencies and how those groups go about developing consensus, can inform our process, but cannot be the substance of our process. I too will throw my hat in for the need for solutions to emerge as part of consensus building and do not see how we can impose order or process on a constituency that does not currently have the shared interest of a solution. Is there any more commonality if we go one further level of distinction down? By way of placing these comments in context... While a number of the groups more directly involved in the operations of IANA can be categorized as businesses, and some may be members of ICC/BASIS, the constituency I represent is the broader range of businesses that are not directly involved in Internet Governance, but are rather it's beneficiaries. Some of those businesses would be unable to articulate the IANA functions, but approach these issues which some level of trepidation related to any change that could break or impair the Internet or their ability to use it as a channel of commerce and in some cases also communication or societal interaction. A concept that would broadly reflect that groups concern and interest is a Hippocratic oath of IANA transition - First do no harm. The other tenant which was heard in relation to the overall transition process was, to the extent possible, test the proposals. To a limited extent there may be some technical steps which can be taken to test proposals, in other cases, things like scenario analysis may be an appropriate methodology. Essentially those businesses are looking for any demonstration/validation possible of the functionality of any new solutions proposed. ICC/BASIS will also be reaching out to other broad business groups not affiliated with ICC (Recall that ICC includes national committees in over 80 countries) to get their input to the process, but we were waiting for a little more substance before undertaking that outreach. Looking forward to the meeting- Joe PS:Is there an interest for an informal dinner on Wed? On 7/15/2014 12:45 PM, Daniel Karrenberg wrote:
Let me contribute an essay:
When a person or group asks you to make a decision for them, it is never wise to just do as they ask.
Sometimes it may be wise to help them see the question before them more clearly.
Often it is best just to look at them patiently until they make up their minds.
One person who has taught me this by example was Jon Postel.
</essay>
This says it all, so if pressed for time you can stop reading right here.
------
Application to the question being discussed:
If the names communities cannot come to consensus about the transition of NTIA's role by themselves, then it would not be wise for the CG to have any part in doing this for them, even if the names communities ask for it.
The best the CG can do is to produce a unified proposal from the parts that *do* have consensus in their respective communities and have those communities come to consensus about that unified proposal.
It may be that the names communities do not realise what is at stake for them and that it is in their interest to agree on *something* within a reasonable time. If they cannot manage this by themselves then then the CG cannot make this happen magically and should not try. Rather the CG should make a proposal that leaves out the IANA functions concerning names and disband.
If the names communities should find that they need help coming to consensus it is up to them to find that help somewhere, possibly in arbitration or some other process help. That is up to them. But if they come to us we should say 'No'.
NB: This is not specific to "names". I just wrote it with reference to this particular thread.
Summary: Daniel fully agrees with Alissa and substantially disagrees with Milton. _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
-----Original Message----- The best the CG can do is to produce a unified proposal from the parts that *do* have consensus in their respective communities and have those communities come to consensus about that unified proposal.
Thanks, Daniel. That is not much different from what I am proposing. But I am calling attention to a fact that is often neglected or deliberately ignored in these circles, which is that the presence or absence of "consensus" is not self-evident, that consensus can be (and often is) claimed when it does not exist, and thus there is a need for independent assessment of the level of support enjoyed by a proposal. I am also insisting on the fact - yes, it is a fact - that no proposal coming out of the DNS world will enjoy total, true _consensus_ if we use the term in the proper, Quaker sense, meaning full accord, no objections, unanimity. Some of them may, however, enjoy significant, broad support, broad enough to be viable. So the CG will have to make judgments about what passes the bar and what doesn't.
It may be that the names communities do not realise what is at stake for them and that it is in their interest to agree on *something* within a reasonable time. If they cannot manage this by themselves then then the CG cannot make this happen magically and should not try.
And you recognize, of course, that such an approach gives veto power to any group that does not want the transition to happen? There is a long history of obstructionism by small but determined and powerful interests in the names world. How does this fit in with your concept of consensus? I wonder why you would consider, say, the GNSO or an ICANN-composed CCWG as a legitimate modifier or developer of a proposal but would not consider a CG whose members were appointed as representatives by the exact same group. Alissa's idea of a subgroup of DNS-related people on the CG might make sense here.
Rather the CG should make a proposal that leaves out the IANA functions concerning names and disband.
This I regard as irresponsible. An IANA transition that does not include a viable plan for DNS is not an IANA transition. Full stop. The protocol parameter registries are not controversial. The number registry issues could be controversial, but currently are not. If we cannot resolve DNS controversies, we have resolved nothing, accomplished nothing. So if you are happy with the status quo, keep singing this tune.
If the names communities should find that they need help coming to consensus it is up to them to find that help somewhere, possibly in arbitration or some other process help. That is up to them. But if they come to us we should say 'No'.
Did I miss the argument as to why? I want an instrumental argument, a practical argument, not a fable or an anecdote
Summary: Daniel fully agrees with Alissa and substantially disagrees with Milton.
What you agree or disagree with, I hope, are specific arguments or positions, not people. Personalization of disagreements about the charter and mission is counterproductive. For one thing, there are about a dozen, distinct statements or arguments in my last post, some of which are not all that contestable. Are you saying you disagree with all of them simply because they come from me? Lets try to do better. --MM
I think the group has to be clear about the various consensus levels everybody has in mind when talking about "consensus". In addition it should be transparent on whose behalf CG members speak and - if at all - participate in consensus calls. It could be helpful to mention it in the charter. Best regards Wolf-Ulrich -----Ursprüngliche Nachricht----- From: Milton L Mueller Sent: Tuesday, July 15, 2014 8:30 PM To: 'Daniel Karrenberg' Cc: Internal-cg@icann.org Subject: Re: [Internal-cg] Early draft for a charter
-----Original Message----- The best the CG can do is to produce a unified proposal from the parts that *do* have consensus in their respective communities and have those communities come to consensus about that unified proposal.
Thanks, Daniel. That is not much different from what I am proposing. But I am calling attention to a fact that is often neglected or deliberately ignored in these circles, which is that the presence or absence of "consensus" is not self-evident, that consensus can be (and often is) claimed when it does not exist, and thus there is a need for independent assessment of the level of support enjoyed by a proposal. I am also insisting on the fact - yes, it is a fact - that no proposal coming out of the DNS world will enjoy total, true _consensus_ if we use the term in the proper, Quaker sense, meaning full accord, no objections, unanimity. Some of them may, however, enjoy significant, broad support, broad enough to be viable. So the CG will have to make judgments about what passes the bar and what doesn't.
It may be that the names communities do not realise what is at stake for them and that it is in their interest to agree on *something* within a reasonable time. If they cannot manage this by themselves then then the CG cannot make this happen magically and should not try.
And you recognize, of course, that such an approach gives veto power to any group that does not want the transition to happen? There is a long history of obstructionism by small but determined and powerful interests in the names world. How does this fit in with your concept of consensus? I wonder why you would consider, say, the GNSO or an ICANN-composed CCWG as a legitimate modifier or developer of a proposal but would not consider a CG whose members were appointed as representatives by the exact same group. Alissa's idea of a subgroup of DNS-related people on the CG might make sense here.
Rather the CG should make a proposal that leaves out the IANA functions concerning names and disband.
This I regard as irresponsible. An IANA transition that does not include a viable plan for DNS is not an IANA transition. Full stop. The protocol parameter registries are not controversial. The number registry issues could be controversial, but currently are not. If we cannot resolve DNS controversies, we have resolved nothing, accomplished nothing. So if you are happy with the status quo, keep singing this tune.
If the names communities should find that they need help coming to consensus it is up to them to find that help somewhere, possibly in arbitration or some other process help. That is up to them. But if they come to us we should say 'No'.
Did I miss the argument as to why? I want an instrumental argument, a practical argument, not a fable or an anecdote
Summary: Daniel fully agrees with Alissa and substantially disagrees with Milton.
What you agree or disagree with, I hope, are specific arguments or positions, not people. Personalization of disagreements about the charter and mission is counterproductive. For one thing, there are about a dozen, distinct statements or arguments in my last post, some of which are not all that contestable. Are you saying you disagree with all of them simply because they come from me? Lets try to do better. --MM _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
On 15.07.14 20:53 , WUKnoben wrote:
I think the group has to be clear about the various consensus levels everybody has in mind when talking about "consensus". In addition it should be transparent on whose behalf CG members speak and - if at all - participate in consensus calls. It could be helpful to mention it in the charter.
This is a hard problem in general. In our specific case I would go for the pragmatic approach: "No outspoken disagreement by anyone NTIA cannot ignore." This is easy to check if we liaise closely with NTIA. Daniel
The GNSO wrestles with this issue (consensus levels) in its policy development process. We have developed some descriptions/guidelines that differentiate between "unanimous" vs "consensus" vs "strong support, with opposition". Perhaps on of the Staff folks could post these to the list for the group's consideration? Thank you-- J. __________________________ James Bladel GoDaddy jbladel@godaddy.com
On Jul 16, 2014, at 13:30, "Daniel Karrenberg" <daniel.karrenberg@ripe.net> wrote:
On 15.07.14 20:53 , WUKnoben wrote: I think the group has to be clear about the various consensus levels everybody has in mind when talking about "consensus". In addition it should be transparent on whose behalf CG members speak and - if at all - participate in consensus calls. It could be helpful to mention it in the charter.
This is a hard problem in general. In our specific case I would go for the pragmatic approach: "No outspoken disagreement by anyone NTIA cannot ignore." This is easy to check if we liaise closely with NTIA.
Daniel
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Dear Coordination Group Members, Please find below the descriptions/guidelines James is referring to (see p. 9-10 of GNSO WG guidelines at http://gnso.icann.org/council/annex-1-gnso-wg-guidelines-26mar14-en.pdf - or p.42-43 of the GNSO Operating Procedures http://gnso.icann.org/en/council/op-procedures-26mar14-en.pdf): The Chair will be responsible for designating each position as having one of the following designations: - Full consensus - when no one in the group speaks against the recommendation in its last readings. This is also sometimes referred to as Unanimous Consensus. - Consensus - a position where only a small minority disagrees, but most agree. - Strong support but significant opposition - a position where, while most of the group supports a recommendation, there are a significant number of those who do not support it. - Divergence (also referred to as No Consensus) - a position where there isn't strong support for any particular position, but many different points of view. Sometimes this is due to irreconcilable differences of opinion and sometimes it is due to the fact that no one has a particularly strong or convincing viewpoint, but the members of the group agree that it is worth listing the issue in the report nonetheless. - Minority View - refers to a proposal where a small number of people support the recommendation. This can happen in response to a Consensus, Strong support but significant opposition, and No Consensus; or, it can happen in cases where there is neither support nor opposition to a suggestion made by a small number of individuals. Thanks, Best regards Alice On 7/16/14 3:07 PM, "James M. Bladel" <jbladel@godaddy.com> wrote:
The GNSO wrestles with this issue (consensus levels) in its policy development process. We have developed some descriptions/guidelines that differentiate between "unanimous" vs "consensus" vs "strong support, with opposition".
Perhaps on of the Staff folks could post these to the list for the group's consideration?
Thank you--
J. __________________________ James Bladel GoDaddy jbladel@godaddy.com
On Jul 16, 2014, at 13:30, "Daniel Karrenberg" <daniel.karrenberg@ripe.net> wrote:
On 15.07.14 20:53 , WUKnoben wrote: I think the group has to be clear about the various consensus levels everybody has in mind when talking about "consensus". In addition it should be transparent on whose behalf CG members speak and - if at all - participate in consensus calls. It could be helpful to mention it in the charter.
This is a hard problem in general. In our specific case I would go for the pragmatic approach: "No outspoken disagreement by anyone NTIA cannot ignore." This is easy to check if we liaise closely with NTIA.
Daniel
_______________________________________________ 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
[sorry this has become very long. i just want some things to be on record. decide yourself whether it is interesting and helpful enough for you.] Milton, I am well aware of the effect that you call "veto power" in consensus processes. I have experienced my share of what you call "obstructionism" too. That's just something we have to deal with. It all depends on the definition of consensus. See my pragmatic definition of "consensus" in this thread and we can discuss this further. Now about being responsible: look at it from the perspective of those IANA customers that do have robust and credible processes and who can indeed come to consensus within a reasonable time. Should their fate indefinitely be subject to "veto power" from those that cannot come to consensus? They will likely say: "Of course not!" I would consider it irresponsible of these communities to allow themselves to be taken hostage by those communities that will not deliver.The responsible course of action for them is to try hard to get as broad a consensus as can practically be achieved. But once it becomes clear that this is not happening within a reasonable time, they will have no choice but to document this and to propose a transition for those parts of the IANA whose customers can agree on a proposal. Note well that I am personally much more flexible about the "reasonable time" than some others appear to be. I consider it much more important to have the broadest possible agreement on a well considered proposal than to finish in time for the current contract period running out. But it cannot take indefinite time and constant progress must be evident. An assertion by one community that their area is just more controversial or complicated than others will only go so far. At this point in time all areas are permeated by "politics, public policy issues, and conflicts between economic interests." It is not obvious to me how the benefits of consensus about self governance are substantially different among the communities. I am sure that for instance both the IETF and the RIRs could credibly argue that their participants constitute a significantly larger share of industrial activity than the total names business. So there is even more money at stake and more potential for all sorts of conflicts. The RIRs could credibly argue that they have successfully managed running out of a very finite yet economically critical resource: IPv4 addresses; they could take the view that this is much more complicated to get right than distributing an essentially infinite name space. People could take the view that all that is needed is that other communities get their act together to the same standards. After some time the sentiment may well be that "the names should just get on with it." It is all a matter of perspective. Such assertions and the discussions about them will not be helpful to us. They will only create antagonism that we do not need. We all have to do our homework and we will have to help each other doing it as much as possible. We will have failed if we do not come up with a workable proposal that only has opponents whome NTIA can safely ignore. This will not only preserve the status-quo. It will also show very clearly to the world that our self governance does not work. I still believe that everyone around our table does not want that to happen. Daniel PS: My argument against our group making decisions for particular communities is indeed in the first lines of my message. In my experience nothing good has ever come from giving in to that particular temptation. Experience is a strong and totally convincing argument for me. Others have already mentioned practicalities such as creating the opportunity for an end-run around the particular community and increased resistance based on "the wrong people" making decisions. Daniel PPS: We can discuss debating style over a beverage. When I say I agree with X then I mean I agree with what they have said in the particular context. Daniel
I’m with both Milton and Alissa in this discussion. - Members of the CG are not in any position to invent solutions for other constituencies (other than their own), and neither will they succeed by trying to do so. - To me this means that realistically, the CG can only consider substantive parts of the eventual plan that have been supplied by the affected constituencies, and our role in reconciling differences cannot introduce substantial changes to individual plans. Well, we can try, and we can try to judge the difference between substantial changes and lesser adjustments, but in the end that judgement is not ours to make. - I believe that in soliciting plans from the individual communities we must be very clear on what is expected: giving as much guidance as we can on the structure of the plan, on the information that is must contain, the questions which must be addressed, etc. This could be in the form or a checklist, a questionnaire, or a survey monkey form. :-) - To allow us to find the “best compromise” in case of differences, we may also need to identify in advance the likely areas of difference, and structure our questions so as to drill down into those areas. - We might also ask that the plans submitted to us respond very specifically in identifying negotiable or non-negotiable elements (preferences versus requirements). Sure, some folks will actually be more negotiable than they are prepared to admit, but it is important I think to phrase this whole exercise as one of compromise rather than demand. - Finally I think that one thing we can do is to make a distinction, both in our own minds and in our communication with constituencies, between those aspics of the transition plan that are essential to the transition, and those which may be able to be deferred for later resolution. This process will certainly not succeed if participants try to use it as an opportunity to make ambit claims for a whole raft of demands or reforms which are not strictly related to the transition. Thanks, ________________________________________________________________________ Paul Wilson, Director-General, APNIC <dg@apnic.net> http://www.apnic.net +61 7 3858 3100 See you at APNIC 38! http://conference.apnic.net/38 On 16 Jul 2014, at 12:48 am, Milton L Mueller <Mueller@syr.edu> wrote:
Thanks Alissa for the well-considered response. My replies below in line
-----Original Message----- board, which is far from ideal for many reasons. For the IANA stewardship transition, I think the first key question is what the cross-community decision mechanism will be. I think such a mechanism is absolutely necessary.
A Cross Community Working Group is being set up within ICANN. There are three problems with it: a) like the CG, it contains members from outside the names communities (e.g., RIRs, ASO, ALAC) b) its composition almost exactly mirrors that of the CG, only it is larger c) it is almost entirely ICANN oriented
You have suggested that the CG should be that mechanism.
Incorrect! Not at all what I proposed! Here is a simple cut and paste of what I proposed:
I think the CG has to be chartered to review proposals: * to provide a reality check on their workability, * to assess their compatibility and interoperability with the numbers and protocol part of the problem, and * to assess their levels of support.
In other words, my idea assumes that the CG is a "taker" not a "maker" of proposals, but it also evaluates them, and may need to tweak them to achieve compatibility. It does NOT propose to make the CG the mechanism for initial development of proposals. It DOES assume that whatever we do is subject to public comment. The difference is just that I am assuming (based on sober realism) that there is unlikely to be consensus among the DNS communities, and that there is still a need for assessment of the way the proposals coming out of the 3 communities relate to each other. I also believe that, given the size, complexity and non-DNS-based nature of the CCWG, that there will be a need for an independent assessment of the level of support enjoyed by proposals that emerge from the CCWG, and indeed, for all 3 sectors.
The DNS part is also likely to receive input from non-ICANN based sources. IMHO, some of those proposals may need to be taken as seriously as whatever comes out of the CCWG. There is also some possibility that there will be US Congressional legislation that impacts our work.
2. The problem described above is a show-stopper for protocol parameters. That is, it will not be acceptable for the CG to modify the substance of an IETF community consensus proposal for protocol parameters if the IETF community produces such a proposal. The ultimate authority over the
Of course. Again, you are misunderstanding my conception of the role of the CG. If indeed a community produces a firm consensus then none of the problems I am worried about are invoked. The three functions mentioned above (check on workability, assessment of compatibility and interoperability, and levels of support) would not justify changing an IETF proposal that had consensus & was workable. If, however, there proved to be incompatibilities with the proposal coming out of IETF, DNS and numbers, then the the CG could send the proposal back to IETF with an explanation of what the problem was, and await modification. I am sure you would not suggest that an IETF solution should dictate the form or structure preferred by other communities?
substance of the protocol parameters proposal must reside with the IETF community, not the CG. If the CG observes problems with any proposal it receives from the IETF, the remedy for that is to send the proposal back to the IETF community to get fixed, not to fix it ourselves.
Exactly what I had in mind (see above).
3. If the core of the difficulty in the names community is that views are so diverse as to be irreconcilable, I’m not sure I understand why the subset of the CG reps from names organizations would be more likely to agree on one proposal than would the organizations they represent.
It is possible, of course, that both entities would be deadlocked; however, it is a well-known feature of politics and working groups that a smaller, higher-level committee one step removed from the direct constituencies may find it easier to find accord - especially since they are in more direct communication with each other and with the other communities. For a very rough analogy, think of the differences between the House and the Senate in the U.S. Congress, or the difference between an expert commission and a Congressional committee.
4. NTIA has specified that the final transition proposal needs to have broad community support. It’s not clear to me that, if presented with, say, four different proposals from four different constituency groups, the CG choosing one of them would actually result in a proposal that could be claimed to have broad community support. Same goes for if we stitch together pieces of different names proposals.
The CG is in the best position to assess which of the 4 has the most support and fits in the best with the other communities' plans, don't you think? And I think it is also in the best position to determine which modifications could be made in a viable proposal that had some, but not quite enough, support, to increase its standing. As for stitching together, there is no avoiding it -- even in the ideal case that you seem to be contemplaying, we will "stitch together" the DNS, numbers and protocol proposals into a single integrated proposal. And there will be a public comment period for reviewing whatever we do.
Hope this clarifies my position, and I think it shows that we are not that far apart, I am, imho, simply a bit more detailed and realistic about what we are likely to face.
I will end this novel now.
Hope chapter 2 contains battle scenes, romance and a happy ending
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
participants (10)
-
Alice Jansen -
Alissa Cooper -
Daniel Karrenberg -
Drazek, Keith -
James M. Bladel -
Jari Arkko -
joseph alhadeff -
Milton L Mueller -
Paul Wilson -
WUKnoben