Accountability measures required by CWG Proposal(s)
I believe that this is the minimalist list of accountability measures or accountability-related processes that would be required based on the two proposals currently under consideration. I have explicitly not included the wider list of measures that the CCWG is considering for possible inclusion in its WS1, specifically those which the community would like to see and for which the IANA transition might provide additional impetus for the Board to approve, but are not absolutely required to ensure that the IANA transition can occur. I recognize that this is a judgement call that not all might agree with. During the last of the four weekend meetings, Chuck mentioned one additional issue, and referred to a chat exchange between him and Donna during the third meeting that listed several other potential accountability issues. Unfortunately, that chat transcript was not preserved due to an error in saving it. The list of measures for the Contract Co. model is based on the list that the Co-Chairs created in December, augmented by Chucks suggestion. I do not believe that the December list has been negated by any work done in the interim, but perhaps I have missed something. I could not find a rationale for the inclusion of the first of the three items, but include it here so that the CWG could decide if it is based on a real need associated with the proposal or not. If included, I would suggest the CWG be more specific as to under what conditions it would apply. Chuck's suggestion seems to conflict with the 2nd measure in that the 2nd measure is specified as being binding. I am also not sure if it could possibly be replaced by the more generalized IAP (once the request goes to IANA). The requirements for the internal-to-ICANN model are based on my discussions with a number of people over the last weeks. Contract Co. Model Requirements 1. Independent Review of Board Actions Change the ICANN Bylaws to specify that under certain circumstances (to be defined) the determinations of an Independent Review of Board Actions Panel would be binding and not implemented at the Board's discretions. 2. Independent certification for delegation and re-delegation requests This would be a replacement for the authorization function for all changes to the Root Zone or its WHOIS Database currently performed by the NTIA. The replacement mechanism would have gTLD requests for delegations and re-delegations authorized by an independent third party and its decision on these matters would be binding on ICANN/IANA. 3. Independent Appeals Panel An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process. 4. gTLD Delegation or Redelegation Appeal within ICANN prior to the change request going to IANA A Registry could appeal an ICANN decision to delegate or redelegate and gTLD, based on policy not being followed (or presumably contractual terms not being followed). Internal-To-ICANN Model Requirements This model will require all of the above measures plus the following: 5. Control over ICANN Board decisions. The ability for ICANN Stakeholders, potentially augmented by other non-ICANN entities, to mandate or overrule, a particular Board decision, or to require that the implementation of such a decision be subject to consideration of an independent, binding review. These measures might need to be augmented by advance notice of such decisions and allow the MS community to react. In the most restricted form, this ability might be restricted to decisions related to IANA, but in reality, it may not be practical to define this scope limitation (ie how to recognize an IANA-related decision). 6. Ability to Remove Directors The ability of the overall multi-stakeholder community to remove some or all of the Board Directors. In the case of a full Board removal, a mechanism would be required for appointing an Interim Board and then a replacement regular Board. In addition, ACs and SOs could be given the right to recall their appointed Director(s).
Apologies Alan, I missed this when drafting my earlier email. Jonathan From: Alan Greenberg [mailto:alan.greenberg@mcgill.ca] Sent: 15 January 2015 06:12 To: CWG IANA Subject: [CWG-Stewardship] Accountability measures required by CWG Proposal(s) I believe that this is the minimalist list of accountability measures or accountability-related processes that would be required based on the two proposals currently under consideration. I have explicitly not included the wider list of measures that the CCWG is considering for possible inclusion in its WS1, specifically those which the community would like to see and for which the IANA transition might provide additional impetus for the Board to approve, but are not absolutely required to ensure that the IANA transition can occur. I recognize that this is a judgement call that not all might agree with. During the last of the four weekend meetings, Chuck mentioned one additional issue, and referred to a chat exchange between him and Donna during the third meeting that listed several other potential accountability issues. Unfortunately, that chat transcript was not preserved due to an error in saving it. The list of measures for the Contract Co. model is based on the list that the Co-Chairs created in December, augmented by Chucks suggestion. I do not believe that the December list has been negated by any work done in the interim, but perhaps I have missed something. I could not find a rationale for the inclusion of the first of the three items, but include it here so that the CWG could decide if it is based on a real need associated with the proposal or not. If included, I would suggest the CWG be more specific as to under what conditions it would apply. Chuck's suggestion seems to conflict with the 2nd measure in that the 2nd measure is specified as being binding. I am also not sure if it could possibly be replaced by the more generalized IAP (once the request goes to IANA). The requirements for the internal-to-ICANN model are based on my discussions with a number of people over the last weeks. Contract Co. Model Requirements 1. Independent Review of Board Actions Change the ICANN Bylaws to specify that under certain circumstances (to be defined) the determinations of an Independent Review of Board Actions Panel would be binding and not implemented at the Board's discretions. 2. Independent certification for delegation and re-delegation requests This would be a replacement for the authorization function for all changes to the Root Zone or its WHOIS Database currently performed by the NTIA. The replacement mechanism would have gTLD requests for delegations and re-delegations authorized by an independent third party and its decision on these matters would be binding on ICANN/IANA. 3. Independent Appeals Panel An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process. 4. gTLD Delegation or Redelegation Appeal within ICANN prior to the change request going to IANA A Registry could appeal an ICANN decision to delegate or redelegate and gTLD, based on policy not being followed (or presumably contractual terms not being followed). Internal-To-ICANN Model Requirements This model will require all of the above measures plus the following: 5. Control over ICANN Board decisions. The ability for ICANN Stakeholders, potentially augmented by other non-ICANN entities, to mandate or overrule, a particular Board decision, or to require that the implementation of such a decision be subject to consideration of an independent, binding review. These measures might need to be augmented by advance notice of such decisions and allow the MS community to react. In the most restricted form, this ability might be restricted to decisions related to IANA, but in reality, it may not be practical to define this scope limitation (ie how to recognize an IANA-related decision). 6. Ability to Remove Directors The ability of the overall multi-stakeholder community to remove some or all of the Board Directors. In the case of a full Board removal, a mechanism would be required for appointing an Interim Board and then a replacement regular Board. In addition, ACs and SOs could be given the right to recall their appointed Director(s).
Alan (and the CWG), One question that strikes me which we will almost certainly be asked to clarify is; What is the problem/issue that you (we) are trying to solve for in each case? The purpose for establishing the motivation is that it may be that there is more than one remedy and that one remedy is more desirable than another (for whatever reason including but not limited to legal advice). Perhaps a table in the form of issue / proposed resolution 1 / proposed resolution 2? Jonathan From: Alan Greenberg [mailto:alan.greenberg@mcgill.ca] Sent: 15 January 2015 06:12 To: CWG IANA Subject: [CWG-Stewardship] Accountability measures required by CWG Proposal(s) I believe that this is the minimalist list of accountability measures or accountability-related processes that would be required based on the two proposals currently under consideration. I have explicitly not included the wider list of measures that the CCWG is considering for possible inclusion in its WS1, specifically those which the community would like to see and for which the IANA transition might provide additional impetus for the Board to approve, but are not absolutely required to ensure that the IANA transition can occur. I recognize that this is a judgement call that not all might agree with. During the last of the four weekend meetings, Chuck mentioned one additional issue, and referred to a chat exchange between him and Donna during the third meeting that listed several other potential accountability issues. Unfortunately, that chat transcript was not preserved due to an error in saving it. The list of measures for the Contract Co. model is based on the list that the Co-Chairs created in December, augmented by Chucks suggestion. I do not believe that the December list has been negated by any work done in the interim, but perhaps I have missed something. I could not find a rationale for the inclusion of the first of the three items, but include it here so that the CWG could decide if it is based on a real need associated with the proposal or not. If included, I would suggest the CWG be more specific as to under what conditions it would apply. Chuck's suggestion seems to conflict with the 2nd measure in that the 2nd measure is specified as being binding. I am also not sure if it could possibly be replaced by the more generalized IAP (once the request goes to IANA). The requirements for the internal-to-ICANN model are based on my discussions with a number of people over the last weeks. Contract Co. Model Requirements 1. Independent Review of Board Actions Change the ICANN Bylaws to specify that under certain circumstances (to be defined) the determinations of an Independent Review of Board Actions Panel would be binding and not implemented at the Board's discretions. 2. Independent certification for delegation and re-delegation requests This would be a replacement for the authorization function for all changes to the Root Zone or its WHOIS Database currently performed by the NTIA. The replacement mechanism would have gTLD requests for delegations and re-delegations authorized by an independent third party and its decision on these matters would be binding on ICANN/IANA. 3. Independent Appeals Panel An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process. 4. gTLD Delegation or Redelegation Appeal within ICANN prior to the change request going to IANA A Registry could appeal an ICANN decision to delegate or redelegate and gTLD, based on policy not being followed (or presumably contractual terms not being followed). Internal-To-ICANN Model Requirements This model will require all of the above measures plus the following: 5. Control over ICANN Board decisions. The ability for ICANN Stakeholders, potentially augmented by other non-ICANN entities, to mandate or overrule, a particular Board decision, or to require that the implementation of such a decision be subject to consideration of an independent, binding review. These measures might need to be augmented by advance notice of such decisions and allow the MS community to react. In the most restricted form, this ability might be restricted to decisions related to IANA, but in reality, it may not be practical to define this scope limitation (ie how to recognize an IANA-related decision). 6. Ability to Remove Directors The ability of the overall multi-stakeholder community to remove some or all of the Board Directors. In the case of a full Board removal, a mechanism would be required for appointing an Interim Board and then a replacement regular Board. In addition, ACs and SOs could be given the right to recall their appointed Director(s).
All, Note the reference that Fadi has very recently made to the possible use of an over-arching conditionality (in the CWG proposal) in the form of a "poison pill" i.e. our (CWG) proposal being invalid unless certain key accountability conditions are met. Jonathan From: Jonathan Robinson [mailto:jrobinson@afilias.info] Sent: 15 January 2015 12:46 To: 'Alan Greenberg'; 'CWG IANA' Subject: RE: [CWG-Stewardship] Accountability measures required by CWG Proposal(s) Alan (and the CWG), One question that strikes me which we will almost certainly be asked to clarify is; What is the problem/issue that you (we) are trying to solve for in each case? The purpose for establishing the motivation is that it may be that there is more than one remedy and that one remedy is more desirable than another (for whatever reason including but not limited to legal advice). Perhaps a table in the form of issue / proposed resolution 1 / proposed resolution 2? Jonathan From: Alan Greenberg [mailto:alan.greenberg@mcgill.ca] Sent: 15 January 2015 06:12 To: CWG IANA Subject: [CWG-Stewardship] Accountability measures required by CWG Proposal(s) I believe that this is the minimalist list of accountability measures or accountability-related processes that would be required based on the two proposals currently under consideration. I have explicitly not included the wider list of measures that the CCWG is considering for possible inclusion in its WS1, specifically those which the community would like to see and for which the IANA transition might provide additional impetus for the Board to approve, but are not absolutely required to ensure that the IANA transition can occur. I recognize that this is a judgement call that not all might agree with. During the last of the four weekend meetings, Chuck mentioned one additional issue, and referred to a chat exchange between him and Donna during the third meeting that listed several other potential accountability issues. Unfortunately, that chat transcript was not preserved due to an error in saving it. The list of measures for the Contract Co. model is based on the list that the Co-Chairs created in December, augmented by Chucks suggestion. I do not believe that the December list has been negated by any work done in the interim, but perhaps I have missed something. I could not find a rationale for the inclusion of the first of the three items, but include it here so that the CWG could decide if it is based on a real need associated with the proposal or not. If included, I would suggest the CWG be more specific as to under what conditions it would apply. Chuck's suggestion seems to conflict with the 2nd measure in that the 2nd measure is specified as being binding. I am also not sure if it could possibly be replaced by the more generalized IAP (once the request goes to IANA). The requirements for the internal-to-ICANN model are based on my discussions with a number of people over the last weeks. Contract Co. Model Requirements 1. Independent Review of Board Actions Change the ICANN Bylaws to specify that under certain circumstances (to be defined) the determinations of an Independent Review of Board Actions Panel would be binding and not implemented at the Board's discretions. 2. Independent certification for delegation and re-delegation requests This would be a replacement for the authorization function for all changes to the Root Zone or its WHOIS Database currently performed by the NTIA. The replacement mechanism would have gTLD requests for delegations and re-delegations authorized by an independent third party and its decision on these matters would be binding on ICANN/IANA. 3. Independent Appeals Panel An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process. 4. gTLD Delegation or Redelegation Appeal within ICANN prior to the change request going to IANA A Registry could appeal an ICANN decision to delegate or redelegate and gTLD, based on policy not being followed (or presumably contractual terms not being followed). Internal-To-ICANN Model Requirements This model will require all of the above measures plus the following: 5. Control over ICANN Board decisions. The ability for ICANN Stakeholders, potentially augmented by other non-ICANN entities, to mandate or overrule, a particular Board decision, or to require that the implementation of such a decision be subject to consideration of an independent, binding review. These measures might need to be augmented by advance notice of such decisions and allow the MS community to react. In the most restricted form, this ability might be restricted to decisions related to IANA, but in reality, it may not be practical to define this scope limitation (ie how to recognize an IANA-related decision). 6. Ability to Remove Directors The ability of the overall multi-stakeholder community to remove some or all of the Board Directors. In the case of a full Board removal, a mechanism would be required for appointing an Interim Board and then a replacement regular Board. In addition, ACs and SOs could be given the right to recall their appointed Director(s).
Jonathan, I do not understand the 'poison pill' point. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Jonathan Robinson Sent: Thursday, January 15, 2015 8:16 AM To: jrobinson@afilias.info; 'Alan Greenberg'; 'CWG IANA' Subject: Re: [CWG-Stewardship] Accountability measures required by CWG Proposal(s) All, Note the reference that Fadi has very recently made to the possible use of an over-arching conditionality (in the CWG proposal) in the form of a "poison pill" i.e. our (CWG) proposal being invalid unless certain key accountability conditions are met. Jonathan From: Jonathan Robinson [mailto:jrobinson@afilias.info]<mailto:[mailto:jrobinson@afilias.info]> Sent: 15 January 2015 12:46 To: 'Alan Greenberg'; 'CWG IANA' Subject: RE: [CWG-Stewardship] Accountability measures required by CWG Proposal(s) Alan (and the CWG), One question that strikes me which we will almost certainly be asked to clarify is; What is the problem/issue that you (we) are trying to solve for in each case? The purpose for establishing the motivation is that it may be that there is more than one remedy and that one remedy is more desirable than another (for whatever reason including but not limited to legal advice). Perhaps a table in the form of issue / proposed resolution 1 / proposed resolution 2? Jonathan From: Alan Greenberg [mailto:alan.greenberg@mcgill.ca] Sent: 15 January 2015 06:12 To: CWG IANA Subject: [CWG-Stewardship] Accountability measures required by CWG Proposal(s) I believe that this is the minimalist list of accountability measures or accountability-related processes that would be required based on the two proposals currently under consideration. I have explicitly not included the wider list of measures that the CCWG is considering for possible inclusion in its WS1, specifically those which the community would like to see and for which the IANA transition might provide additional impetus for the Board to approve, but are not absolutely required to ensure that the IANA transition can occur. I recognize that this is a judgement call that not all might agree with. During the last of the four weekend meetings, Chuck mentioned one additional issue, and referred to a chat exchange between him and Donna during the third meeting that listed several other potential accountability issues. Unfortunately, that chat transcript was not preserved due to an error in saving it. The list of measures for the Contract Co. model is based on the list that the Co-Chairs created in December, augmented by Chucks suggestion. I do not believe that the December list has been negated by any work done in the interim, but perhaps I have missed something. I could not find a rationale for the inclusion of the first of the three items, but include it here so that the CWG could decide if it is based on a real need associated with the proposal or not. If included, I would suggest the CWG be more specific as to under what conditions it would apply. Chuck's suggestion seems to conflict with the 2nd measure in that the 2nd measure is specified as being binding. I am also not sure if it could possibly be replaced by the more generalized IAP (once the request goes to IANA). The requirements for the internal-to-ICANN model are based on my discussions with a number of people over the last weeks. Contract Co. Model Requirements 1. Independent Review of Board Actions Change the ICANN Bylaws to specify that under certain circumstances (to be defined) the determinations of an Independent Review of Board Actions Panel would be binding and not implemented at the Board's discretions. 2. Independent certification for delegation and re-delegation requests This would be a replacement for the authorization function for all changes to the Root Zone or its WHOIS Database currently performed by the NTIA. The replacement mechanism would have gTLD requests for delegations and re-delegations authorized by an independent third party and its decision on these matters would be binding on ICANN/IANA. 3. Independent Appeals Panel An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process. 4. gTLD Delegation or Redelegation Appeal within ICANN prior to the change request going to IANA A Registry could appeal an ICANN decision to delegate or redelegate and gTLD, based on policy not being followed (or presumably contractual terms not being followed). Internal-To-ICANN Model Requirements This model will require all of the above measures plus the following: 5. Control over ICANN Board decisions. The ability for ICANN Stakeholders, potentially augmented by other non-ICANN entities, to mandate or overrule, a particular Board decision, or to require that the implementation of such a decision be subject to consideration of an independent, binding review. These measures might need to be augmented by advance notice of such decisions and allow the MS community to react. In the most restricted form, this ability might be restricted to decisions related to IANA, but in reality, it may not be practical to define this scope limitation (ie how to recognize an IANA-related decision). 6. Ability to Remove Directors The ability of the overall multi-stakeholder community to remove some or all of the Board Directors. In the case of a full Board removal, a mechanism would be required for appointing an Interim Board and then a replacement regular Board. In addition, ACs and SOs could be given the right to recall their appointed Director(s).
Thanks Chuck, I'll drop a note explaining further as soon as I get a moment. Jonathan On 15 Jan 2015 19:45, "Gomes, Chuck" <cgomes@verisign.com> wrote:
Jonathan,
I do not understand the ‘poison pill’ point.
Chuck
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Jonathan Robinson *Sent:* Thursday, January 15, 2015 8:16 AM *To:* jrobinson@afilias.info; 'Alan Greenberg'; 'CWG IANA' *Subject:* Re: [CWG-Stewardship] Accountability measures required by CWG Proposal(s)
All,
Note the reference that Fadi has very recently made to the possible use of an over-arching conditionality (in the CWG proposal) in the form of a “poison pill” i.e. our (CWG) proposal being invalid unless certain key accountability conditions are met.
Jonathan
*From:* Jonathan Robinson [mailto:jrobinson@afilias.info] *Sent:* 15 January 2015 12:46 *To:* 'Alan Greenberg'; 'CWG IANA' *Subject:* RE: [CWG-Stewardship] Accountability measures required by CWG Proposal(s)
Alan (and the CWG),
One question that strikes me which we will almost certainly be asked to clarify is; What is the problem/issue that you (we) are trying to solve for in each case?
The purpose for establishing the motivation is that it may be that there is more than one remedy and that one remedy is more desirable than another (for whatever reason including but not limited to legal advice).
Perhaps a table in the form of issue / proposed resolution 1 / proposed resolution 2?
Jonathan
*From:* Alan Greenberg [mailto:alan.greenberg@mcgill.ca <alan.greenberg@mcgill.ca>] *Sent:* 15 January 2015 06:12 *To:* CWG IANA *Subject:* [CWG-Stewardship] Accountability measures required by CWG Proposal(s)
I believe that this is the minimalist list of accountability measures or accountability-related processes that would be required based on the two proposals currently under consideration.
I have explicitly not included the wider list of measures that the CCWG is considering for possible inclusion in its WS1, specifically those which the community would like to see and for which the IANA transition might provide additional impetus for the Board to approve, but are not absolutely required to ensure that the IANA transition can occur. I recognize that this is a judgement call that not all might agree with.
During the last of the four weekend meetings, Chuck mentioned one additional issue, and referred to a chat exchange between him and Donna during the third meeting that listed several other potential accountability issues. Unfortunately, that chat transcript was not preserved due to an error in saving it.
The list of measures for the Contract Co. model is based on the list that the Co-Chairs created in December, augmented by Chucks suggestion. I do not believe that the December list has been negated by any work done in the interim, but perhaps I have missed something. I could not find a rationale for the inclusion of the first of the three items, but include it here so that the CWG could decide if it is based on a real need associated with the proposal or not. If included, I would suggest the CWG be more specific as to under what conditions it would apply. Chuck's suggestion seems to conflict with the 2nd measure in that the 2nd measure is specified as being binding. I am also not sure if it could possibly be replaced by the more generalized IAP (once the request goes to IANA).
The requirements for the internal-to-ICANN model are based on my discussions with a number of people over the last weeks.
*Contract Co. Model Requirements *
*1. Independent Review of Board Actions *Change the ICANN Bylaws to specify that under certain circumstances (to be defined) the determinations of an Independent Review of Board Actions Panel would be binding and not implemented at the Board's discretions.
*2. Independent certification for delegation and re-delegation requests *This would be a replacement for the authorization function for all changes to the Root Zone or its WHOIS Database currently performed by the NTIA. The replacement mechanism would have gTLD requests for delegations and re-delegations authorized by an independent third party and its decision on these matters would be binding on ICANN/IANA.
*3. Independent Appeals Panel *An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process.
*4. gTLD Delegation or Redelegation Appeal within ICANN prior to the change request going to IANA *A Registry could appeal an ICANN decision to delegate or redelegate and gTLD, based on policy not being followed (or presumably contractual terms not being followed).
*Internal-To-ICANN Model Requirements *This model will require all of the above measures plus the following:
*5. Control over ICANN Board decisions. *The ability for ICANN Stakeholders, potentially augmented by other non-ICANN entities, to mandate or overrule, a particular Board decision, or to require that the implementation of such a decision be subject to consideration of an independent, binding review. These measures might need to be augmented by advance notice of such decisions and allow the MS community to react. In the most restricted form, this ability might be restricted to decisions related to IANA, but in reality, it may not be practical to define this scope limitation (ie how to recognize an IANA-related decision).
*6. Ability to Remove Directors *The ability of the overall multi-stakeholder community to remove some or all of the Board Directors. In the case of a full Board removal, a mechanism would be required for appointing an Interim Board and then a replacement regular Board. In addition, ACs and SOs could be given the right to recall their appointed Director(s).
Alan, First let me put in writing the what I said in the last weekend call: We need the Accountability CCWG to provide an accountability process that registry operators (c's & g's) and possibly governments in the case of ccTLDs can use in cases where they think delegation and re-delegation decisions are not in line with approved policy or for governments local law. This may be covered by your item 4 (gTLD Delegation or Redelegation Appeal within ICANN prior to the change request going to IANA) although I am not sure that appeals would always have to happen before going to IANA; that would be preferred though. Alan - why do you think that this would conflict with item 2 (Independent certification for delegation and re-delegation requests)? In the case of gTLDs, the decision whether or not a gTLD could be delegated or re-delegated would happen before any certification would occur. The certification would simply confirm that required steps were followed properly. For gTLDs I think that any appeal would preferably happen before any certification happened but I suppose it could happen afterwards; those details would need to be defined. I won't try to venture into the ccTLD world. On a totally different topic with regard to item 2, I don't think that is something that we need the Accountability CCWG to deal with that. In my view, that seems to be clearly in our court. Any accountability for a certification decision would probably be covered by general accountability processes. Why is item 6 (Ability to Remove Directors) an action that the CWG needs from the CCWG. I agree that we need some specific accountability mechanisms from the CCWG but we don't specifically need the one that would allow for the removal of Directors. That option may provide some of the accountability that the CWG needs but we require that specific option. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Thursday, January 15, 2015 1:12 AM To: CWG IANA Subject: [CWG-Stewardship] Accountability measures required by CWG Proposal(s) I believe that this is the minimalist list of accountability measures or accountability-related processes that would be required based on the two proposals currently under consideration. I have explicitly not included the wider list of measures that the CCWG is considering for possible inclusion in its WS1, specifically those which the community would like to see and for which the IANA transition might provide additional impetus for the Board to approve, but are not absolutely required to ensure that the IANA transition can occur. I recognize that this is a judgement call that not all might agree with. During the last of the four weekend meetings, Chuck mentioned one additional issue, and referred to a chat exchange between him and Donna during the third meeting that listed several other potential accountability issues. Unfortunately, that chat transcript was not preserved due to an error in saving it. The list of measures for the Contract Co. model is based on the list that the Co-Chairs created in December, augmented by Chucks suggestion. I do not believe that the December list has been negated by any work done in the interim, but perhaps I have missed something. I could not find a rationale for the inclusion of the first of the three items, but include it here so that the CWG could decide if it is based on a real need associated with the proposal or not. If included, I would suggest the CWG be more specific as to under what conditions it would apply. Chuck's suggestion seems to conflict with the 2nd measure in that the 2nd measure is specified as being binding. I am also not sure if it could possibly be replaced by the more generalized IAP (once the request goes to IANA). The requirements for the internal-to-ICANN model are based on my discussions with a number of people over the last weeks. Contract Co. Model Requirements 1. Independent Review of Board Actions Change the ICANN Bylaws to specify that under certain circumstances (to be defined) the determinations of an Independent Review of Board Actions Panel would be binding and not implemented at the Board's discretions. 2. Independent certification for delegation and re-delegation requests This would be a replacement for the authorization function for all changes to the Root Zone or its WHOIS Database currently performed by the NTIA. The replacement mechanism would have gTLD requests for delegations and re-delegations authorized by an independent third party and its decision on these matters would be binding on ICANN/IANA. 3. Independent Appeals Panel An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process. 4. gTLD Delegation or Redelegation Appeal within ICANN prior to the change request going to IANA A Registry could appeal an ICANN decision to delegate or redelegate and gTLD, based on policy not being followed (or presumably contractual terms not being followed). Internal-To-ICANN Model Requirements This model will require all of the above measures plus the following: 5. Control over ICANN Board decisions. The ability for ICANN Stakeholders, potentially augmented by other non-ICANN entities, to mandate or overrule, a particular Board decision, or to require that the implementation of such a decision be subject to consideration of an independent, binding review. These measures might need to be augmented by advance notice of such decisions and allow the MS community to react. In the most restricted form, this ability might be restricted to decisions related to IANA, but in reality, it may not be practical to define this scope limitation (ie how to recognize an IANA-related decision). 6. Ability to Remove Directors The ability of the overall multi-stakeholder community to remove some or all of the Board Directors. In the case of a full Board removal, a mechanism would be required for appointing an Interim Board and then a replacement regular Board. In addition, ACs and SOs could be given the right to recall their appointed Director(s).
Hi, A couple of questions that are relevant to implementation (the bits I care about):
2. Independent certification for delegation and re-delegation requests
This would be a replacement for the authorization function for all changes to the Root Zone or its WHOIS Database currently performed by the NTIA. The replacement mechanism would have gTLD requests for delegations and re-delegations authorized by an independent third party and its decision on these matters would be binding on ICANN/IANA.
As documented by NTIA at http://www.ntia.doc.gov/files/ntia/publications/ntias_role_root_zone_managem..., the following is considered during "authorization": • Did ICANN follow the change notification process correctly? • Transmitted securely? • Includes the standard set of information (i.e., summary of requested changes)? • Self-certification from ICANN that processes followed? • Request for authorization? Is the idea that the "independent third party" would consider the same set of information and utilize the same mechanisms currently used by NTIA?
3. Independent Appeals Panel
An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process.
The implication of the last sentence is that there would be the introduction of some sort of notification period during root change processing in which interested parties could file an injunction/appeal. As this would be new, some issues to consider: How is that notification sent out? How long is that period? Who would have standing to file an injunction/appeal? How is that injunction request/appeal submitted? What changes would be subject to injunction, e.g., would 'emergency changes' be subject to this notification period and/or injunction-like mechanism? Thanks, -drc
David, In the cases of gTLDs, I think an appeals mechanism regarding delegations, re-delegations or root zone Whois changes could be handled outside of the certification process if there is one. For example, in the case of gTLDs, the decision to delegate a gTLD is made before IANA gets involved and IANA isn’t involved in that decision. See my comments in the Google Doc that Avri initiated. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of David Conrad Sent: Thursday, January 15, 2015 12:56 PM To: Alan Greenberg Cc: CWG Mailing List Subject: Re: [CWG-Stewardship] Accountability measures required by CWG Proposal(s) Hi, A couple of questions that are relevant to implementation (the bits I care about): 2. Independent certification for delegation and re-delegation requests This would be a replacement for the authorization function for all changes to the Root Zone or its WHOIS Database currently performed by the NTIA. The replacement mechanism would have gTLD requests for delegations and re-delegations authorized by an independent third party and its decision on these matters would be binding on ICANN/IANA. As documented by NTIA at http://www.ntia.doc.gov/files/ntia/publications/ntias_role_root_zone_managem..., the following is considered during "authorization": • Did ICANN follow the change notification process correctly? • Transmitted securely? • Includes the standard set of information (i.e., summary of requested changes)? • Self-certification from ICANN that processes followed? • Request for authorization? Is the idea that the "independent third party" would consider the same set of information and utilize the same mechanisms currently used by NTIA? 3. Independent Appeals Panel An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process. The implication of the last sentence is that there would be the introduction of some sort of notification period during root change processing in which interested parties could file an injunction/appeal. As this would be new, some issues to consider: How is that notification sent out? How long is that period? Who would have standing to file an injunction/appeal? How is that injunction request/appeal submitted? What changes would be subject to injunction, e.g., would 'emergency changes' be subject to this notification period and/or injunction-like mechanism? Thanks, -drc
Chuck,
In the cases of gTLDs, I think an appeals mechanism regarding delegations, re-delegations or root zone Whois changes could be handled outside of the certification process if there is one. For example, in the case of gTLDs, the decision to delegate a gTLD is made before IANA gets involved and IANA isn¹t involved in that decision. See my comments in the Google Doc that Avri initiated.
Right. However, the area I was asking about was the implication of: "There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process." The current process does not have a mechanism by which anyone other than the requester, ICANN, NTIA, and Verisign can "defer the change" (or even know it is in process) once lodged. More generically, the statement: "An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database." implies a significant change to the way the IANA Names function is performed. Today, if a change lodged with the IANA Names function is contested, IANA staff will not move forward with the change and instead will request the contesting parties come to a consensus on the change. While not wanting to be again accused of trying to influence outcomes, I'll admit I don't think changing this policy (which has been in place since Postel days) would be prudent. Regards, -drc
David, Agree with your comments. Thank you for flagging for us what in the proposal(s) indicate a significant change from existing processes that have been long been working well. regards Robert
On Jan 15, 2015, at 9:01 PM, David Conrad <david.conrad@icann.org> wrote:
Chuck,
In the cases of gTLDs, I think an appeals mechanism regarding delegations, re-delegations or root zone Whois changes could be handled outside of the certification process if there is one. For example, in the case of gTLDs, the decision to delegate a gTLD is made before IANA gets involved and IANA isn’t involved in that decision. See my comments in the Google Doc that Avri initiated.
Right. However, the area I was asking about was the implication of:
"There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process."
The current process does not have a mechanism by which anyone other than the requester, ICANN, NTIA, and Verisign can "defer the change" (or even know it is in process) once lodged. More generically, the statement:
"An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database."
implies a significant change to the way the IANA Names function is performed. Today, if a change lodged with the IANA Names function is contested, IANA staff will not move forward with the change and instead will request the contesting parties come to a consensus on the change. While not wanting to be again accused of trying to influence outcomes, I'll admit I don't think changing this policy (which has been in place since Postel days) would be prudent.
Regards, -drc
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Regarding standing to appeal, the RySG comments made some very specific recommendations in that regard. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of David Conrad Sent: Thursday, January 15, 2015 12:56 PM To: Alan Greenberg Cc: CWG Mailing List Subject: Re: [CWG-Stewardship] Accountability measures required by CWG Proposal(s) Hi, A couple of questions that are relevant to implementation (the bits I care about): 2. Independent certification for delegation and re-delegation requests This would be a replacement for the authorization function for all changes to the Root Zone or its WHOIS Database currently performed by the NTIA. The replacement mechanism would have gTLD requests for delegations and re-delegations authorized by an independent third party and its decision on these matters would be binding on ICANN/IANA. As documented by NTIA at http://www.ntia.doc.gov/files/ntia/publications/ntias_role_root_zone_managem..., the following is considered during "authorization": • Did ICANN follow the change notification process correctly? • Transmitted securely? • Includes the standard set of information (i.e., summary of requested changes)? • Self-certification from ICANN that processes followed? • Request for authorization? Is the idea that the "independent third party" would consider the same set of information and utilize the same mechanisms currently used by NTIA? 3. Independent Appeals Panel An independent review panel must be set up to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process. The implication of the last sentence is that there would be the introduction of some sort of notification period during root change processing in which interested parties could file an injunction/appeal. As this would be new, some issues to consider: How is that notification sent out? How long is that period? Who would have standing to file an injunction/appeal? How is that injunction request/appeal submitted? What changes would be subject to injunction, e.g., would 'emergency changes' be subject to this notification period and/or injunction-like mechanism? Thanks, -drc
participants (5)
-
Alan Greenberg -
David Conrad -
Gomes, Chuck -
Jonathan Robinson -
Robert Guerra