I agree with Chuck on this. Our objective in oversight of the operation of the IANA functions should be to ensure as near a self-healing process as we can get: spotting issues early and addressing them – and that was the thinking in the CSC design team, using internal escalation to ensure that there is a proper understanding of issues within the management chain so that resources can be brought to bear. However, that relies on there being a will to resolve issues. If there is not and we end up with a failing IANA functions operator (as we have had in the past), we need to be able to find a solution and implement it quickly. That in itself is not going to be easy without also having to face a slog against a reluctant bureaucracy. From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Gomes, Chuck Sent: 28 April 2015 22:42 To: CW Lists; Grace Abuhamad Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Chris, While I believe that that separation should only happen after several progressive steps and that it should be only done for intractable breaches, I also don’t think it is wise to make it so difficult that ICANN essentially believes that there is no real threat of that happening because that would be little different than giving them the rights to operate IANA in perpetuity, which I think would be a terrible mistake. Chuck From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of CW Lists Sent: Tuesday, April 28, 2015 5:03 PM To: Grace Abuhamad Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Good evening: 1. It is important that Post Transition IANA, as a whole, remains anchored with Protocols and Numbering, that is with IETF and the RIRs. There are several reasons for this. ( a ) Open Internet Standards are critical for fair competition and low entry barriers. Governments and Users have an existential interest in the work of IETF. ( b ) Numbering, and particularly communications numbering are of critical interest to public policy. Most governments have accepted with more-or-less good grace that that shall continue to be done for the Internet by the RIRs. However, I believe that in the last resort their ability to comment and advise on numbering policy through ICANN/IANA/GAC is a significant element in their acceptance. 2. The recent debate within the CWG has clearly revealed support for separation of IANA/Names from the other IANA functions and - if possible - from ICANN. Whether that has been for ideological or commercial reasons is immaterial at this stage. The present CWG compromise proposal is workable for the time being, but I expect that debate on separation to re-open shortly after the transition, not least on the basis of the proposed array of IANA performance criteria. As a long-time student and practitioner of industrial economics applied to the information society, let me say that IANA, as a fully privatised commercial service, would become financially invaluable to its owners. I do not want to see that happen, ever. The first line of defence is to ensure the continued integration of all IANA functions: Naming, numbering and protocols. The second line of defence is to make it as difficult as possible to separate IANA from ICANN (as to be reformed under the CCWG Accountability proposals). In the last resort, a 'separate' IANA must be protected as a public service against any form of capture. However, that last resort is not yet credible. There are no safeguards in place, not least because the multistakeholder community has tacitly, if not explicitly, come to the conclusion that we do not wish to reproduce all the checks and balances that ought to be present within ICANN, in the IANA context as well. 3. Granted, IETF/CRISP/RIRs/CWG have all been working to date within their respective 'silos'. So be it, although the risks were already visible in ICANN 50/London. It is now up to the ICG to make sure that they do not materialise. ICG must ensure that there is no 'poison pill' for post transition IANA arising from the 'separability' debate in CWG. Regards CW On 28 Apr 2015, at 22:18, Grace Abuhamad <grace.abuhamad@icann.org<mailto:grace.abuhamad@icann.org>> wrote: Dear CWG-Stewardship, Following a request from our GAC member Elise Lindeberg and the two briefing webinars on 24 April<https://community.icann.org/x/ryYnAw> (last week), the Chairs are going to hold two additional webinars on 6-7 May. The announcement will be posted within the next 24h, but I wanted to share the information with the group now. The two additional webinars will be held on: 6 May from 13:00 – 14:30 UTC (time zone converter here<http://www.timeanddate.com/worldclock/fixedtime.html?msg=CWG-Stewardship+Web...>) 7 May from 06:00 – 07:30 UTC (time zone converter here<http://www.timeanddate.com/worldclock/fixedtime.html?msg=CWG-Stewardship+Web...>) These webinars will focus more on the content of the proposal and less on the work process that led to the development of the 2nd draft proposal. The main value of these webinars is that they will allow for further questions and answers from the community, while still giving the community enough time to submit comments in time for the close of the public comment period on 20 May. Brenda will send calendar notices to the group with call details. Talk to you all on the CWG call on Thursday, Grace _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship

Points taken Milton. I think we need to find the right balance on this. Chuck From: Milton L Mueller [mailto:mueller@syr.edu] Sent: Wednesday, April 29, 2015 12:54 PM To: 'Martin Boyle'; Gomes, Chuck; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Martin Boyle MB: I agree with Chuck on this. Our objective in oversight of the operation of the IANA functions should be to ensure as near a self-healing process as we can get: spotting issues early and addressing them – and that was the thinking in the CSC design team, using internal escalation to ensure that there is a proper understanding of issues within the management chain so that resources can be brought to bear. However, that relies on there being a will to resolve issues. If there is not and we end up with a failing IANA functions operator (as we have had in the past), we need to be able to find a solution and implement it quickly. That in itself is not going to be easy without also having to face a slog against a reluctant bureaucracy. MM: I am glad that both you and Chuck think it would be a mistake to give anyone the right to operate IANA services in perpetuity. Even so, I still detect a tendency to erect too many barriers to separability. The right to terminate the contract is just basic common sense. It is the simplest and most powerful accountability mechanism there is. IANA is nothing but a clerical service performed for technical coordination needs. If an IANA functions operator does not do the job right, you fire them and find another service provider. True, changing providers can create disruptions, and service providers often exploit these to lock you in to their service. But one of the weaknesses of the current proposal is that it makes this process of separation far too complex and slow. No one in the community wants to change providers for the heck of it. But if they do, we should not make it difficult. The IETF makes extensive use of IANA, and their MoU says is that they can terminate their agreement with ICANN with 6 months notice. For any reason, at any time. In the DNS environment more stakeholders need to be consulted, so I don’t oppose having a more defined review process, but the idea that we must bend over backwards to ensure that the existing IANA functions operator is given 6 bites at the apple before we can change it is a bit ridiculous. From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Gomes, Chuck Sent: 28 April 2015 22:42 To: CW Lists; Grace Abuhamad Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Chris, While I believe that that separation should only happen after several progressive steps and that it should be only done for intractable breaches, I also don’t think it is wise to make it so difficult that ICANN essentially believes that there is no real threat of that happening because that would be little different than giving them the rights to operate IANA in perpetuity, which I think would be a terrible mistake. Chuck From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of CW Lists Sent: Tuesday, April 28, 2015 5:03 PM To: Grace Abuhamad Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Good evening: 1. It is important that Post Transition IANA, as a whole, remains anchored with Protocols and Numbering, that is with IETF and the RIRs. There are several reasons for this. ( a ) Open Internet Standards are critical for fair competition and low entry barriers. Governments and Users have an existential interest in the work of IETF. ( b ) Numbering, and particularly communications numbering are of critical interest to public policy. Most governments have accepted with more-or-less good grace that that shall continue to be done for the Internet by the RIRs. However, I believe that in the last resort their ability to comment and advise on numbering policy through ICANN/IANA/GAC is a significant element in their acceptance. 2. The recent debate within the CWG has clearly revealed support for separation of IANA/Names from the other IANA functions and - if possible - from ICANN. Whether that has been for ideological or commercial reasons is immaterial at this stage. The present CWG compromise proposal is workable for the time being, but I expect that debate on separation to re-open shortly after the transition, not least on the basis of the proposed array of IANA performance criteria. As a long-time student and practitioner of industrial economics applied to the information society, let me say that IANA, as a fully privatised commercial service, would become financially invaluable to its owners. I do not want to see that happen, ever. The first line of defence is to ensure the continued integration of all IANA functions: Naming, numbering and protocols. The second line of defence is to make it as difficult as possible to separate IANA from ICANN (as to be reformed under the CCWG Accountability proposals). In the last resort, a 'separate' IANA must be protected as a public service against any form of capture. However, that last resort is not yet credible. There are no safeguards in place, not least because the multistakeholder community has tacitly, if not explicitly, come to the conclusion that we do not wish to reproduce all the checks and balances that ought to be present within ICANN, in the IANA context as well. 3. Granted, IETF/CRISP/RIRs/CWG have all been working to date within their respective 'silos'. So be it, although the risks were already visible in ICANN 50/London. It is now up to the ICG to make sure that they do not materialise. ICG must ensure that there is no 'poison pill' for post transition IANA arising from the 'separability' debate in CWG. Regards CW On 28 Apr 2015, at 22:18, Grace Abuhamad <grace.abuhamad@icann.org<mailto:grace.abuhamad@icann.org>> wrote: Dear CWG-Stewardship, Following a request from our GAC member Elise Lindeberg and the two briefing webinars on 24 April<https://community.icann.org/x/ryYnAw> (last week), the Chairs are going to hold two additional webinars on 6-7 May. The announcement will be posted within the next 24h, but I wanted to share the information with the group now. The two additional webinars will be held on: 6 May from 13:00 – 14:30 UTC (time zone converter here<http://www.timeanddate.com/worldclock/fixedtime.html?msg=CWG-Stewardship+Web...>) 7 May from 06:00 – 07:30 UTC (time zone converter here<http://www.timeanddate.com/worldclock/fixedtime.html?msg=CWG-Stewardship+Web...>) These webinars will focus more on the content of the proposal and less on the work process that led to the development of the 2nd draft proposal. The main value of these webinars is that they will allow for further questions and answers from the community, while still giving the community enough time to submit comments in time for the close of the public comment period on 20 May. Brenda will send calendar notices to the group with call details. Talk to you all on the CWG call on Thursday, Grace _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship

Thanks for helping to highlight where you and I diverge, Milton. I’d take changing the operator a lot more seriously than you! MM: I don’t think we actually do diverge on this issue, Martin. See below. So whoever takes the IANA functions operator role will need to be aware of the back story and be able to command trust. It is not straight-forward and while I am sure there’s a long list of people who would be able to update names, protocol parameters and the gTLD part of the TLD registries, I still struggle to think of who might be able to do the ccTLD piece and would also be generally trusted. (Clue – it is not a TLD or a consortium of TLDs.) MM: The IANA Functions operator (IFO) should simply take ICANN’s instructions. One benefit of a separated IFO would be the ability to more clearly separate those sensitive policy decisions that should really be made by ICANN, and those implementations that should be done by the IFO. I agree with you that ccTLD redelegations can be more sensitive than gTLD delegations, I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. Do you disagree?

Martin/Milton, Please note my understandings below. Chuck From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Sent: Friday, May 01, 2015 6:44 AM To: Milton L Mueller; Gomes, Chuck; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Obviously then I’m misunderstanding something Milton.

The IANA Functions operator (IFO) should simply take ICANN’s instructions. [Chuck Gomes] I think this is mostly accurate but I qualify that below.

Err, no! The IANA functions operator should base its decisions on agreed policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group. It also has advice from the GAC 2005 Principles. ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations. [Chuck Gomes] With regard to technical policy (i.e., Internet Standards), my understanding is that the IFO would check for compliance and does not need specific direction from ICANN in that regard so I think Martin is correct that the IFO doesn’t rely on ICANN’s instructions for its technical checks. But with regard to ccTLD delegations or revocations, I believe that a Board approval is required. I do not believe that the IFO is involved in any interpretation of ICANN policy; rather, ICANN staff confirms that ICANN policy has been followed. I know In the case of gTLDs, no Board action is needed for a delegation of a gTLD but ICANN staff confirms that GNSO policy has been followed before it ever gets to IANA involvement; it is not the IFO responsibility to do that. This is fundamental – clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions. And if I remember correctly this principle is clearly embodied in the SOW. And ICANN does not have the power to overrule national due processes. [Chuck Gomes] Agreed on the principle of separation policy development and the IFO and I think what I described in my previous comments above demonstrates clear separation but I am pretty sure that ICANN staff must give confirmation (instructions) that ICANN policy (in contrast to technical policy) has been satisfied regarding delegations or revocations. And I do not think that violates the principle of separating policy development from the IFO. I of course also agree that “ICANN does not have the power to overrule national due processes” but I don’t think that means that the IFO would be involved in interpreting national due process; isn’t that ICANN’s task?

I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. [Chuck Gomes] I think this is a correct statement as I have tried to describe above.

The issue – and hence the complexity – is about who actually has the right to make the decisions and direct the IANA functions operator. The role of the IANA functions operator is to identify that a decision is appropriate – and the SOW gives some guidance to that, as does the work of the FOIWG. But it is absolutely not ICANN’s decision. [Chuck Gomes] From a technical point of view I agree but not beyond that. We would be getting into a very different situation if the IFO has to make decisions regarding whether ICANN policy or national due process is followed. That would mean that the IANA functions are much more than technical and clerical and it would require very different skills sets. Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not. The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions. (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.) I do not think that I’m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor. [Chuck Gomes] I definitely do not think that ICANN should impose arbitrary conditions or question legitimate national decisions but I do not believe that that means that the IFO should make those decisions. If we have disagreement on this, then I think we need to have some serious discussions so that we are all on the same page. Martin From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 30 April 2015 18:48 To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Thanks for helping to highlight where you and I diverge, Milton. I’d take changing the operator a lot more seriously than you! MM: I don’t think we actually do diverge on this issue, Martin. See below. So whoever takes the IANA functions operator role will need to be aware of the back story and be able to command trust. It is not straight-forward and while I am sure there’s a long list of people who would be able to update names, protocol parameters and the gTLD part of the TLD registries, I still struggle to think of who might be able to do the ccTLD piece and would also be generally trusted. (Clue – it is not a TLD or a consortium of TLDs.) MM: The IANA Functions operator (IFO) should simply take ICANN’s instructions. One benefit of a separated IFO would be the ability to more clearly separate those sensitive policy decisions that should really be made by ICANN, and those implementations that should be done by the IFO. I agree with you that ccTLD redelegations can be more sensitive than gTLD delegations, I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. Do you disagree?

Matin + 1. Cheers, Chris On 3 May 2015, at 08:16 , Martin Boyle <Martin.Boyle@nominet.org.uk> wrote:

Chuck, comments in line below.

From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 01 May 2015 14:37 To: Martin Boyle; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May

Martin/Milton,

Please note my understandings below.

Chuck

From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Sent: Friday, May 01, 2015 6:44 AM To: Milton L Mueller; Gomes, Chuck; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May

Obviously then I’m misunderstanding something Milton.

...

The IANA Functions operator (IFO) should simply take ICANN’s instructions. [Chuck Gomes] I think this is mostly accurate but I qualify that below.

Err, no! The IANA functions operator should base its decisions on agreed policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group. It also has advice from the GAC 2005 Principles. ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations. [Chuck Gomes] With regard to technical policy (i.e., Internet Standards), my understanding is that the IFO would check for compliance and does not need specific direction from ICANN in that regard so I think Martin is correct that the IFO doesn’t rely on ICANN’s instructions for its technical checks. But with regard to ccTLD delegations or revocations, I believe that a Board approval is required. I do not believe that the IFO is involved in any interpretation of ICANN policy; rather, ICANN staff confirms that ICANN policy has been followed. I know In the case of gTLDs, no Board action is needed for a delegation of a gTLD but ICANN staff confirms that GNSO policy has been followed before it ever gets to IANA involvement; it is not the IFO responsibility to do that.

MB: I believe – and Chris Disspain has explained the role to the ccNSO and to others – the Board sees its role on delegations and revocations of ccTLDs as assessing a traffic-light report from the IANA functions operator staff: it is essentially a process and documentation check, although it could be used to approve a decision where strict adherence to policy (eg on engagement with interested parties in countries where this sort of approach is not carried out). In my mind it is not an instruction and the role could be done by a PTI Board which has responsibility for the provision of the IANA functions operator role.

This is fundamental – clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions. And if I remember correctly this principle is clearly embodied in the SOW. And ICANN does not have the power to overrule national due processes. [Chuck Gomes] Agreed on the principle of separation policy development and the IFO and I think what I described in my previous comments above demonstrates clear separation but I am pretty sure that ICANN staff must give confirmation (instructions) that ICANN policy (in contrast to technical policy) has been satisfied regarding delegations or revocations. And I do not think that violates the principle of separating policy development from the IFO. I of course also agree that “ICANN does not have the power to overrule national due processes” but I don’t think that means that the IFO would be involved in interpreting national due process; isn’t that ICANN’s task?

MB: For ccTLDs, I do not see where this role is performed. I’d also be alarmed at other ccTLDs (and hence non-nationals) having a say over a ccTLD.

...

I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. [Chuck Gomes] I think this is a correct statement as I have tried to describe above.

MB: The IANA functions operator’s role is surely (again for ccTLDs) to ascertain that the decision for change has properly been made (and all other decisions can be automated anyway. But the disagreement is who does have the discretion to make those decisions.

The issue – and hence the complexity – is about who actually has the right to make the decisions and direct the IANA functions operator. The role of the IANA functions operator is to identify that a decision is appropriate – and the SOW gives some guidance to that, as does the work of the FOIWG. But it is absolutely not ICANN’s decision. [Chuck Gomes] From a technical point of view I agree but not beyond that. We would be getting into a very different situation if the IFO has to make decisions regarding whether ICANN policy or national due process is followed. That would mean that the IANA functions are much more than technical and clerical and it would require very different skills sets.

MB: the IANA functions operator (and the current ICANN Board) role is not to make the decision, but to verify that the decision is appropriate and correctly made.

Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not.

The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions. (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.) I do not think that I’m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor. [Chuck Gomes] I definitely do not think that ICANN should impose arbitrary conditions or question legitimate national decisions but I do not believe that that means that the IFO should make those decisions. If we have disagreement on this, then I think we need to have some serious discussions so that we are all on the same page.

MB: I am not arguing that the IANA functions operator makes the decisions. It is that the ICANN Board does not make decisions and give instructions.

Martin

From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 30 April 2015 18:48 To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May

Thanks for helping to highlight where you and I diverge, Milton. I’d take changing the operator a lot more seriously than you!

MM: I don’t think we actually do diverge on this issue, Martin. See below.

So whoever takes the IANA functions operator role will need to be aware of the back story and be able to command trust. It is not straight-forward and while I am sure there’s a long list of people who would be able to update names, protocol parameters and the gTLD part of the TLD registries, I still struggle to think of who might be able to do the ccTLD piece and would also be generally trusted. (Clue – it is not a TLD or a consortium of TLDs.)

MM: The IANA Functions operator (IFO) should simply take ICANN’s instructions. One benefit of a separated IFO would be the ability to more clearly separate those sensitive policy decisions that should really be made by ICANN, and those implementations that should be done by the IFO. I agree with you that ccTLD redelegations can be more sensitive than gTLD delegations, I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. Do you disagree?

_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship

Chuck,

What is the board doing when it approves a ccTLD delegation if it is not making a decision?

I think it is just checking that its operators have followed due process and have documented the final decision. The decision should have been made locally/nationally and it is not really for the ICANN Board to challenge or overrule a decision made in another country, just to check that the job has been done. The IANA Functions Operator usually encourages contending parties come to a mutual agreement and the whole process is pretty delicate.

PTI does not make any decision regarding whether policy has been followed except for technical policy

I’m still not really sure I know what you mean by technical policy. I think the PTI assesses whether requests fit the requirements of RFC1591 and encourages local resolution of disputes. In the case of continued disputes, the final decision would need to be according to local due process. Elise might be able to explain how they currently assure themselves that the process has concluded. The Board of the new entity would, I guess, want to ascertain that its staff is doing a good job – and that might include whether a delegation conforms to agreed policy and to local decisions (“C.2.9.2.c … the Contractor will consult with the interested and affected parties, as enumerated in Section C.1.3; relevant public authorities; and governments on any recommendation that is not within or consistent with an existing policy framework. In making its recommendations, the Contractor shall also take into account the relevant national frameworks and applicable laws of the jurisdiction that the TLD registry serves.”) Due diligence would suggest a need to check that due process has been flowed within the IFO, and that the process and recommendation have been properly documented. However, as I said to Milton last night, it had not occurred to me to put the check back to the ICANN Board. I’m still not sure I understand why that would be a good idea. In the case of a decision being made in the relevant jurisdiction, should verification of due process and documentation be able to do anything more than refer back and seek clarification? I think not. In which case, why would we separate an integral part of the SOW from the PTI when we are introducing legal separation? Does that answer your questions? Martin From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 03 May 2015 15:54 To: Chris Disspain; Martin Boyle Cc: Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship@icann.org Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May What is the board doing when it approves a ccTLD delegation if it is not making a decision? It seems to me that we are in agreement that PTI does not make any decision regarding whether policy has been followed except for technical policy. Is that correct? Chuck From: Chris Disspain [mailto:ceo@auda.org.au] Sent: Saturday, May 02, 2015 9:41 PM To: Martin Boyle Cc: Gomes, Chuck; Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Matin + 1. Cheers, Chris On 3 May 2015, at 08:16 , Martin Boyle <Martin.Boyle@nominet.org.uk<mailto:Martin.Boyle@nominet.org.uk>> wrote: Chuck, comments in line below. From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 01 May 2015 14:37 To: Martin Boyle; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Martin/Milton, Please note my understandings below. Chuck From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Sent: Friday, May 01, 2015 6:44 AM To: Milton L Mueller; Gomes, Chuck; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Obviously then I’m misunderstanding something Milton.

The IANA Functions operator (IFO) should simply take ICANN’s instructions. [Chuck Gomes] I think this is mostly accurate but I qualify that below.

Err, no! The IANA functions operator should base its decisions on agreed policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group. It also has advice from the GAC 2005 Principles. ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations. [Chuck Gomes] With regard to technical policy (i.e., Internet Standards), my understanding is that the IFO would check for compliance and does not need specific direction from ICANN in that regard so I think Martin is correct that the IFO doesn’t rely on ICANN’s instructions for its technical checks. But with regard to ccTLD delegations or revocations, I believe that a Board approval is required. I do not believe that the IFO is involved in any interpretation of ICANN policy; rather, ICANN staff confirms that ICANN policy has been followed. I know In the case of gTLDs, no Board action is needed for a delegation of a gTLD but ICANN staff confirms that GNSO policy has been followed before it ever gets to IANA involvement; it is not the IFO responsibility to do that. MB: I believe – and Chris Disspain has explained the role to the ccNSO and to others – the Board sees its role on delegations and revocations of ccTLDs as assessing a traffic-light report from the IANA functions operator staff: it is essentially a process and documentation check, although it could be used to approve a decision where strict adherence to policy (eg on engagement with interested parties in countries where this sort of approach is not carried out). In my mind it is not an instruction and the role could be done by a PTI Board which has responsibility for the provision of the IANA functions operator role. This is fundamental – clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions. And if I remember correctly this principle is clearly embodied in the SOW. And ICANN does not have the power to overrule national due processes. [Chuck Gomes] Agreed on the principle of separation policy development and the IFO and I think what I described in my previous comments above demonstrates clear separation but I am pretty sure that ICANN staff must give confirmation (instructions) that ICANN policy (in contrast to technical policy) has been satisfied regarding delegations or revocations. And I do not think that violates the principle of separating policy development from the IFO. I of course also agree that “ICANN does not have the power to overrule national due processes” but I don’t think that means that the IFO would be involved in interpreting national due process; isn’t that ICANN’s task? MB: For ccTLDs, I do not see where this role is performed. I’d also be alarmed at other ccTLDs (and hence non-nationals) having a say over a ccTLD.

I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. [Chuck Gomes] I think this is a correct statement as I have tried to describe above.

MB: The IANA functions operator’s role is surely (again for ccTLDs) to ascertain that the decision for change has properly been made (and all other decisions can be automated anyway. But the disagreement is who does have the discretion to make those decisions. The issue – and hence the complexity – is about who actually has the right to make the decisions and direct the IANA functions operator. The role of the IANA functions operator is to identify that a decision is appropriate – and the SOW gives some guidance to that, as does the work of the FOIWG. But it is absolutely not ICANN’s decision. [Chuck Gomes] From a technical point of view I agree but not beyond that. We would be getting into a very different situation if the IFO has to make decisions regarding whether ICANN policy or national due process is followed. That would mean that the IANA functions are much more than technical and clerical and it would require very different skills sets. MB: the IANA functions operator (and the current ICANN Board) role is not to make the decision, but to verify that the decision is appropriate and correctly made. Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not. The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions. (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.) I do not think that I’m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor. [Chuck Gomes] I definitely do not think that ICANN should impose arbitrary conditions or question legitimate national decisions but I do not believe that that means that the IFO should make those decisions. If we have disagreement on this, then I think we need to have some serious discussions so that we are all on the same page. MB: I am not arguing that the IANA functions operator makes the decisions. It is that the ICANN Board does not make decisions and give instructions. Martin From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 30 April 2015 18:48 To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Thanks for helping to highlight where you and I diverge, Milton. I’d take changing the operator a lot more seriously than you! MM: I don’t think we actually do diverge on this issue, Martin. See below. So whoever takes the IANA functions operator role will need to be aware of the back story and be able to command trust. It is not straight-forward and while I am sure there’s a long list of people who would be able to update names, protocol parameters and the gTLD part of the TLD registries, I still struggle to think of who might be able to do the ccTLD piece and would also be generally trusted. (Clue – it is not a TLD or a consortium of TLDs.) MM: The IANA Functions operator (IFO) should simply take ICANN’s instructions. One benefit of a separated IFO would be the ability to more clearly separate those sensitive policy decisions that should really be made by ICANN, and those implementations that should be done by the IFO. I agree with you that ccTLD redelegations can be more sensitive than gTLD delegations, I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. Do you disagree? _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship

I just received the clarification I needed on this from Bernie and Bart. The IANA do the due diligence to ensure that the local laws/community issues are satisfied for ccTLDs. I had mistakenly thought that that was done by ICANN staff and reported to the IANA team. For gTLDs I do not believe that the IANA team needs to do any policy checking but just need the confirmation from the GDD team that policy is in order. I am fine with this. I see no problem at all that it is handled differently for gTLDs and ccTLDs. Also, if the ccTLD registries are fine with this, that is what matters. My only suggestion is that we are clear in communicating the difference in the IFO functions with regard to ccTLDs and gTLDs in cases where it is relevant. Note that I added Elise as a cc so that she knows that I have the answer to the question I asked her. Of course, if she wants to add more that is fine but may not be needed now. Chuck From: Gomes, Chuck Sent: Sunday, May 03, 2015 8:24 PM To: 'Martin Boyle'; Chris Disspain Cc: Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship@icann.org Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Thanks Martin. I suspect that we are not far apart and much of what we are talking about may be semantics, i.e., terms that we are interpreting in different ways. That is probably easily fixable as Milton has indicated. Please see a few more comments below. Chuck From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Sent: Sunday, May 03, 2015 6:29 PM To: Gomes, Chuck; Chris Disspain Cc: Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Chuck,

What is the board doing when it approves a ccTLD delegation if it is not making a decision?

I think it is just checking that its operators have followed due process and have documented the final decision. The decision should have been made locally/nationally and it is not really for the ICANN Board to challenge or overrule a decision made in another country, just to check that the job has been done. The IANA Functions Operator usually encourages contending parties come to a mutual agreement and the whole process is pretty delicate. [Chuck Gomes] Who are ‘its operators’? I get the impression that you mean the IANA team? Is that correct? If so, I need to have a clearer understanding of what the IANA team does with regard to checking due process. As you can probably tell, I didn’t think the IANA team did any checking with regard to policy due process whether it be GNSO policy for gTLDs or local law for ccTLDs or ccNSO policy (e.g., for IDN TLDs). My understanding has been that such checking is done by non-IANA ICANN staff in both cases. Regardless, I think it is possible for us to reach agreement with regard to PTI functions. But I do believe that it is essential for us all understand on what the IFO does with regarding to checking what you call due process. That is why I asked the questions of Elise.

PTI does not make any decision regarding whether policy has been followed except for technical policy

I’m still not really sure I know what you mean by technical policy. I think the PTI assesses whether requests fit the requirements of RFC1591 and encourages local resolution of disputes. In the case of continued disputes, the final decision would need to be according to local due process. Elise might be able to explain how they currently assure themselves that the process has concluded. [Chuck Gomes] The word policy is used very broadly by many people in the community. Technical standards and operational best practices are sometimes referred to as policy. That is what I mean by technical policy to distinguish it from TLD policy developed within ICANN. Technical policy would be developed by the ASO and IETF; any of those policies that relate to the DNS and the root zone are checked by the IFO and the Maintainer. What I mean by ‘non-technical policy’ are policies like the New gTLD Policy developed by the GNSO or the IDN ccTLD Policy developed by the ccNSO. The Board of the new entity would, I guess, want to ascertain that its staff is doing a good job – and that might include whether a delegation conforms to agreed policy and to local decisions (“C.2.9.2.c … the Contractor will consult with the interested and affected parties, as enumerated in Section C.1.3; relevant public authorities; and governments on any recommendation that is not within or consistent with an existing policy framework. In making its recommendations, the Contractor shall also take into account the relevant national frameworks and applicable laws of the jurisdiction that the TLD registry serves.”) Due diligence would suggest a need to check that due process has been flowed within the IFO, and that the process and recommendation have been properly documented. However, as I said to Milton last night, it had not occurred to me to put the check back to the ICANN Board. I’m still not sure I understand why that would be a good idea. In the case of a decision being made in the relevant jurisdiction, should verification of due process and documentation be able to do anything more than refer back and seek clarification? I think not. In which case, why would we separate an integral part of the SOW from the PTI when we are introducing legal separation? Does that answer your questions? Martin From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 03 May 2015 15:54 To: Chris Disspain; Martin Boyle Cc: Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May What is the board doing when it approves a ccTLD delegation if it is not making a decision? It seems to me that we are in agreement that PTI does not make any decision regarding whether policy has been followed except for technical policy. Is that correct? Chuck From: Chris Disspain [mailto:ceo@auda.org.au] Sent: Saturday, May 02, 2015 9:41 PM To: Martin Boyle Cc: Gomes, Chuck; Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Matin + 1. Cheers, Chris On 3 May 2015, at 08:16 , Martin Boyle <Martin.Boyle@nominet.org.uk<mailto:Martin.Boyle@nominet.org.uk>> wrote: Chuck, comments in line below. From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 01 May 2015 14:37 To: Martin Boyle; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Martin/Milton, Please note my understandings below. Chuck From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Sent: Friday, May 01, 2015 6:44 AM To: Milton L Mueller; Gomes, Chuck; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Obviously then I’m misunderstanding something Milton.

The IANA Functions operator (IFO) should simply take ICANN’s instructions. [Chuck Gomes] I think this is mostly accurate but I qualify that below.

Err, no! The IANA functions operator should base its decisions on agreed policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group. It also has advice from the GAC 2005 Principles. ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations. [Chuck Gomes] With regard to technical policy (i.e., Internet Standards), my understanding is that the IFO would check for compliance and does not need specific direction from ICANN in that regard so I think Martin is correct that the IFO doesn’t rely on ICANN’s instructions for its technical checks. But with regard to ccTLD delegations or revocations, I believe that a Board approval is required. I do not believe that the IFO is involved in any interpretation of ICANN policy; rather, ICANN staff confirms that ICANN policy has been followed. I know In the case of gTLDs, no Board action is needed for a delegation of a gTLD but ICANN staff confirms that GNSO policy has been followed before it ever gets to IANA involvement; it is not the IFO responsibility to do that. MB: I believe – and Chris Disspain has explained the role to the ccNSO and to others – the Board sees its role on delegations and revocations of ccTLDs as assessing a traffic-light report from the IANA functions operator staff: it is essentially a process and documentation check, although it could be used to approve a decision where strict adherence to policy (eg on engagement with interested parties in countries where this sort of approach is not carried out). In my mind it is not an instruction and the role could be done by a PTI Board which has responsibility for the provision of the IANA functions operator role. This is fundamental – clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions. And if I remember correctly this principle is clearly embodied in the SOW. And ICANN does not have the power to overrule national due processes. [Chuck Gomes] Agreed on the principle of separation policy development and the IFO and I think what I described in my previous comments above demonstrates clear separation but I am pretty sure that ICANN staff must give confirmation (instructions) that ICANN policy (in contrast to technical policy) has been satisfied regarding delegations or revocations. And I do not think that violates the principle of separating policy development from the IFO. I of course also agree that “ICANN does not have the power to overrule national due processes” but I don’t think that means that the IFO would be involved in interpreting national due process; isn’t that ICANN’s task? MB: For ccTLDs, I do not see where this role is performed. I’d also be alarmed at other ccTLDs (and hence non-nationals) having a say over a ccTLD.

I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. [Chuck Gomes] I think this is a correct statement as I have tried to describe above.

MB: The IANA functions operator’s role is surely (again for ccTLDs) to ascertain that the decision for change has properly been made (and all other decisions can be automated anyway. But the disagreement is who does have the discretion to make those decisions. The issue – and hence the complexity – is about who actually has the right to make the decisions and direct the IANA functions operator. The role of the IANA functions operator is to identify that a decision is appropriate – and the SOW gives some guidance to that, as does the work of the FOIWG. But it is absolutely not ICANN’s decision. [Chuck Gomes] From a technical point of view I agree but not beyond that. We would be getting into a very different situation if the IFO has to make decisions regarding whether ICANN policy or national due process is followed. That would mean that the IANA functions are much more than technical and clerical and it would require very different skills sets. MB: the IANA functions operator (and the current ICANN Board) role is not to make the decision, but to verify that the decision is appropriate and correctly made. Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not. The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions. (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.) I do not think that I’m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor. [Chuck Gomes] I definitely do not think that ICANN should impose arbitrary conditions or question legitimate national decisions but I do not believe that that means that the IFO should make those decisions. If we have disagreement on this, then I think we need to have some serious discussions so that we are all on the same page. MB: I am not arguing that the IANA functions operator makes the decisions. It is that the ICANN Board does not make decisions and give instructions. Martin From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 30 April 2015 18:48 To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Thanks for helping to highlight where you and I diverge, Milton. I’d take changing the operator a lot more seriously than you! MM: I don’t think we actually do diverge on this issue, Martin. See below. So whoever takes the IANA functions operator role will need to be aware of the back story and be able to command trust. It is not straight-forward and while I am sure there’s a long list of people who would be able to update names, protocol parameters and the gTLD part of the TLD registries, I still struggle to think of who might be able to do the ccTLD piece and would also be generally trusted. (Clue – it is not a TLD or a consortium of TLDs.) MM: The IANA Functions operator (IFO) should simply take ICANN’s instructions. One benefit of a separated IFO would be the ability to more clearly separate those sensitive policy decisions that should really be made by ICANN, and those implementations that should be done by the IFO. I agree with you that ccTLD redelegations can be more sensitive than gTLD delegations, I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. Do you disagree? _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship

I think you may be right on this Milton but I guess it is a cc decision. Chuck From: Milton L Mueller [mailto:mueller@syr.edu] Sent: Monday, May 04, 2015 10:38 AM To: Gomes, Chuck; Martin Boyle; Chris Disspain Cc: CW Lists; Grace Abuhamad; cwg-stewardship@icann.org; elise.gerich@icann.org Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May From: Gomes, Chuck [mailto:cgomes@verisign.com] I am fine with this. I see no problem at all that it is handled differently for gTLDs and ccTLDs. Also, if the ccTLD registries are fine with this, that is what matters. My only suggestion is that we are clear in communicating the difference in the IFO functions with regard to ccTLDs and gTLDs in cases where it is relevant. MM: Repeating a question buried in my longer message from yesterday: would it be advisable for the ccTLDs to negotiate their own SLA with the PTI? Does this address the potential for the IANA contracts/SLAs not responding to the distinct needs of both communities?

Chuck, Thank you for adding me to the cc list so that it is clear that the question has been answered (thanks, Bernie and Bart). Best, -- Elise From: <Gomes>, Chuck <cgomes@verisign.com> Date: Monday, May 4, 2015 at 7:33 AM To: Martin Boyle <Martin.Boyle@nominet.org.uk>, "ceo@auda.org.au" <ceo@auda.org.au> Cc: Milton L Mueller <mueller@syr.edu>, CW Lists <lists@christopherwilkinson.eu>, Grace Abuhamad <grace.abuhamad@icann.org>, "cwg-stewardship@icann.org" <cwg-stewardship@icann.org>, Elise Gerich <elise.gerich@icann.org> Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

I just received the clarification I needed on this from Bernie and Bart. The IANA do the due diligence to ensure that the local laws/community issues are satisfied for ccTLDs. I had mistakenly thought that that was done by ICANN staff and reported to the IANA team. For gTLDs I do not believe that the IANA team needs to do any policy checking but just need the confirmation from the GDD team that policy is in order.

I am fine with this. I see no problem at all that it is handled differently for gTLDs and ccTLDs. Also, if the ccTLD registries are fine with this, that is what matters.

My only suggestion is that we are clear in communicating the difference in the IFO functions with regard to ccTLDs and gTLDs in cases where it is relevant.

Note that I added Elise as a cc so that she knows that I have the answer to the question I asked her. Of course, if she wants to add more that is fine but may not be needed now.

Chuck

From: Gomes, Chuck Sent: Sunday, May 03, 2015 8:24 PM To: 'Martin Boyle'; Chris Disspain Cc: Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship@icann.org Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Thanks Martin. I suspect that we are not far apart and much of what we are talking about may be semantics, i.e., terms that we are interpreting in different ways. That is probably easily fixable as Milton has indicated. Please see a few more comments below.

Chuck

From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Sent: Sunday, May 03, 2015 6:29 PM To: Gomes, Chuck; Chris Disspain Cc: Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship@icann.org Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Chuck,

...

...

What is the board doing when it approves a ccTLD delegation if it is not making a decision?

I think it is just checking that its operators have followed due process and have documented the final decision. The decision should have been made locally/nationally and it is not really for the ICANN Board to challenge or overrule a decision made in another country, just to check that the job has been done. The IANA Functions Operator usually encourages contending parties come to a mutual agreement and the whole process is pretty delicate. [Chuck Gomes] Who are Œits operators¹? I get the impression that you mean the IANA team? Is that correct? If so, I need to have a clearer understanding of what the IANA team does with regard to checking due process. As you can probably tell, I didn¹t think the IANA team did any checking with regard to policy due process whether it be GNSO policy for gTLDs or local law for ccTLDs or ccNSO policy (e.g., for IDN TLDs). My understanding has been that such checking is done by non-IANA ICANN staff in both cases. Regardless, I think it is possible for us to reach agreement with regard to PTI functions. But I do believe that it is essential for us all understand on what the IFO does with regarding to checking what you call due process. That is why I asked the questions of Elise.

...

...

PTI does not make any decision regarding whether policy has been followed except for technical policy

I¹m still not really sure I know what you mean by technical policy. I think the PTI assesses whether requests fit the requirements of RFC1591 and encourages local resolution of disputes. In the case of continued disputes, the final decision would need to be according to local due process. Elise might be able to explain how they currently assure themselves that the process has concluded. [Chuck Gomes] The word policy is used very broadly by many people in the community. Technical standards and operational best practices are sometimes referred to as policy. That is what I mean by technical policy to distinguish it from TLD policy developed within ICANN. Technical policy would be developed by the ASO and IETF; any of those policies that relate to the DNS and the root zone are checked by the IFO and the Maintainer. What I mean by Œnon-technical policy¹ are policies like the New gTLD Policy developed by the GNSO or the IDN ccTLD Policy developed by the ccNSO.

The Board of the new entity would, I guess, want to ascertain that its staff is doing a good job ­ and that might include whether a delegation conforms to agreed policy and to local decisions (³C.2.9.2.c Š the Contractor will consult with the interested and affected parties, as enumerated in Section C.1.3; relevant public authorities; and governments on any recommendation that is not within or consistent with an existing policy framework. In making its recommendations, the Contractor shall also take into account the relevant national frameworks and applicable laws of the jurisdiction that the TLD registry serves.²) Due diligence would suggest a need to check that due process has been flowed within the IFO, and that the process and recommendation have been properly documented.

However, as I said to Milton last night, it had not occurred to me to put the check back to the ICANN Board. I¹m still not sure I understand why that would be a good idea. In the case of a decision being made in the relevant jurisdiction, should verification of due process and documentation be able to do anything more than refer back and seek clarification? I think not. In which case, why would we separate an integral part of the SOW from the PTI when we are introducing legal separation?

Does that answer your questions?

Martin

From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 03 May 2015 15:54 To: Chris Disspain; Martin Boyle Cc: Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship@icann.org Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

What is the board doing when it approves a ccTLD delegation if it is not making a decision?

It seems to me that we are in agreement that PTI does not make any decision regarding whether policy has been followed except for technical policy. Is that correct?

Chuck

From: Chris Disspain [mailto:ceo@auda.org.au] Sent: Saturday, May 02, 2015 9:41 PM To: Martin Boyle Cc: Gomes, Chuck; Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Matin + 1.

Cheers,

Chris

On 3 May 2015, at 08:16 , Martin Boyle <Martin.Boyle@nominet.org.uk> wrote:

Chuck, comments in line below.

From: Gomes, Chuck [mailto:cgomes@verisign.com <mailto:cgomes@verisign.com> ] Sent: 01 May 2015 14:37 To: Martin Boyle; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> ' Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Martin/Milton,

Please note my understandings below.

Chuck

From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk <mailto:Martin.Boyle@nominet.org.uk> ] Sent: Friday, May 01, 2015 6:44 AM To: Milton L Mueller; Gomes, Chuck; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> ' Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Obviously then I¹m misunderstanding something Milton.

...

...

The IANA Functions operator (IFO) should simply take ICANN¹s instructions.

[Chuck Gomes] I think this is mostly accurate but I qualify that below.

Err, no! The IANA functions operator should base its decisions on agreed policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group. It also has advice from the GAC 2005 Principles. ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations.

[Chuck Gomes] With regard to technical policy (i.e., Internet Standards), my understanding is that the IFO would check for compliance and does not need specific direction from ICANN in that regard so I think Martin is correct that the IFO doesn¹t rely on ICANN¹s instructions for its technical checks. But with regard to ccTLD delegations or revocations, I believe that a Board approval is required. I do not believe that the IFO is involved in any interpretation of ICANN policy; rather, ICANN staff confirms that ICANN policy has been followed. I know In the case of gTLDs, no Board action is needed for a delegation of a gTLD but ICANN staff confirms that GNSO policy has been followed before it ever gets to IANA involvement; it is not the IFO responsibility to do that.

MB: I believe ­ and Chris Disspain has explained the role to the ccNSO and to others ­ the Board sees its role on delegations and revocations of ccTLDs as assessing a traffic-light report from the IANA functions operator staff: it is essentially a process and documentation check, although it could be used to approve a decision where strict adherence to policy (eg on engagement with interested parties in countries where this sort of approach is not carried out). In my mind it is not an instruction and the role could be done by a PTI Board which has responsibility for the provision of the IANA functions operator role.

This is fundamental ­ clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions. And if I remember correctly this principle is clearly embodied in the SOW. And ICANN does not have the power to overrule national due processes.

[Chuck Gomes] Agreed on the principle of separation policy development and the IFO and I think what I described in my previous comments above demonstrates clear separation but I am pretty sure that ICANN staff must give confirmation (instructions) that ICANN policy (in contrast to technical policy) has been satisfied regarding delegations or revocations. And I do not think that violates the principle of separating policy development from the IFO. I of course also agree that ³ICANN does not have the power to overrule national due processes² but I don¹t think that means that the IFO would be involved in interpreting national due process; isn¹t that ICANN¹s task?

MB: For ccTLDs, I do not see where this role is performed. I¹d also be alarmed at other ccTLDs (and hence non-nationals) having a say over a ccTLD.

...

...

I don¹t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed.

[Chuck Gomes] I think this is a correct statement as I have tried to describe above.

MB: The IANA functions operator¹s role is surely (again for ccTLDs) to ascertain that the decision for change has properly been made (and all other decisions can be automated anyway. But the disagreement is who does have the discretion to make those decisions.

The issue ­ and hence the complexity ­ is about who actually has the right to make the decisions and direct the IANA functions operator. The role of the IANA functions operator is to identify that a decision is appropriate ­ and the SOW gives some guidance to that, as does the work of the FOIWG. But it is absolutely not ICANN¹s decision.

[Chuck Gomes] From a technical point of view I agree but not beyond that. We would be getting into a very different situation if the IFO has to make decisions regarding whether ICANN policy or national due process is followed. That would mean that the IANA functions are much more than technical and clerical and it would require very different skills sets.

MB: the IANA functions operator (and the current ICANN Board) role is not to make the decision, but to verify that the decision is appropriate and correctly made.

Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not.

The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions. (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.) I do not think that I¹m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor.

[Chuck Gomes] I definitely do not think that ICANN should impose arbitrary conditions or question legitimate national decisions but I do not believe that that means that the IFO should make those decisions. If we have disagreement on this, then I think we need to have some serious discussions so that we are all on the same page.

MB: I am not arguing that the IANA functions operator makes the decisions. It is that the ICANN Board does not make decisions and give instructions.

Martin

From: Milton L Mueller [mailto:mueller@syr.edu <mailto:mueller@syr.edu> ] Sent: 30 April 2015 18:48 To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> ' Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Thanks for helping to highlight where you and I diverge, Milton. I¹d take changing the operator a lot more seriously than you!

MM: I don¹t think we actually do diverge on this issue, Martin. See below.

So whoever takes the IANA functions operator role will need to be aware of the back story and be able to command trust. It is not straight-forward and while I am sure there¹s a long list of people who would be able to update names, protocol parameters and the gTLD part of the TLD registries, I still struggle to think of who might be able to do the ccTLD piece and would also be generally trusted. (Clue ­ it is not a TLD or a consortium of TLDs.)

MM: The IANA Functions operator (IFO) should simply take ICANN¹s instructions. One benefit of a separated IFO would be the ability to more clearly separate those sensitive policy decisions that should really be made by ICANN, and those implementations that should be done by the IFO. I agree with you that ccTLD redelegations can be more sensitive than gTLD delegations, I don¹t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. Do you disagree?

_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://mm.icann.org/mailman/listinfo/cwg-stewardship>

Thanks Paul. I have learned a lot about ccTLDs in this CWG process. Chuck -----Original Message----- From: Paul M Kane - CWG [mailto:paul.kane-cwg@icb.co.uk] Sent: Tuesday, May 05, 2015 9:00 AM To: Gomes, Chuck Cc: Martin Boyle; Chris Disspain; cwg-stewardship@icann.org; elise.gerich@icann.org Subject: Re: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Morning Chuck I think we need to be very clear with regard to the roles and responsibilities of ICANN/IANA/gTLD/ccTLD Registry/National Framework... as outlined in my email dated 26/10/2014 @ 09:15 UTC - and nothing we propose should change that status. The ccTLD community falls into three groups. Those who have historically instructed IANA based on local consensus (see 1591 below), those that have contracts with ICANN that lay out the roles of each parties, and those who want ICANN to make decisions and hold the liability for that decision.

RFC-1591 is very specific on (re)delegations: 6) For any transfer of the designated manager trusteeship from one organization to another, the higher-level domain manager (the IANA in the case of top-level domains) must receive communications from both the old organization and the new organization that assure the IANA that the transfer in mutually agreed, and that the new organization understands its responsibilities.

It is also very helpful for the IANA to receive communications from other parties that may be concerned or affected by the transfer.

For the "independent" ccTLD operators (non-ccNSO Registry members), the incumbent and the new operator facilitate the transfer in accordance with the laws in which the Registry is incorporated - and advise IANA that technical stability can be assured. So the "liability" rests with the operators. There are some ccTLDs that are under contract with ICANN and they indemnify ICANN should they have agreed that ICANN should make a decision and ICANN informs IANA of their decision that the process has been followed. There are other operators without a contract invite ICANN (using policies that the ccNSO have developed) to make a decision with regard to redelegation and inform IANA as to the compliance with that Policy - and in so doing pass the liability for any stability issues to ICANN. Best Paul Quoting "Gomes, Chuck" <cgomes@verisign.com>:

I just received the clarification I needed on this from Bernie and Bart. The IANA do the due diligence to ensure that the local laws/community issues are satisfied for ccTLDs. I had mistakenly thought that that was done by ICANN staff and reported to the IANA team. For gTLDs I do not believe that the IANA team needs to do any policy checking but just need the confirmation from the GDD team that policy is in order.

I am fine with this. I see no problem at all that it is handled differently for gTLDs and ccTLDs. Also, if the ccTLD registries are fine with this, that is what matters.

Chuck, I’m not sure the IANA team interprets national due process, it just needs to see whether it has been carried out. National processes are dealt with locally and I do not think it is reasonable for the IANA team to be experts in every jurisdiction, but they also need to beware of trying to impose a solution: it tries to encourage local resolution of disputes. But you are perfectly correct – the SOW specifically requires the IANA functions operator to present its processes, so it would be good to hear from Elise to help us understand where decisions are made. Best Martin From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 03 May 2015 16:08 To: Martin Boyle; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad'; elise.gerich@icann.org Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Thanks Martin. Is it your understanding that the current IANA team interprets national due process and determines that it has been followed? If so, I would like find out whether the IANA team has the same understanding and also where in the process that happens. I added Elise to this thread hoping that she can respond. It is quite possible of course that my understanding of what happens is wrong. I definitely think we all need to be on the same page on this. Chuck From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Sent: Saturday, May 02, 2015 6:17 PM To: Gomes, Chuck; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Chuck, comments in line below. From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 01 May 2015 14:37 To: Martin Boyle; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Martin/Milton, Please note my understandings below. Chuck From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Sent: Friday, May 01, 2015 6:44 AM To: Milton L Mueller; Gomes, Chuck; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Obviously then I’m misunderstanding something Milton.

The IANA Functions operator (IFO) should simply take ICANN’s instructions. [Chuck Gomes] I think this is mostly accurate but I qualify that below.

Err, no! The IANA functions operator should base its decisions on agreed policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group. It also has advice from the GAC 2005 Principles. ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations. [Chuck Gomes] With regard to technical policy (i.e., Internet Standards), my understanding is that the IFO would check for compliance and does not need specific direction from ICANN in that regard so I think Martin is correct that the IFO doesn’t rely on ICANN’s instructions for its technical checks. But with regard to ccTLD delegations or revocations, I believe that a Board approval is required. I do not believe that the IFO is involved in any interpretation of ICANN policy; rather, ICANN staff confirms that ICANN policy has been followed. I know In the case of gTLDs, no Board action is needed for a delegation of a gTLD but ICANN staff confirms that GNSO policy has been followed before it ever gets to IANA involvement; it is not the IFO responsibility to do that. MB: I believe – and Chris Disspain has explained the role to the ccNSO and to others – the Board sees its role on delegations and revocations of ccTLDs as assessing a traffic-light report from the IANA functions operator staff: it is essentially a process and documentation check, although it could be used to approve a decision where strict adherence to policy (eg on engagement with interested parties in countries where this sort of approach is not carried out). In my mind it is not an instruction and the role could be done by a PTI Board which has responsibility for the provision of the IANA functions operator role. This is fundamental – clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions. And if I remember correctly this principle is clearly embodied in the SOW. And ICANN does not have the power to overrule national due processes. [Chuck Gomes] Agreed on the principle of separation policy development and the IFO and I think what I described in my previous comments above demonstrates clear separation but I am pretty sure that ICANN staff must give confirmation (instructions) that ICANN policy (in contrast to technical policy) has been satisfied regarding delegations or revocations. And I do not think that violates the principle of separating policy development from the IFO. I of course also agree that “ICANN does not have the power to overrule national due processes” but I don’t think that means that the IFO would be involved in interpreting national due process; isn’t that ICANN’s task? MB: For ccTLDs, I do not see where this role is performed. I’d also be alarmed at other ccTLDs (and hence non-nationals) having a say over a ccTLD.

I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. [Chuck Gomes] I think this is a correct statement as I have tried to describe above.

MB: The IANA functions operator’s role is surely (again for ccTLDs) to ascertain that the decision for change has properly been made (and all other decisions can be automated anyway. But the disagreement is who does have the discretion to make those decisions. The issue – and hence the complexity – is about who actually has the right to make the decisions and direct the IANA functions operator. The role of the IANA functions operator is to identify that a decision is appropriate – and the SOW gives some guidance to that, as does the work of the FOIWG. But it is absolutely not ICANN’s decision. [Chuck Gomes] From a technical point of view I agree but not beyond that. We would be getting into a very different situation if the IFO has to make decisions regarding whether ICANN policy or national due process is followed. That would mean that the IANA functions are much more than technical and clerical and it would require very different skills sets. MB: the IANA functions operator (and the current ICANN Board) role is not to make the decision, but to verify that the decision is appropriate and correctly made. Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not. The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions. (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.) I do not think that I’m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor. [Chuck Gomes] I definitely do not think that ICANN should impose arbitrary conditions or question legitimate national decisions but I do not believe that that means that the IFO should make those decisions. If we have disagreement on this, then I think we need to have some serious discussions so that we are all on the same page. MB: I am not arguing that the IANA functions operator makes the decisions. It is that the ICANN Board does not make decisions and give instructions. Martin From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 30 April 2015 18:48 To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May Thanks for helping to highlight where you and I diverge, Milton. I’d take changing the operator a lot more seriously than you! MM: I don’t think we actually do diverge on this issue, Martin. See below. So whoever takes the IANA functions operator role will need to be aware of the back story and be able to command trust. It is not straight-forward and while I am sure there’s a long list of people who would be able to update names, protocol parameters and the gTLD part of the TLD registries, I still struggle to think of who might be able to do the ccTLD piece and would also be generally trusted. (Clue – it is not a TLD or a consortium of TLDs.) MM: The IANA Functions operator (IFO) should simply take ICANN’s instructions. One benefit of a separated IFO would be the ability to more clearly separate those sensitive policy decisions that should really be made by ICANN, and those implementations that should be done by the IFO. I agree with you that ccTLD redelegations can be more sensitive than gTLD delegations, I don’t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. Do you disagree?

Martin explains it very well:

I¹m not sure the IANA team interprets national due process, it just needs to see whether it has been carried out. National processes are dealt with locally and I do not think it is reasonable for the IANA team to be experts in every jurisdiction, but they also need to beware of trying to impose a solution: it tries to encourage local resolution of disputes.

The documentation of the delegation and redelegation process is published on the iana.org website. http://www.iana.org/help/cctld-delegation Please let me know if I can be of further assistance. -- Elise From: Martin Boyle <Martin.Boyle@nominet.org.uk> Date: Monday, May 4, 2015 at 12:56 AM To: "Gomes, Chuck" <cgomes@verisign.com>, Milton L Mueller <mueller@syr.edu>, 'CW Lists' <lists@christopherwilkinson.eu>, Grace Abuhamad <grace.abuhamad@icann.org>, Elise Gerich <elise.gerich@icann.org> Cc: "'cwg-stewardship@icann.org'" <cwg-stewardship@icann.org> Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Chuck,

I¹m not sure the IANA team interprets national due process, it just needs to see whether it has been carried out. National processes are dealt with locally and I do not think it is reasonable for the IANA team to be experts in every jurisdiction, but they also need to beware of trying to impose a solution: it tries to encourage local resolution of disputes.

But you are perfectly correct ­ the SOW specifically requires the IANA functions operator to present its processes, so it would be good to hear from Elise to help us understand where decisions are made.

Best

Martin

From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 03 May 2015 16:08 To: Martin Boyle; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad'; elise.gerich@icann.org Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Thanks Martin. Is it your understanding that the current IANA team interprets national due process and determines that it has been followed? If so, I would like find out whether the IANA team has the same understanding and also where in the process that happens. I added Elise to this thread hoping that she can respond. It is quite possible of course that my understanding of what happens is wrong. I definitely think we all need to be on the same page on this.

Chuck

From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Sent: Saturday, May 02, 2015 6:17 PM To: Gomes, Chuck; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Chuck, comments in line below.

From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 01 May 2015 14:37 To: Martin Boyle; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Martin/Milton,

Please note my understandings below.

Chuck

From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Sent: Friday, May 01, 2015 6:44 AM To: Milton L Mueller; Gomes, Chuck; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Obviously then I¹m misunderstanding something Milton.

...

...

The IANA Functions operator (IFO) should simply take ICANN¹s instructions. [Chuck Gomes] I think this is mostly accurate but I qualify that below.

Err, no! The IANA functions operator should base its decisions on agreed policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group. It also has advice from the GAC 2005 Principles. ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations. [Chuck Gomes] With regard to technical policy (i.e., Internet Standards), my understanding is that the IFO would check for compliance and does not need specific direction from ICANN in that regard so I think Martin is correct that the IFO doesn¹t rely on ICANN¹s instructions for its technical checks. But with regard to ccTLD delegations or revocations, I believe that a Board approval is required. I do not believe that the IFO is involved in any interpretation of ICANN policy; rather, ICANN staff confirms that ICANN policy has been followed. I know In the case of gTLDs, no Board action is needed for a delegation of a gTLD but ICANN staff confirms that GNSO policy has been followed before it ever gets to IANA involvement; it is not the IFO responsibility to do that.

MB: I believe ­ and Chris Disspain has explained the role to the ccNSO and to others ­ the Board sees its role on delegations and revocations of ccTLDs as assessing a traffic-light report from the IANA functions operator staff: it is essentially a process and documentation check, although it could be used to approve a decision where strict adherence to policy (eg on engagement with interested parties in countries where this sort of approach is not carried out). In my mind it is not an instruction and the role could be done by a PTI Board which has responsibility for the provision of the IANA functions operator role.

This is fundamental ­ clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions. And if I remember correctly this principle is clearly embodied in the SOW. And ICANN does not have the power to overrule national due processes. [Chuck Gomes] Agreed on the principle of separation policy development and the IFO and I think what I described in my previous comments above demonstrates clear separation but I am pretty sure that ICANN staff must give confirmation (instructions) that ICANN policy (in contrast to technical policy) has been satisfied regarding delegations or revocations. And I do not think that violates the principle of separating policy development from the IFO. I of course also agree that ³ICANN does not have the power to overrule national due processes² but I don¹t think that means that the IFO would be involved in interpreting national due process; isn¹t that ICANN¹s task?

MB: For ccTLDs, I do not see where this role is performed. I¹d also be alarmed at other ccTLDs (and hence non-nationals) having a say over a ccTLD.

...

...

I don¹t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. [Chuck Gomes] I think this is a correct statement as I have tried to describe above.

MB: The IANA functions operator¹s role is surely (again for ccTLDs) to ascertain that the decision for change has properly been made (and all other decisions can be automated anyway. But the disagreement is who does have the discretion to make those decisions.

The issue ­ and hence the complexity ­ is about who actually has the right to make the decisions and direct the IANA functions operator. The role of the IANA functions operator is to identify that a decision is appropriate ­ and the SOW gives some guidance to that, as does the work of the FOIWG. But it is absolutely not ICANN¹s decision. [Chuck Gomes] From a technical point of view I agree but not beyond that. We would be getting into a very different situation if the IFO has to make decisions regarding whether ICANN policy or national due process is followed. That would mean that the IANA functions are much more than technical and clerical and it would require very different skills sets.

MB: the IANA functions operator (and the current ICANN Board) role is not to make the decision, but to verify that the decision is appropriate and correctly made.

Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not.

The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions. (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.) I do not think that I¹m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor. [Chuck Gomes] I definitely do not think that ICANN should impose arbitrary conditions or question legitimate national decisions but I do not believe that that means that the IFO should make those decisions. If we have disagreement on this, then I think we need to have some serious discussions so that we are all on the same page.

MB: I am not arguing that the IANA functions operator makes the decisions. It is that the ICANN Board does not make decisions and give instructions.

Martin

From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 30 April 2015 18:48 To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May

Thanks for helping to highlight where you and I diverge, Milton. I¹d take changing the operator a lot more seriously than you!

MM: I don¹t think we actually do diverge on this issue, Martin. See below.

So whoever takes the IANA functions operator role will need to be aware of the back story and be able to command trust. It is not straight-forward and while I am sure there¹s a long list of people who would be able to update names, protocol parameters and the gTLD part of the TLD registries, I still struggle to think of who might be able to do the ccTLD piece and would also be generally trusted. (Clue ­ it is not a TLD or a consortium of TLDs.)

MM: The IANA Functions operator (IFO) should simply take ICANN¹s instructions. One benefit of a separated IFO would be the ability to more clearly separate those sensitive policy decisions that should really be made by ICANN, and those implementations that should be done by the IFO. I agree with you that ccTLD redelegations can be more sensitive than gTLD delegations, I don¹t think the IFO should have discretion to make those decisions, it should simply edit the zone file as directed. Do you disagree?

From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Boyle: Obviously then I’m misunderstanding something Milton. MM: You are.

The IANA Functions operator (IFO) should simply take ICANN’s instructions.

Boyle: Err, no! The IANA functions operator should base its decisions on agreed policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group. MM: which is part of the ccNSO, which is part of….ICANN. Or are you asserting it is part of IANA? Boyle: It also has advice from the GAC 2005 Principles. MM: GAC is part of….ICANN. Or are you asserting it is part of IANA? Boyle: ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations. MM: This is where the misunderstanding resides. When I said “ICANN” I meant the policy-making side of the ICANN/IANA split, which includes not just the board, but the policy making entities such as ccNSO, GNSO, the ACs. When I say IANA “takes instructions” there could still be ambiguities about the exact way in which those instructions are issued, and by whom, and when, but clarifying that is one of the virtues of separation. I think we both agree that once a policy is set, IFO should implement it, and that IFO does not make the policy or have discretion as to whether to implement it. Boyle: This is fundamental – clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions. MM: Agreed. My goal is precisely the clear separation of policy and the IFO. This should be clear. Boyle: The issue – and hence the complexity – is about who actually has the right to make the decisions and direct the IANA functions operator. The role of the IANA functions operator is to identify that a decision is appropriate – and the SOW gives some guidance to that, as does the work of the FOIWG. But it is absolutely not ICANN’s decision. Boyle: Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not. The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions. (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.) I do not think that I’m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor. MM: I think it’s clear from this exchange that you are failing to understand my point, and you are overreacting - it’s not me failing to understand the risk of arbitrary and high-handed actions by ICANN. Really, that’s a pretty insulting and uninformed assertion for you to make, given my role in analysing and leading attempts to reform the accountability problems at ICANN. MM: As for “starting this learning process over with a new contractor,” the learning process has to take place on the ICANN side of the divide, not at the IANA contractor, and be reflected in the ICANN-IFO contract. The problems you mention have occurred precisely because IANA has been a wholly controlled department of the ICANN board. Any contract between ICANN and an IFO could and should clearly account for the concerns you have and make sure that ICANN’s board cannot issue “instructions” that are not authorized or approved by the proper parties on the policy making side of the divide. --MM

Whilst I might use slightly different terminology, + 1 to Martin. Cheers, Chris Disspain | Chief Executive Officer .au Domain Administration Ltd T: +61 3 8341 4111 | F: +61 3 8341 4112 E: ceo@auda.org.au | W: www.auda.org.au auDA – Australia’s Domain Name Administrator Important Notice - This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately. Please consider the environment before printing this email. On 3 May 2015, at 07:54 , Martin Boyle <Martin.Boyle@nominet.org.uk> wrote:

So Milton: In spite of your analysis of my concerns, I still do not agree. In your defence of your assertions, you continue to miss my point completely.

For ccTLDs, ICANN’s sole role is to provide the framework for policy development. (Caveat: as Paul Kane would note, actually only for those ccTLDs that were members of the ccNSO. And actually the policy document did not come from ICANN anyway.) It is the IANA functions operator’s obligation to base its decisions on the policy in place – as identified below.

In making its decisions:

· Neither the ccNSO nor the GAC has any say over the decisions except in that they might (I suppose – to my knowledge this has never happened) raise questions with the Board about conformity to policy). In particular, I would hope that GAC members (in line with paragraph 63 of the Tunis Agenda) would not see it as their role to comment – it would be interfering with a country’s national sovereignty.

· The current Board view (and one that I feel greatly comfortable with) is that its role is simply to ensure that due process has been followed and documented. It uses a traffic-light metric and recognises that there might be different interpretations (for example on how multi-stakeholder engagement takes place). In essence and for national sovereignty reasons, any role for the Board is simply to assure itself that the decision has been properly made. It has taken us a long time to get there, and I do not want to see us return to ICANN having a decision making role for ccTLD delegations: been there and it doesn’t work.

· All the analysis, document checking, evaluation, discussion with the interested parties in a ccTLD amendment is currently carried out by the IANA functions operator. I failed to notice where we decided that the PTI as new IANA functions operator would only do the clerical and technical bit and I would love to know who does the detailed work in the new model. It seems to leave behind in ICANN a key IANA functions operator role in the existing model.

You can claim indignation all you like, but you still do not address my concerns about the appropriateness of your model of ICANN Board instructions for ccTLDs. I stand to be corrected, but I’m not convinced yet.

As for your interpretation of the new model: if this is right, then Nominet for one will not be able to accept the current proposal. I suspect other ccTLDs will have similar problems. Incidentally, I seriously wonder why we have put all this effort in on separability if the only thing we are able to separate is the mechanical bit (which could all be done automatically).

The learning process has taken place on the ICANN side of the divide over the years. ICANN is currently the IANA contractor and the learning is also in place in the IANA team. I’ve given no thought to date about who validates changes – up to now I’ve assumed it would be the PTI Board as responsible for the IANA functions operator’s work. Placing it elsewhere gives me two concerns:

1. The validation body (remember that we’ve agreed there should not be an authorisation function in the new model) is the responsible agent: if it is in ICANN we cannot hold PTI responsible for any failure.

2. The validation body operates a gatekeeper function outside the direct surveillance of the mechanisms we have been discussing for so long. We will have additional work to make pretty clear what the limitations of that function actually are: I think it should only be able to refer decisions back to the IANA functions operator (the operational team) on the basis that the process has not been followed or that the necessary documentation is not present or correct.

So I’m still unconvinced by your arguments. They might work for gTLDs – and I’m happy for existing arrangements for gTLDs to stay in place. But I don’t think what you assert works for ccTLDs,

Martin

From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 01 May 2015 14:53 To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May

From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk]

Boyle: Obviously then I’m misunderstanding something Milton.

MM: You are.

...

The IANA Functions operator (IFO) should simply take ICANN’s instructions.

Boyle: Err, no! The IANA functions operator should base its decisions on agreed policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group.

MM: which is part of the ccNSO, which is part of….ICANN. Or are you asserting it is part of IANA?

Boyle: It also has advice from the GAC 2005 Principles.

MM: GAC is part of….ICANN. Or are you asserting it is part of IANA?

Boyle: ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations.

MM: This is where the misunderstanding resides. When I said “ICANN” I meant the policy-making side of the ICANN/IANA split, which includes not just the board, but the policy making entities such as ccNSO, GNSO, the ACs. When I say IANA “takes instructions” there could still be ambiguities about the exact way in which those instructions are issued, and by whom, and when, but clarifying that is one of the virtues of separation. I think we both agree that once a policy is set, IFO should implement it, and that IFO does not make the policy or have discretion as to whether to implement it.

Boyle: This is fundamental – clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions.

MM: Agreed. My goal is precisely the clear separation of policy and the IFO. This should be clear.

Boyle: The issue – and hence the complexity – is about who actually has the right to make the decisions and direct the IANA functions operator. The role of the IANA functions operator is to identify that a decision is appropriate – and the SOW gives some guidance to that, as does the work of the FOIWG. But it is absolutely not ICANN’s decision.

Boyle: Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not. The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions. (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.) I do not think that I’m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor.

MM: I think it’s clear from this exchange that you are failing to understand my point, and you are overreacting - it’s not me failing to understand the risk of arbitrary and high-handed actions by ICANN. Really, that’s a pretty insulting and uninformed assertion for you to make, given my role in analysing and leading attempts to reform the accountability problems at ICANN.

MM: As for “starting this learning process over with a new contractor,” the learning process has to take place on the ICANN side of the divide, not at the IANA contractor, and be reflected in the ICANN-IFO contract. The problems you mention have occurred precisely because IANA has been a wholly controlled department of the ICANN board. Any contract between ICANN and an IFO could and should clearly account for the concerns you have and make sure that ICANN’s board cannot issue “instructions” that are not authorized or approved by the proper parties on the policy making side of the divide.

--MM

_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship

In UK English, instructions tell someone what to do. So alternative wording is needed, if there is a difference between US and UK usage. Currently the ICANN Board plays a role of (what I would see as) due diligence for its operational team. It is not included in the SOW, but, on a critical function where its reputation is on the line, I could imagine it would want to check that staff had done their job and there would be no come-back on ICANN. But I do not see it as an instruction, so different wording is needed. As I said last night, I do not understand why, in introducing legal separation, we would split the role between subsidiary and parent company. I’ve not heard any clear reasoning as to why it would be appropriate and I would see a clear issue of accountability associated with this split function. It is not a failing of the PTI if the ICANN Board screws up. Moving the PTI to a new operator doesn’t solve the problem. People can only be held accountable for things they can do something about. On separability, I said in an e-mail early in this thread that “Our objective in oversight of the operation of the IANA functions should be to ensure as near a self-healing process as we can get… If … we end up with a failing IANA functions operator…, we need to be able to find a solution and implement it quickly.” By this I mean, we should try to make the system work (and take some time to do this to avoid disruption), but if it is failing and won’t reform we need to respond and separate quickly. For reasons that we’ve now discussed at length, I feel nervous about turning over the knowledge of ccTLD issues without first taking the obvious action of seeking to remedy defects. I am sure my threshold is higher than yours, but from a TLD point, stability is important. However, once a consensus decision has been made, I oppose making separation inordinately difficult. Hope this helps clarify my position. I have a question back to you on gTLDs: doesn’t the ICANN Board have a different (operational) role given that gTLDs are in a contractual relationship with ICANN? No contract, no IANA entry? So it would be quite appropriate for the ICANN Board to instruct the PTI to act, wouldn’t it? And the PTI might (as I believe is currently the case) expect to see a similar checklist of meeting terms and conditions. In my mind, accountability for a decision badly made would be with the ICANN Board (especially if it lied in the checklist). The counterpart to that is that the PTI Board could refuse an instruction on the grounds that it was not sufficiently documented. MB From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 03 May 2015 22:33 To: Martin Boyle; 'Gomes, Chuck' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May OK. I think I understand better now. What set you off, apparently, was the word “instructions” which you mistakenly interpreted to mean: the ICANN board unilaterally makes delegation decisions for ccTLDs. This is not what I meant at all, and I am pretty sure it’s not what Chuck is looking for either. I note that you had to admit that the ICANN board _does_ play a role in “ensur[ing] that due process has been followed and documented.” Some of us would call that an approval role, something akin to the NTIA’s authorization role. At the end of that process, I assume, it issues some kind of decision, approval, or statement, which may be no more than “go ahead and do what you proposed to do.” It would be perfectly reasonable to use the word “instruction” for that, but if the word scares you I’ll use another. “Due process check”? “approval”? (As an aside, some of us fervently wish that the board had the same limited role with respect to GNSO policies.) I understand better now your point about how the institutional environment around ICANN had to be “educated” to accept a method of making delegation decisions with a very limited role for the ICANN board (a view with which I am in violent agreement). And I think we are all sensitive to the need to do this in ways that avoid allowing governments to interfere with the ccTLD associated with another government. You have admitted that ICANN (not the board, but the community in the broader sense) “provides the framework for policy development.” But you have clarified the way in which the IANA staff _apply_ that framework, subject to a board-level “traffic light metric,” and it is clear that this is more than clerical. I have no problem with PTI continuing in that role. I am not sure why these very subtle distinctions would create such indignation and fear on your part; I think it’s constructive for these things to be teased out more carefully and taken into consideration in designing PTI. I don’t agree with you, however, that this means that separability should be discouraged or made inordinately difficult. And if you’ll recall, that issue (ease of changing operators) was what initially provoked the controversy. The fact that ICANN and the community around cc’s has reached an acceptable and somewhat intricate balance around how to do delegations does not mean that the right to change IANA function operator should be mitigated or made extremely difficult. This is a non-sequitur. To begin with, the knowledge is there now and is accepted politically. While it may have been difficult to establish the right way to do redelegations over the course of the past 15 years, those methods are accepted and applied broadly now. Hence, it would not be that difficult to recreate them in a new operator and formalize them in a SLA. Indeed, it might be a good idea to formalize the current procedure more, in the form of a contract or SLA with PTI, precisely so that maintenance of the methods that are so important to you is not completely reliant on the institutional memory of a single entity (the current IANA department). Perhaps the ccNSO should have its own SLA with PTI, just as the address and protocols do. Making these things more explicit would reduce the community’s reliance on a single operator. Second, no one would want to change IFOs unless something were going seriously wrong. If things are going wrong, it’s a bad idea to make it highly difficult to effectuate a change. Indeed, one of the things that might go wrong is that the IFO might start deviating from what you and other ccTLD operators consider proper procedure. To summarize, I don’t think your view of the role of PTI is inconsistent with mine; I do think that your conservatism regarding a change in the IFO is unwarranted by any logic or argument you’ve made, and could easily backfire on you/other ccTLDs. --MM From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] For ccTLDs, ICANN’s sole role is to provide the framework for policy development. (Caveat: as Paul Kane would note, actually only for those ccTLDs that were members of the ccNSO. And actually the policy document did not come from ICANN anyway.) It is the IANA functions operator’s obligation to base its decisions on the policy in place – as identified below. In making its decisions: • Neither the ccNSO nor the GAC has any say over the decisions except in that they might (I suppose – to my knowledge this has never happened) raise questions with the Board about conformity to policy). In particular, I would hope that GAC members (in line with paragraph 63 of the Tunis Agenda) would not see it as their role to comment – it would be interfering with a country’s national sovereignty. • The current Board view (and one that I feel greatly comfortable with) is that its role is simply to ensure that due process has been followed and documented. It uses a traffic-light metric and recognises that there might be different interpretations (for example on how multi-stakeholder engagement takes place). In essence and for national sovereignty reasons, any role for the Board is simply to assure itself that the decision has been properly made. It has taken us a long time to get there, and I do not want to see us return to ICANN having a decision making role for ccTLD delegations: been there and it doesn’t work. • All the analysis, document checking, evaluation, discussion with the interested parties in a ccTLD amendment is currently carried out by the IANA functions operator. I failed to notice where we decided that the PTI as new IANA functions operator would only do the clerical and technical bit and I would love to know who does the detailed work in the new model. It seems to leave behind in ICANN a key IANA functions operator role in the existing model. You can claim indignation all you like, but you still do not address my concerns about the appropriateness of your model of ICANN Board instructions for ccTLDs. I stand to be corrected, but I’m not convinced yet. As for your interpretation of the new model: if this is right, then Nominet for one will not be able to accept the current proposal. I suspect other ccTLDs will have similar problems. Incidentally, I seriously wonder why we have put all this effort in on separability if the only thing we are able to separate is the mechanical bit (which could all be done automatically). The learning process has taken place on the ICANN side of the divide over the years. ICANN is currently the IANA contractor and the learning is also in place in the IANA team. I’ve given no thought to date about who validates changes – up to now I’ve assumed it would be the PTI Board as responsible for the IANA functions operator’s work. Placing it elsewhere gives me two concerns: 1. The validation body (remember that we’ve agreed there should not be an authorisation function in the new model) is the responsible agent: if it is in ICANN we cannot hold PTI responsible for any failure. 2. The validation body operates a gatekeeper function outside the direct surveillance of the mechanisms we have been discussing for so long. We will have additional work to make pretty clear what the limitations of that function actually are: I think it should only be able to refer decisions back to the IANA functions operator (the operational team) on the basis that the process has not been followed or that the necessary documentation is not present or correct. So I’m still unconvinced by your arguments. They might work for gTLDs – and I’m happy for existing arrangements for gTLDs to stay in place. But I don’t think what you assert works for ccTLDs, Martin From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 01 May 2015 14:53 To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Boyle: Obviously then I’m misunderstanding something Milton. MM: You are.

The IANA Functions operator (IFO) should simply take ICANN’s instructions.

Boyle: Err, no! The IANA functions operator should base its decisions on agreed policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group. MM: which is part of the ccNSO, which is part of….ICANN. Or are you asserting it is part of IANA? Boyle: It also has advice from the GAC 2005 Principles. MM: GAC is part of….ICANN. Or are you asserting it is part of IANA? Boyle: ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations. MM: This is where the misunderstanding resides. When I said “ICANN” I meant the policy-making side of the ICANN/IANA split, which includes not just the board, but the policy making entities such as ccNSO, GNSO, the ACs. When I say IANA “takes instructions” there could still be ambiguities about the exact way in which those instructions are issued, and by whom, and when, but clarifying that is one of the virtues of separation. I think we both agree that once a policy is set, IFO should implement it, and that IFO does not make the policy or have discretion as to whether to implement it. Boyle: This is fundamental – clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions. MM: Agreed. My goal is precisely the clear separation of policy and the IFO. This should be clear. Boyle: The issue – and hence the complexity – is about who actually has the right to make the decisions and direct the IANA functions operator. The role of the IANA functions operator is to identify that a decision is appropriate – and the SOW gives some guidance to that, as does the work of the FOIWG. But it is absolutely not ICANN’s decision. Boyle: Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not. The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions. (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.) I do not think that I’m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor. MM: I think it’s clear from this exchange that you are failing to understand my point, and you are overreacting - it’s not me failing to understand the risk of arbitrary and high-handed actions by ICANN. Really, that’s a pretty insulting and uninformed assertion for you to make, given my role in analysing and leading attempts to reform the accountability problems at ICANN. MM: As for “starting this learning process over with a new contractor,” the learning process has to take place on the ICANN side of the divide, not at the IANA contractor, and be reflected in the ICANN-IFO contract. The problems you mention have occurred precisely because IANA has been a wholly controlled department of the ICANN board. Any contract between ICANN and an IFO could and should clearly account for the concerns you have and make sure that ICANN’s board cannot issue “instructions” that are not authorized or approved by the proper parties on the policy making side of the divide. --MM