[CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
Hope all of you are enjoying the holidays. Work Team 2 has added several ideas and requests that arrived after 21-Dec. Draft v5.1 is attached, reflecting these changes: CWG requests: IANA Stewardship CWG co-chairs Jonathan Robinson and Lise Fuhr requested 3 new accountability items in Category 1, Work Stream 1. These 3 items are flagged as CWG (in red and bold) David Johnson: For Category 1, Work Stream 1, proposed a contract between ICANN and Registries & Registrars, with Registrants as 3rd party beneficiaries. Contract lets ICANN impose rules on others only when supported by consensus of affected parties. Disputes go to independent arbitration panel that could issue binding decisions. In a discussion with David, we thought the contract could work alongside the Member structure, not instead of it. Izumi Okutani and Athina Fragkouli noted support for four accountability items, but would place them in Work Stream 2 and suggested some wording changes. Malcolm Hutty requested an item be moved to Work Stream 1: "Ensure that the ICANN Board can be held to its Bylaws, with effective remedy if breach found by independent adjudicator.” Seun Ojedeji requested an alternative: “found by the community" Daniel Castro of ITIF and Wisdom Donkor requested Open Data transparency rules, in Category 3, Work Stream 2. Guru Achayra: For Category 1, Work Stream 1, proposed an Accountability Contract between ICANN and ‘Contract Co.’ to replace the Affirmation of Commitments Carlos Gutiérrez: requested 4 new prescribed actions in Category 3, Work Stream 2 Apologies if I have missed other suggestions. Look forward to discussing on our next call. — Steve DelBianco Executive Director NetChoice http://www.NetChoice.org<http://www.netchoice.org/> and http://blog.netchoice.org<http://blog.netchoice.org/> +1.202.420.7482
I am somewhat troubled by all of the items in WS1 where I do not see the direct link to the IANA transition (even if the IANA transition was directly to ICANN without the intervening Contract Co.) Note I am not saying that they might not be perfectly valid and desirable accountability mechanism, just that I do not see the direct link, and thus perhaps greatly increasing our work to be done to allow transition. I do understand that it may be easier to get some of these accepted if done in association with WS1, but if we make our WS1 task too all-inclusive, it may not get done at all. Alan At 28/12/2014 07:53 PM, Steve DelBianco wrote:
Hope all of you are enjoying the holidays. Work Team 2 has added several ideas and requests that arrived after 21-Dec. Draft v5.1 is attached, reflecting these changes:
CWG requests: IANA Stewardship CWG co-chairs Jonathan Robinson and Lise Fuhr requested 3 new accountability items in Category 1, Work Stream 1. These 3 items are flagged as CWG (in red and bold)
David Johnson: For Category 1, Work Stream 1, proposed a contract between ICANN and Registries & Registrars, with Registrants as 3rd party beneficiaries. Contract lets ICANN impose rules on others only when supported by consensus of affected parties. Disputes go to independent arbitration panel that could issue binding decisions. In a discussion with David, we thought the contract could work alongside the Member structure, not instead of it.
Izumi Okutani and Athina Fragkouli noted support for four accountability items, but would place them in Work Stream 2 and suggested some wording changes.
Malcolm Hutty requested an item be moved to Work Stream 1: "Ensure that the ICANN Board can be held to its Bylaws, with effective remedy if breach found by independent adjudicator.â Seun Ojedeji requested an alternative: âfound by the community"
Daniel Castro of ITIF and Wisdom Donkor requested Open Data transparency rules, in Category 3, Work Stream 2.
Guru Achayra: For Category 1, Work Stream 1, proposed an Accountability Contract between ICANN and âContract Co.â to replace the Affirmation of Commitments
Carlos Gutiérrez: requested 4 new prescribed actions in Category 3, Work Stream 2
Apologies if I have missed other suggestions. Look forward to discussing on our next call.
< Steve DelBianco Executive Director NetChoice <http://www.netchoice.org/>http://www.NetChoice.org and <http://blog.netchoice.org/>http://blog.netchoice.org +1.202.420.7482
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Of course, in so much as the transition represents a loss of leverage, WS1 needs to sufficiently replace it. It’s not really about the IANA transition itself so much as the elimination of the contractual relationship. I agree with Alan that we need to be disciplined about what to include in WS1 to ensure that we come away with the leverage to accomplish WS2. From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Sunday, December 28, 2014 9:35 PM To: Steve DelBianco; Accountability CCWG Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1 I am somewhat troubled by all of the items in WS1 where I do not see the direct link to the IANA transition (even if the IANA transition was directly to ICANN without the intervening Contract Co.) Note I am not saying that they might not be perfectly valid and desirable accountability mechanism, just that I do not see the direct link, and thus perhaps greatly increasing our work to be done to allow transition. I do understand that it may be easier to get some of these accepted if done in association with WS1, but if we make our WS1 task too all-inclusive, it may not get done at all. Alan At 28/12/2014 07:53 PM, Steve DelBianco wrote: Hope all of you are enjoying the holidays. Work Team 2 has added several ideas and requests that arrived after 21-Dec. Draft v5.1 is attached, reflecting these changes: CWG requests: IANA Stewardship CWG co-chairs Jonathan Robinson and Lise Fuhr requested 3 new accountability items in Category 1, Work Stream 1. These 3 items are flagged as CWG (in red and bold) David Johnson: For Category 1, Work Stream 1, proposed a contract between ICANN and Registries & Registrars, with Registrants as 3rd party beneficiaries. Contract lets ICANN impose rules on others only when supported by consensus of affected parties. Disputes go to independent arbitration panel that could issue binding decisions. In a discussion with David, we thought the contract could work alongside the Member structure, not instead of it. Izumi Okutani and Athina Fragkouli noted support for four accountability items, but would place them in Work Stream 2 and suggested some wording changes. Malcolm Hutty requested an item be moved to Work Stream 1: "Ensure that the ICANN Board can be held to its Bylaws, with effective remedy if breach found by independent adjudicator.†Seun Ojedeji requested an alternative: “found by the community" Daniel Castro of ITIF and Wisdom Donkor requested Open Data transparency rules, in Category 3, Work Stream 2. Guru Achayra: For Category 1, Work Stream 1, proposed an Accountability Contract between ICANN and ‘Contract Co.’ to replace the Affirmation of Commitments Carlos Gutiérrez: requested 4 new prescribed actions in Category 3, Work Stream 2 Apologies if I have missed other suggestions. Look forward to discussing on our next call. — < Steve DelBianco Executive Director NetChoice http://www.NetChoice.org<http://www.netchoice.org/> and http://blog.netchoice.org<http://blog.netchoice.org/> +1.202.420.7482 _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hi, And that presupposes that the CSG-Stewardship WG won't stick with the principle of separability in its recommended solution. If it does stick with separability then a contractual relationship remains as an ongoing leverage point. In terms of CWG-Stewardship work, Contract Co holding the contract, still appears to be quite active as a proposal. Perhaps we need to look at the WS1 list in terms of the binary discriminant: is there an ongoing contractual relationship with an eternal entity or not. I expect the WS1 list will vary based on which of these is being considered. avri On 28-Dec-14 22:57, Jonathan Zuck wrote:
Of course, in so much as the transition represents a loss of leverage, WS1 needs to sufficiently replace it. It�s not really about the IANA transition itself so much as the elimination of the contractual relationship. I agree with Alan that we need to be disciplined about what to include in WS1 to ensure that we come away with the leverage to accomplish WS2.
*From:*accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] *On Behalf Of *Alan Greenberg *Sent:* Sunday, December 28, 2014 9:35 PM *To:* Steve DelBianco; Accountability CCWG *Subject:* Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
I am somewhat troubled by all of the items in WS1 where I do not see the direct link to the IANA transition (even if the IANA transition was directly to ICANN without the intervening Contract Co.)
Note I am not saying that they might not be perfectly valid and desirable accountability mechanism, just that I do not see the direct link, and thus perhaps greatly increasing our work to be done to allow transition.
I do understand that it may be easier to get some of these accepted if done in association with WS1, but if we make our WS1 task too all-inclusive, it may not get done at all.
Alan
At 28/12/2014 07:53 PM, Steve DelBianco wrote:
Hope all of you are enjoying the holidays. Work Team 2 has added several ideas and requests that arrived after 21-Dec. Draft v5.1 is attached, reflecting these changes:
CWG requests: IANA Stewardship CWG co-chairs Jonathan Robinson and Lise Fuhr requested 3 new accountability items in Category 1, Work Stream 1. These 3 items are flagged as CWG (in red and bold)
David Johnson: For Category 1, Work Stream 1, proposed a contract between ICANN and Registries & Registrars, with Registrants as 3rd party beneficiaries. Contract lets ICANN impose rules on others only when supported by consensus of affected parties. Disputes go to independent arbitration panel that could issue binding decisions. In a discussion with David, we thought the contract could work alongside the Member structure, not instead of it.
Izumi Okutani and Athina Fragkouli noted support for four accountability items, but would place them in Work Stream 2 and suggested some wording changes.
Malcolm Hutty requested an item be moved to Work Stream 1: "Ensure that the ICANN Board can be held to its Bylaws, with effective remedy if breach found by independent adjudicator.” Seun Ojedeji requested an alternative: “found by the community"
Daniel Castro of ITIF and Wisdom Donkor requested Open Data transparency rules, in Category 3, Work Stream 2.
Guru Achayra: For Category 1, Work Stream 1, proposed an Accountability Contract between ICANN and ‘Contract Co.’ to replace the Affirmation of Commitments
Carlos Gutiérrez: requested 4 new prescribed actions in Category 3, Work Stream 2
Apologies if I have missed other suggestions. Look forward to discussing on our next call.
� < Steve DelBianco Executive Director NetChoice http://www.NetChoice.org <http://www.netchoice.org/> and http://blog.netchoice.org <http://blog.netchoice.org/> +1.202.420.7482
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
sent from Google nexus 4 kindly excuse brevity and typos. On 29 Dec 2014 06:43, "Avri Doria" <avri@acm.org> wrote:
Hi,
And that presupposes that the CSG-Stewardship WG won't stick with the
principle of separability in its recommended solution.
If it does stick with separability then a contractual relationship
remains as an ongoing leverage point. In terms of CWG-Stewardship work, Contract Co holding the contract, still appears to be quite active as a proposal.
While I won't attempt start discussing contract co approach in details here, I will just say that since we are speaking of ICANN accountability, then it becomes a thing of relevance to discuss the accountability aspect of contract co (if this cwg is considering it as an option).
Perhaps we need to look at the WS1 list in terms of the binary discriminant: is there an ongoing contractual relationship with an eternal entity or not. I expect the WS1 list will vary based on which of these is being considered.
Well if we have the time for this, that's fine. However, while asking that question, let's also be sure to review the characteristics of the current external entity in considering a replacement (which is where accountability of such entity comes in the picture) Regards
avri
On 28-Dec-14 22:57, Jonathan Zuck wrote:
Of course, in so much as the transition represents a loss of leverage,
WS1 needs to sufficiently replace it. It’s not really about the IANA transition itself so much as the elimination of the contractual relationship. I agree with Alan that we need to be disciplined about what to include in WS1 to ensure that we come away with the leverage to accomplish WS2.
From: accountability-cross-community-bounces@icann.org [mailto:
accountability-cross-community-bounces@icann.org] On Behalf Of Alan Greenberg
Sent: Sunday, December 28, 2014 9:35 PM To: Steve DelBianco; Accountability CCWG Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
I am somewhat troubled by all of the items in WS1 where I do not see the direct link to the IANA transition (even if the IANA transition was directly to ICANN without the intervening Contract Co.)
Note I am not saying that they might not be perfectly valid and desirable accountability mechanism, just that I do not see the direct link, and thus perhaps greatly increasing our work to be done to allow transition.
I do understand that it may be easier to get some of these accepted if done in association with WS1, but if we make our WS1 task too all-inclusive, it may not get done at all.
Alan
At 28/12/2014 07:53 PM, Steve DelBianco wrote:
Hope all of you are enjoying the holidays. Work Team 2 has added several ideas and requests that arrived after 21-Dec. Draft v5.1 is attached, reflecting these changes:
CWG requests: IANA Stewardship CWG co-chairs Jonathan Robinson and Lise Fuhr requested 3 new accountability items in Category 1, Work Stream 1. These 3 items are flagged as CWG (in red and bold)
David Johnson: For Category 1, Work Stream 1, proposed a contract between ICANN and Registries & Registrars, with Registrants as 3rd party beneficiaries. Contract lets ICANN impose rules on others only when supported by consensus of affected parties. Disputes go to independent arbitration panel that could issue binding decisions. In a discussion with David, we thought the contract could work alongside the Member structure, not instead of it.
Izumi Okutani and Athina Fragkouli noted support for four accountability items, but would place them in Work Stream 2 and suggested some wording changes.
Malcolm Hutty requested an item be moved to Work Stream 1: "Ensure that the ICANN Board can be held to its Bylaws, with effective remedy if breach found by independent adjudicator.†Seun Ojedeji requested an alternative: “found by the community"
Daniel Castro of ITIF and Wisdom Donkor requested Open Data transparency rules, in Category 3, Work Stream 2.
Guru Achayra: For Category 1, Work Stream 1, proposed an Accountability Contract between ICANN and ‘Contract Co.’ to replace the Affirmation of Commitments
Carlos Gutiérrez: requested 4 new prescribed actions in Category 3, Work Stream 2
Apologies if I have missed other suggestions. Look forward to discussing on our next call.
— < Steve DelBianco Executive Director NetChoice http://www.NetChoice.org and http://blog.netchoice.org +1.202.420.7482
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Of course, the use of a contract is a bit of a blunt instrument of accountability absent some structure for transactional checks and balances. Let’s not miss the opportunity to replace it with something more operational while we’re at it. From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Seun Ojedeji Sent: Monday, December 29, 2014 1:37 AM To: avri Cc: accountability-cross-community@icann.org Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1 sent from Google nexus 4 kindly excuse brevity and typos. On 29 Dec 2014 06:43, "Avri Doria" <avri@acm.org<mailto:avri@acm.org>> wrote:
Hi,
And that presupposes that the CSG-Stewardship WG won't stick with the principle of separability in its recommended solution.
If it does stick with separability then a contractual relationship remains as an ongoing leverage point. In terms of CWG-Stewardship work, Contract Co holding the contract, still appears to be quite active as a proposal.
While I won't attempt start discussing contract co approach in details here, I will just say that since we are speaking of ICANN accountability, then it becomes a thing of relevance to discuss the accountability aspect of contract co (if this cwg is considering it as an option).
Perhaps we need to look at the WS1 list in terms of the binary discriminant: is there an ongoing contractual relationship with an eternal entity or not. I expect the WS1 list will vary based on which of these is being considered.
Well if we have the time for this, that's fine. However, while asking that question, let's also be sure to review the characteristics of the current external entity in considering a replacement (which is where accountability of such entity comes in the picture) Regards
avri
On 28-Dec-14 22:57, Jonathan Zuck wrote:
Of course, in so much as the transition represents a loss of leverage, WS1 needs to sufficiently replace it. It’s not really about the IANA transition itself so much as the elimination of the contractual relationship. I agree with Alan that we need to be disciplined about what to include in WS1 to ensure that we come away with the leverage to accomplish WS2.
From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>] On Behalf Of Alan Greenberg Sent: Sunday, December 28, 2014 9:35 PM To: Steve DelBianco; Accountability CCWG Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
I am somewhat troubled by all of the items in WS1 where I do not see the direct link to the IANA transition (even if the IANA transition was directly to ICANN without the intervening Contract Co.)
Note I am not saying that they might not be perfectly valid and desirable accountability mechanism, just that I do not see the direct link, and thus perhaps greatly increasing our work to be done to allow transition.
I do understand that it may be easier to get some of these accepted if done in association with WS1, but if we make our WS1 task too all-inclusive, it may not get done at all.
Alan
At 28/12/2014 07:53 PM, Steve DelBianco wrote:
Hope all of you are enjoying the holidays. Work Team 2 has added several ideas and requests that arrived after 21-Dec. Draft v5.1 is attached, reflecting these changes:
CWG requests: IANA Stewardship CWG co-chairs Jonathan Robinson and Lise Fuhr requested 3 new accountability items in Category 1, Work Stream 1. These 3 items are flagged as CWG (in red and bold)
David Johnson: For Category 1, Work Stream 1, proposed a contract between ICANN and Registries & Registrars, with Registrants as 3rd party beneficiaries. Contract lets ICANN impose rules on others only when supported by consensus of affected parties. Disputes go to independent arbitration panel that could issue binding decisions. In a discussion with David, we thought the contract could work alongside the Member structure, not instead of it.
Izumi Okutani and Athina Fragkouli noted support for four accountability items, but would place them in Work Stream 2 and suggested some wording changes.
Malcolm Hutty requested an item be moved to Work Stream 1: "Ensure that the ICANN Board can be held to its Bylaws, with effective remedy if breach found by independent adjudicator.†Seun Ojedeji requested an alternative: “found by the community"
Daniel Castro of ITIF and Wisdom Donkor requested Open Data transparency rules, in Category 3, Work Stream 2.
Guru Achayra: For Category 1, Work Stream 1, proposed an Accountability Contract between ICANN and ‘Contract Co.’ to replace the Affirmation of Commitments
Carlos Gutiérrez: requested 4 new prescribed actions in Category 3, Work Stream 2
Apologies if I have missed other suggestions. Look forward to discussing on our next call.
— < Steve DelBianco Executive Director NetChoice http://www.NetChoice.org and http://blog.netchoice.org +1.202.420.7482
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hi, Of course, but still that might make it a WS2 task. I am just trying to point out a consideration from the other track. avri On 29-Dec-14 08:37, Jonathan Zuck wrote:
Of course, the use of a contract is a bit of a blunt instrument of accountability absent some structure for transactional checks and balances. Let’s not miss the opportunity to replace it with something more operational while we’re at it.
*From:*accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] *On Behalf Of *Seun Ojedeji *Sent:* Monday, December 29, 2014 1:37 AM *To:* avri *Cc:* accountability-cross-community@icann.org *Subject:* Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
sent from Google nexus 4 kindly excuse brevity and typos. On 29 Dec 2014 06:43, "Avri Doria" <avri@acm.org <mailto:avri@acm.org>> wrote:
Hi,
And that presupposes that the CSG-Stewardship WG won't stick with
the principle of separability in its recommended solution.
If it does stick with separability then a contractual relationship
remains as an ongoing leverage point. In terms of CWG-Stewardship work, Contract Co holding the contract, still appears to be quite active as a proposal.
While I won't attempt start discussing contract co approach in details here, I will just say that since we are speaking of ICANN accountability, then it becomes a thing of relevance to discuss the accountability aspect of contract co (if this cwg is considering it as an option).
Perhaps we need to look at the WS1 list in terms of the binary discriminant: is there an ongoing contractual relationship with an eternal entity or not. I expect the WS1 list will vary based on which of these is being considered.
Well if we have the time for this, that's fine. However, while asking that question, let's also be sure to review the characteristics of the current external entity in considering a replacement (which is where accountability of such entity comes in the picture)
Regards
avri
On 28-Dec-14 22:57, Jonathan Zuck wrote:
Of course, in so much as the transition represents a loss of
leverage, WS1 needs to sufficiently replace it. It’s not really about the IANA transition itself so much as the elimination of the contractual relationship. I agree with Alan that we need to be disciplined about what to include in WS1 to ensure that we come away with the leverage to accomplish WS2.
From: accountability-cross-community-bounces@icann.org
<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org>] On Behalf Of Alan Greenberg
Sent: Sunday, December 28, 2014 9:35 PM To: Steve DelBianco; Accountability CCWG Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
I am somewhat troubled by all of the items in WS1 where I do not see the direct link to the IANA transition (even if the IANA transition was directly to ICANN without the intervening Contract Co.)
Note I am not saying that they might not be perfectly valid and desirable accountability mechanism, just that I do not see the direct link, and thus perhaps greatly increasing our work to be done to allow transition.
I do understand that it may be easier to get some of these accepted if done in association with WS1, but if we make our WS1 task too all-inclusive, it may not get done at all.
Alan
At 28/12/2014 07:53 PM, Steve DelBianco wrote:
Hope all of you are enjoying the holidays. Work Team 2 has added several ideas and requests that arrived after 21-Dec. Draft v5.1 is attached, reflecting these changes:
CWG requests: IANA Stewardship CWG co-chairs Jonathan Robinson and Lise Fuhr requested 3 new accountability items in Category 1, Work Stream 1. These 3 items are flagged as CWG (in red and bold)
David Johnson: For Category 1, Work Stream 1, proposed a contract between ICANN and Registries & Registrars, with Registrants as 3rd party beneficiaries. Contract lets ICANN impose rules on others only when supported by consensus of affected parties. Disputes go to independent arbitration panel that could issue binding decisions. In a discussion with David, we thought the contract could work alongside the Member structure, not instead of it.
Izumi Okutani and Athina Fragkouli noted support for four accountability items, but would place them in Work Stream 2 and suggested some wording changes.
Malcolm Hutty requested an item be moved to Work Stream 1: "Ensure that the ICANN Board can be held to its Bylaws, with effective remedy if breach found by independent adjudicator.†Seun Ojedeji requested an alternative: “found by the community"
Daniel Castro of ITIF and Wisdom Donkor requested Open Data transparency rules, in Category 3, Work Stream 2.
Guru Achayra: For Category 1, Work Stream 1, proposed an Accountability Contract between ICANN and ‘Contract Co.’ to replace the Affirmation of Commitments
Carlos Gutiérrez: requested 4 new prescribed actions in Category 3, Work Stream 2
Apologies if I have missed other suggestions. Look forward to discussing on our next call.
— < Steve DelBianco Executive Director NetChoice http://www.NetChoice.org and http://blog.netchoice.org <http://blog.netchoice.org> +1.202.420.7482
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
With respect, I think it is a mistake to look to the current entity as a guide for what we want to replace … mostly because much (if not all) of the actual control exercised by NTIA is through deterrence and its existence as a check rather than through formal controls. It can do that because, candidly, it is an instrument of a very powerful government with many non-contractual tools at its disposal to influence events. When the IANA function transitions, the accountability will be to the community at large – a much broader, more diffuse institution. It will have some power of the non-contractual sort but it will be exceedingly difficult to mobilize that power and use it. As a result, the accountability with which we replace IANA has to be bas3ed on much more formal processes that effectively institutionalize control. I think Avri is exactly right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.” And we have seen that ICANN sometimes has ambitions to do more than IANA – witness the proposal to spend money on broadband expansion. [I support expansion – but not through ICANN :)] In the absence of a commitment to adopt a legally binding mechanism for limiting ICANN activities to IANA, and =only= IANA, WS1 needs to be much more comprehensive. The risk is that the functionality transitions without any such limitation, in which case we will have traded one body of guardians at NTIA for an even more Plantonic guardian group at the Board. Paul **NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 *** 509 C St. NE Washington, DC 20002 Paul Rosenzweig <mailto:paul.rosenzweigesq@redbranchconsulting.com> paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 Skype: +1 (202) 738-1739 or paul.rosenzweig1066 <http://www.redbranchconsulting.com/index.php?option=com_content&view=article...> Link to my PGP Key From: Seun Ojedeji [mailto:seun.ojedeji@gmail.com] Sent: Monday, December 29, 2014 1:37 AM To: avri Cc: accountability-cross-community@icann.org Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1 sent from Google nexus 4 kindly excuse brevity and typos. On 29 Dec 2014 06:43, "Avri Doria" <avri@acm.org <mailto:avri@acm.org> > wrote:
Hi,
And that presupposes that the CSG-Stewardship WG won't stick with the principle of separability in its recommended solution.
If it does stick with separability then a contractual relationship remains as an ongoing leverage point. In terms of CWG-Stewardship work, Contract Co holding the contract, still appears to be quite active as a proposal.
While I won't attempt start discussing contract co approach in details here, I will just say that since we are speaking of ICANN accountability, then it becomes a thing of relevance to discuss the accountability aspect of contract co (if this cwg is considering it as an option).
Perhaps we need to look at the WS1 list in terms of the binary discriminant: is there an ongoing contractual relationship with an eternal entity or not. I expect the WS1 list will vary based on which of these is being considered.
Well if we have the time for this, that's fine. However, while asking that question, let's also be sure to review the characteristics of the current external entity in considering a replacement (which is where accountability of such entity comes in the picture) Regards
avri
On 28-Dec-14 22:57, Jonathan Zuck wrote:
Of course, in so much as the transition represents a loss of leverage, WS1 needs to sufficiently replace it. It’s not really about the IANA transition itself so much as the elimination of the contractual relationship. I agree with Alan that we need to be disciplined about what to include in WS1 to ensure that we come away with the leverage to accomplish WS2.
From: accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org> ] On Behalf Of Alan Greenberg Sent: Sunday, December 28, 2014 9:35 PM To: Steve DelBianco; Accountability CCWG Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
I am somewhat troubled by all of the items in WS1 where I do not see the direct link to the IANA transition (even if the IANA transition was directly to ICANN without the intervening Contract Co.)
Note I am not saying that they might not be perfectly valid and desirable accountability mechanism, just that I do not see the direct link, and thus perhaps greatly increasing our work to be done to allow transition.
I do understand that it may be easier to get some of these accepted if done in association with WS1, but if we make our WS1 task too all-inclusive, it may not get done at all.
Alan
At 28/12/2014 07:53 PM, Steve DelBianco wrote:
Hope all of you are enjoying the holidays. Work Team 2 has added several ideas and requests that arrived after 21-Dec. Draft v5.1 is attached, reflecting these changes:
CWG requests: IANA Stewardship CWG co-chairs Jonathan Robinson and Lise Fuhr requested 3 new accountability items in Category 1, Work Stream 1. These 3 items are flagged as CWG (in red and bold)
David Johnson: For Category 1, Work Stream 1, proposed a contract between ICANN and Registries & Registrars, with Registrants as 3rd party beneficiaries. Contract lets ICANN impose rules on others only when supported by consensus of affected parties. Disputes go to independent arbitration panel that could issue binding decisions. In a discussion with David, we thought the contract could work alongside the Member structure, not instead of it.
Izumi Okutani and Athina Fragkouli noted support for four accountability items, but would place them in Work Stream 2 and suggested some wording changes.
Malcolm Hutty requested an item be moved to Work Stream 1: "Ensure that the ICANN Board can be held to its Bylaws, with effective remedy if breach found by independent adjudicator.†Seun Ojedeji requested an alternative: “found by the community"
Daniel Castro of ITIF and Wisdom Donkor requested Open Data transparency rules, in Category 3, Work Stream 2.
Guru Achayra: For Category 1, Work Stream 1, proposed an Accountability Contract between ICANN and ‘Contract Co.’ to replace the Affirmation of Commitments
Carlos Gutiérrez: requested 4 new prescribed actions in Category 3, Work Stream 2
Apologies if I have missed other suggestions. Look forward to discussing on our next call.
— < Steve DelBianco Executive Director NetChoice http://www.NetChoice.org and http://blog.netchoice.org +1.202.420.7482
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hello Paul,
I think Avri is exactly right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
I don’t think you should make that assumption yet. There is a difference between the Board’s views in forming a new entity (Contract Co.) to replace the NTIA, and the aboard agreeing to terms in contracts with the users of the IANA functions that may limit what it can do. There are already requirements on ICANN in the gTLD registry agreement for example: From: http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-... "Article 3 "COVENANTS OF ICANN" ICANN covenants and agrees with Registry Operator as follows: 3.1 Open and Transparent. Consistent with ICANN’s expressed mission and core values, ICANN shall operate in an open and transparent manner. 3.2 Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause. 3.3 TLD Nameservers. ICANN will use commercially reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at http://www.iana.org/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications. 3.4 Root-zone Information Publication. ICANN’s publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at http://www.iana.org/domains/root/. 3.5 Authoritative Root Database. To the extent that ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (a) ensure that the authoritative root will point to the top-level domain nameservers designated by Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction." As a result of recommendations from this working group - additional text could be made part of the standard gTLD registry and registrar agreements.
And we have seen that ICANN sometimes has ambitions to do more than IANA – witness the proposal to spend money on broadband expansion.
Yes - I believe that statement was a possible area of spending noted by the CEO. I note however that it is not part of any approved budget, and the Board would be seeking a consensus of the ICANN community before it authorised such expenditure from any auction proceeds. Regards, Bruce Tonkin
Dear Bruce, Dear Colleagues, Many thanks for pointing these covenants out Bruce. Turning to David & Samantha as WA1 coordinators, wouldn't such generic contract commitments by Icann qualify for our inventory of existing accountability mechanisms ? I suppose we would need to assess what options a gTLD registry would have if Icann were to not deliver on these commitments ? Best Mathieu Le 30/12/2014 07:16, Bruce Tonkin a écrit :
Hello Paul,
I think Avri is exactly right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
I don’t think you should make that assumption yet. There is a difference between the Board’s views in forming a new entity (Contract Co.) to replace the NTIA, and the aboard agreeing to terms in contracts with the users of the IANA functions that may limit what it can do. There are already requirements on ICANN in the gTLD registry agreement for example:
From: http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-...
"Article 3 "COVENANTS OF ICANN"
ICANN covenants and agrees with Registry Operator as follows:
3.1 Open and Transparent. Consistent with ICANN’s expressed mission and core values, ICANN shall operate in an open and transparent manner.
3.2 Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause.
3.3 TLD Nameservers. ICANN will use commercially reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at http://www.iana.org/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications.
3.4 Root-zone Information Publication. ICANN’s publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at http://www.iana.org/domains/root/.
3.5 Authoritative Root Database. To the extent that ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (a) ensure that the authoritative root will point to the top-level domain nameservers designated by Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction."
As a result of recommendations from this working group - additional text could be made part of the standard gTLD registry and registrar agreements.
And we have seen that ICANN sometimes has ambitions to do more than IANA – witness the proposal to spend money on broadband expansion. Yes - I believe that statement was a possible area of spending noted by the CEO. I note however that it is not part of any approved budget, and the Board would be seeking a consensus of the ICANN community before it authorised such expenditure from any auction proceeds.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- ***************************** Mathieu WEILL AFNIC - directeur général Tél: +33 1 39 30 83 06 mathieu.weill@afnic.fr Twitter : @mathieuweill *****************************
Hello Mathieu,
I suppose we would need to assess what options a gTLD registry would have if Icann were to not deliver on these commitments ?
Well the gTLD registry operator has termination rights if ICANN breaches the covenants - but they may not be what the gTLD registry operator wants to do. ICANN is also subject to binding arbitration under the agreement: "Disputes arising under or in connection with this Agreement that are not resolved pursuant to Section 5.1, including requests for specific performance, will be resolved through binding arbitration conducted pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce" " Registry Operator and ICANN agree that irreparable damage could occur if any of the provisions of this Agreement was not performed in accordance with its specific terms. Accordingly, the parties agree that they each shall be entitled to seek from the arbitrator or court of competent jurisdiction specific performance of the terms of this Agreement (in addition to any other remedy to which each party is entitled)." It would seem more likely that a registry operator would seek a binding commitment from ICANN to address any breach of its covenants. Regards, Bruce Tonkin
Bruce Regarding your last below re: the seeking of consensus before spending on broadband, I think we have a fundamental disagreement. Even if the entire community were to want to do that, ICANN would be the wrong mechanism for achieving that goal -- for much the same reason that we don't ask a Department of Education to manage the health care system in a country. Both are important "good governance" functions but for reasons of expertise, focus and management we don't accept that. For that reason I see it as essential to prevent as far as is practicable ICANN from straying beyond the IANA mission. "Even the best intentions oft lead men astray." Paul **NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 *** 509 C St. NE Washington, DC 20002 Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 Skype: +1 (202) 738-1739 or paul.rosenzweig1066 Link to my PGP Key -----Original Message----- From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] Sent: Tuesday, December 30, 2014 1:17 AM To: accountability-cross-community@icann.org Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1 Hello Paul,
I think Avri is exactly right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
I don’t think you should make that assumption yet. There is a difference between the Board’s views in forming a new entity (Contract Co.) to replace the NTIA, and the aboard agreeing to terms in contracts with the users of the IANA functions that may limit what it can do. There are already requirements on ICANN in the gTLD registry agreement for example: From: http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-... "Article 3 "COVENANTS OF ICANN" ICANN covenants and agrees with Registry Operator as follows: 3.1 Open and Transparent. Consistent with ICANN’s expressed mission and core values, ICANN shall operate in an open and transparent manner. 3.2 Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause. 3.3 TLD Nameservers. ICANN will use commercially reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at http://www.iana.org/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications. 3.4 Root-zone Information Publication. ICANN’s publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at http://www.iana.org/domains/root/. 3.5 Authoritative Root Database. To the extent that ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (a) ensure that the authoritative root will point to the top-level domain nameservers designated by Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction." As a result of recommendations from this working group - additional text could be made part of the standard gTLD registry and registrar agreements.
And we have seen that ICANN sometimes has ambitions to do more than IANA – witness the proposal to spend money on broadband expansion.
Yes - I believe that statement was a possible area of spending noted by the CEO. I note however that it is not part of any approved budget, and the Board would be seeking a consensus of the ICANN community before it authorised such expenditure from any auction proceeds. Regards, Bruce Tonkin _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear All, I ALSO think Avri is right – the solution set is binary. * If the Board/ICANN will accept in WS1 ** a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. * COMMENT FROM KAVOUSS This has exactly been proposed by CWG in their outcome draft to which the Board disagreed in its recent publication for public comments and I have surprised to read that and thus asked to discuss that matter in the agenda of this evening ,30 December CALL *But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.” * COMMENT FROM KAVOUSS I do not understand why the Board will not accept that .They have told in their views for public comment that " it is duplication of work " does it means that any mechanism to properly address the replacement of NTIA for IANA functions are duplication of work? Does it mean that if no replacement is proposed and the function trusted to ICANN without a clear responsibility and transparaency in an acciountable manner it is not duplication ? Are we exchanging NTIA by ICANN ? Under the current practice, at least ICANN is accountable to NTIA . After the transition ICANN WOULD BE ACCOUNTABLE TO WHICH ENTITY? This is a core issue and must be fully examined and resolved Kavouss 2014-12-30 14:16 GMT+01:00 Paul Rosenzweig < paul.rosenzweig@redbranchconsulting.com>:
Bruce
Regarding your last below re: the seeking of consensus before spending on broadband, I think we have a fundamental disagreement. Even if the entire community were to want to do that, ICANN would be the wrong mechanism for achieving that goal -- for much the same reason that we don't ask a Department of Education to manage the health care system in a country. Both are important "good governance" functions but for reasons of expertise, focus and management we don't accept that. For that reason I see it as essential to prevent as far as is practicable ICANN from straying beyond the IANA mission. "Even the best intentions oft lead men astray."
Paul
**NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 *** 509 C St. NE Washington, DC 20002
Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 Skype: +1 (202) 738-1739 or paul.rosenzweig1066 Link to my PGP Key
-----Original Message----- From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] Sent: Tuesday, December 30, 2014 1:17 AM To: accountability-cross-community@icann.org Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
Hello Paul,
I think Avri is exactly right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
I don’t think you should make that assumption yet. There is a difference between the Board’s views in forming a new entity (Contract Co.) to replace the NTIA, and the aboard agreeing to terms in contracts with the users of the IANA functions that may limit what it can do. There are already requirements on ICANN in the gTLD registry agreement for example:
From: http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-...
"Article 3 "COVENANTS OF ICANN"
ICANN covenants and agrees with Registry Operator as follows:
3.1 Open and Transparent. Consistent with ICANN’s expressed mission and core values, ICANN shall operate in an open and transparent manner.
3.2 Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause.
3.3 TLD Nameservers. ICANN will use commercially reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at http://www.iana.org/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications.
3.4 Root-zone Information Publication. ICANN’s publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at http://www.iana.org/domains/root/.
3.5 Authoritative Root Database. To the extent that ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (a) ensure that the authoritative root will point to the top-level domain nameservers designated by Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction."
As a result of recommendations from this working group - additional text could be made part of the standard gTLD registry and registrar agreements.
And we have seen that ICANN sometimes has ambitions to do more than IANA – witness the proposal to spend money on broadband expansion.
Yes - I believe that statement was a possible area of spending noted by the CEO. I note however that it is not part of any approved budget, and the Board would be seeking a consensus of the ICANN community before it authorised such expenditure from any auction proceeds.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
The BOARD talked about is this Board. Congress asks 'what happens when this Board is replaced with other members unknown today? Sent from my iPhone
On Dec 30, 2014, at 9:11 AM, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:
Dear All, I ALSO think Avri is right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2.
COMMENT FROM KAVOUSS
This has exactly been proposed by CWG in their outcome draft to which the Board disagreed in its recent publication for public comments and I have surprised to read that and thus asked to discuss that matter in the agenda of this evening ,30 December CALL
But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
COMMENT FROM KAVOUSS
I do not understand why the Board will not accept that .They have told in their views for public comment that " it is duplication of work " does it means that any mechanism to properly address the replacement of NTIA for IANA functions are duplication of work? Does it mean that if no replacement is proposed and the function trusted to ICANN without a clear responsibility and transparaency in an acciountable manner it is not duplication ? Are we exchanging NTIA by ICANN ? Under the current practice, at least ICANN is accountable to NTIA . After the transition ICANN WOULD BE ACCOUNTABLE TO WHICH ENTITY? This is a core issue and must be fully examined and resolved Kavouss
2014-12-30 14:16 GMT+01:00 Paul Rosenzweig <paul.rosenzweig@redbranchconsulting.com>:
Bruce
Regarding your last below re: the seeking of consensus before spending on broadband, I think we have a fundamental disagreement. Even if the entire community were to want to do that, ICANN would be the wrong mechanism for achieving that goal -- for much the same reason that we don't ask a Department of Education to manage the health care system in a country. Both are important "good governance" functions but for reasons of expertise, focus and management we don't accept that. For that reason I see it as essential to prevent as far as is practicable ICANN from straying beyond the IANA mission. "Even the best intentions oft lead men astray."
Paul
**NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 *** 509 C St. NE Washington, DC 20002
Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 Skype: +1 (202) 738-1739 or paul.rosenzweig1066 Link to my PGP Key
-----Original Message----- From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] Sent: Tuesday, December 30, 2014 1:17 AM To: accountability-cross-community@icann.org Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
Hello Paul,
I think Avri is exactly right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
I don’t think you should make that assumption yet. There is a difference between the Board’s views in forming a new entity (Contract Co.) to replace the NTIA, and the aboard agreeing to terms in contracts with the users of the IANA functions that may limit what it can do. There are already requirements on ICANN in the gTLD registry agreement for example:
From: http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-...
"Article 3 "COVENANTS OF ICANN"
ICANN covenants and agrees with Registry Operator as follows:
3.1 Open and Transparent. Consistent with ICANN’s expressed mission and core values, ICANN shall operate in an open and transparent manner.
3.2 Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause.
3.3 TLD Nameservers. ICANN will use commercially reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at http://www.iana.org/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications.
3.4 Root-zone Information Publication. ICANN’s publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at http://www.iana.org/domains/root/.
3.5 Authoritative Root Database. To the extent that ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (a) ensure that the authoritative root will point to the top-level domain nameservers designated by Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction."
As a result of recommendations from this working group - additional text could be made part of the standard gTLD registry and registrar agreements.
And we have seen that ICANN sometimes has ambitions to do more than IANA – witness the proposal to spend money on broadband expansion.
Yes - I believe that statement was a possible area of spending noted by the CEO. I note however that it is not part of any approved budget, and the Board would be seeking a consensus of the ICANN community before it authorised such expenditure from any auction proceeds.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
The issue is not about the individuals designated after transition. The issue is how and who designate these members What are the principles to be used in their désignations More importantly should they be nominated and then designated or They should be suggested and elected or There should be an open candidatships filling certain conditions and qualifications Then who and how the designation and or election is to be carried out . Individuals which are not designated and/ or elected by public Global Multistakeholders or their lega représentatives ) could not be held accountable to that entity. Regards Kavouss 2014-12-30 15:39 GMT+01:00 Carrie <carriedev@gmail.com>:
The BOARD talked about is this Board. Congress asks 'what happens when this Board is replaced with other members unknown today?
Sent from my iPhone
On Dec 30, 2014, at 9:11 AM, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:
Dear All, I ALSO think Avri is right – the solution set is binary. * If the Board/ICANN will accept in WS1 ** a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. *
COMMENT FROM KAVOUSS
This has exactly been proposed by CWG in their outcome draft to which the Board disagreed in its recent publication for public comments and I have surprised to read that and thus asked to discuss that matter in the agenda of this evening ,30 December CALL
*But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.” *
COMMENT FROM KAVOUSS
I do not understand why the Board will not accept that .They have told in their views for public comment that " it is duplication of work " does it means that any mechanism to properly address the replacement of NTIA for IANA functions are duplication of work? Does it mean that if no replacement is proposed and the function trusted to ICANN without a clear responsibility and transparaency in an acciountable manner it is not duplication ? Are we exchanging NTIA by ICANN ? Under the current practice, at least ICANN is accountable to NTIA . After the transition ICANN WOULD BE ACCOUNTABLE TO WHICH ENTITY? This is a core issue and must be fully examined and resolved Kavouss
2014-12-30 14:16 GMT+01:00 Paul Rosenzweig < paul.rosenzweig@redbranchconsulting.com>:
Bruce
Regarding your last below re: the seeking of consensus before spending on broadband, I think we have a fundamental disagreement. Even if the entire community were to want to do that, ICANN would be the wrong mechanism for achieving that goal -- for much the same reason that we don't ask a Department of Education to manage the health care system in a country. Both are important "good governance" functions but for reasons of expertise, focus and management we don't accept that. For that reason I see it as essential to prevent as far as is practicable ICANN from straying beyond the IANA mission. "Even the best intentions oft lead men astray."
Paul
**NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 *** 509 C St. NE Washington, DC 20002
Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 Skype: +1 (202) 738-1739 or paul.rosenzweig1066 Link to my PGP Key
-----Original Message----- From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] Sent: Tuesday, December 30, 2014 1:17 AM To: accountability-cross-community@icann.org Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
Hello Paul,
I think Avri is exactly right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
I don’t think you should make that assumption yet. There is a difference between the Board’s views in forming a new entity (Contract Co.) to replace the NTIA, and the aboard agreeing to terms in contracts with the users of the IANA functions that may limit what it can do. There are already requirements on ICANN in the gTLD registry agreement for example:
From: http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-...
"Article 3 "COVENANTS OF ICANN"
ICANN covenants and agrees with Registry Operator as follows:
3.1 Open and Transparent. Consistent with ICANN’s expressed mission and core values, ICANN shall operate in an open and transparent manner.
3.2 Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause.
3.3 TLD Nameservers. ICANN will use commercially reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at http://www.iana.org/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications.
3.4 Root-zone Information Publication. ICANN’s publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at http://www.iana.org/domains/root/.
3.5 Authoritative Root Database. To the extent that ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (a) ensure that the authoritative root will point to the top-level domain nameservers designated by Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction."
As a result of recommendations from this working group - additional text could be made part of the standard gTLD registry and registrar agreements.
And we have seen that ICANN sometimes has ambitions to do more than IANA – witness the proposal to spend money on broadband expansion.
Yes - I believe that statement was a possible area of spending noted by the CEO. I note however that it is not part of any approved budget, and the Board would be seeking a consensus of the ICANN community before it authorised such expenditure from any auction proceeds.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I agree Kavouss. Part of that decision process must be aware that for every good there is a bad so what is built in now before there is bad makes that a wise approach. As with all contracts, what is being crafted is the Divorce before the marriage or in other terms, the pre-nup. Best to cover the bad stuff now rather than assume it can never happen Carrie Devorah On Tue, Dec 30, 2014 at 11:11 AM, Kavouss Arasteh <kavouss.arasteh@gmail.com
wrote:
The issue is not about the individuals designated after transition. The issue is how and who designate these members What are the principles to be used in their désignations More importantly should they be nominated and then designated or They should be suggested and elected or There should be an open candidatships filling certain conditions and qualifications Then who and how the designation and or election is to be carried out . Individuals which are not designated and/ or elected by public Global Multistakeholders or their lega représentatives ) could not be held accountable to that entity. Regards Kavouss
2014-12-30 15:39 GMT+01:00 Carrie <carriedev@gmail.com>:
The BOARD talked about is this Board. Congress asks 'what happens when this Board is replaced with other members unknown today?
Sent from my iPhone
On Dec 30, 2014, at 9:11 AM, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:
Dear All, I ALSO think Avri is right – the solution set is binary. * If the Board/ICANN will accept in WS1 ** a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. *
COMMENT FROM KAVOUSS
This has exactly been proposed by CWG in their outcome draft to which the Board disagreed in its recent publication for public comments and I have surprised to read that and thus asked to discuss that matter in the agenda of this evening ,30 December CALL
*But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.” *
COMMENT FROM KAVOUSS
I do not understand why the Board will not accept that .They have told in their views for public comment that " it is duplication of work " does it means that any mechanism to properly address the replacement of NTIA for IANA functions are duplication of work? Does it mean that if no replacement is proposed and the function trusted to ICANN without a clear responsibility and transparaency in an acciountable manner it is not duplication ? Are we exchanging NTIA by ICANN ? Under the current practice, at least ICANN is accountable to NTIA . After the transition ICANN WOULD BE ACCOUNTABLE TO WHICH ENTITY? This is a core issue and must be fully examined and resolved Kavouss
2014-12-30 14:16 GMT+01:00 Paul Rosenzweig < paul.rosenzweig@redbranchconsulting.com>:
Bruce
Regarding your last below re: the seeking of consensus before spending on broadband, I think we have a fundamental disagreement. Even if the entire community were to want to do that, ICANN would be the wrong mechanism for achieving that goal -- for much the same reason that we don't ask a Department of Education to manage the health care system in a country. Both are important "good governance" functions but for reasons of expertise, focus and management we don't accept that. For that reason I see it as essential to prevent as far as is practicable ICANN from straying beyond the IANA mission. "Even the best intentions oft lead men astray."
Paul
**NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 *** 509 C St. NE Washington, DC 20002
Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 Skype: +1 (202) 738-1739 or paul.rosenzweig1066 Link to my PGP Key
-----Original Message----- From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] Sent: Tuesday, December 30, 2014 1:17 AM To: accountability-cross-community@icann.org Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1
Hello Paul,
I think Avri is exactly right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
I don’t think you should make that assumption yet. There is a difference between the Board’s views in forming a new entity (Contract Co.) to replace the NTIA, and the aboard agreeing to terms in contracts with the users of the IANA functions that may limit what it can do. There are already requirements on ICANN in the gTLD registry agreement for example:
From: http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-...
"Article 3 "COVENANTS OF ICANN"
ICANN covenants and agrees with Registry Operator as follows:
3.1 Open and Transparent. Consistent with ICANN’s expressed mission and core values, ICANN shall operate in an open and transparent manner.
3.2 Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause.
3.3 TLD Nameservers. ICANN will use commercially reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at http://www.iana.org/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications.
3.4 Root-zone Information Publication. ICANN’s publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at http://www.iana.org/domains/root/.
3.5 Authoritative Root Database. To the extent that ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (a) ensure that the authoritative root will point to the top-level domain nameservers designated by Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction."
As a result of recommendations from this working group - additional text could be made part of the standard gTLD registry and registrar agreements.
And we have seen that ICANN sometimes has ambitions to do more than IANA – witness the proposal to spend money on broadband expansion.
Yes - I believe that statement was a possible area of spending noted by the CEO. I note however that it is not part of any approved budget, and the Board would be seeking a consensus of the ICANN community before it authorised such expenditure from any auction proceeds.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Sincerely CARRIE Devorah 562 688 2883 DISCLAIMER : With the continuing crossing and interfacing of platforms both on & off line both with & without our knowledge nor approval to note nothing sent over the Internet anymore is ever private nor should be presumed to be so. If it is that much of a secret, say nothing. If you must? Take a lesson from our military- hand write the note, chew then swallow
sent from Google nexus 4 kindly excuse brevity and typos. On 30 Dec 2014 15:39, "Carrie" <carriedev@gmail.com> wrote:
The BOARD talked about is this Board. Congress asks 'what happens when
this Board is replaced with other members unknown today?
The board operates by the organisation bylaw...I think we under estimate what we can achieve with the bylaw. The situation of what-if mentioned above can also happen to any non-icann setup. I think the fact that we are tasked to transition to multistakeholder gives us the opportunity to further empower the ICANN community which is a known/open and converged multistakeholder. Regards
Sent from my iPhone
On Dec 30, 2014, at 9:11 AM, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:
Dear All, I ALSO think Avri is right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2.
COMMENT FROM KAVOUSS
This has exactly been proposed by CWG in their outcome draft to which the Board disagreed in its recent publication for public comments and I have surprised to read that and thus asked to discuss that matter in the agenda of this evening ,30 December CALL
But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
COMMENT FROM KAVOUSS
I do not understand why the Board will not accept that .They have told in their views for public comment that " it is duplication of work " does it means that any mechanism to properly address the replacement of NTIA for IANA functions are duplication of work? Does it mean that if no replacement is proposed and the function trusted to ICANN without a clear responsibility and transparaency in an acciountable manner it is not duplication ? Are we exchanging NTIA by ICANN ? Under the current practice, at least ICANN is accountable to NTIA . After the transition ICANN WOULD BE ACCOUNTABLE TO WHICH ENTITY? This is a core issue and must be fully examined and resolved Kavouss
2014-12-30 14:16 GMT+01:00 Paul Rosenzweig < paul.rosenzweig@redbranchconsulting.com>:
Bruce
Regarding your last below re: the seeking of consensus before spending
on broadband, I think we have a fundamental disagreement. Even if the entire community were to want to do that, ICANN would be the wrong mechanism for achieving that goal -- for much the same reason that we don't ask a Department of Education to manage the health care system in a country. Both are important "good governance" functions but for reasons of expertise, focus and management we don't accept that. For that reason I see it as essential to prevent as far as is practicable ICANN from straying beyond the IANA mission. "Even the best intentions oft lead men astray."
Paul
**NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 *** 509 C St. NE Washington, DC 20002
Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 Skype: +1 (202) 738-1739 or paul.rosenzweig1066 Link to my PGP Key
-----Original Message----- From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] Sent: Tuesday, December 30, 2014 1:17 AM To: accountability-cross-community@icann.org Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2:
draft 5.1
Hello Paul,
I think Avri is exactly right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual
boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
I don’t think you should make that assumption yet. There is a
difference between the Board’s views in forming a new entity (Contract Co.) to replace the NTIA, and the aboard agreeing to terms in contracts with the users of the IANA functions that may limit what it can do. There are already requirements on ICANN in the gTLD registry agreement for example:
From:
http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-...
"Article 3 "COVENANTS OF ICANN"
ICANN covenants and agrees with Registry Operator as follows:
3.1 Open and Transparent. Consistent with ICANN’s
expressed mission and core values, ICANN shall operate in an open and transparent manner.
3.2 Equitable Treatment. ICANN shall not apply
standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause.
3.3 TLD Nameservers. ICANN will use commercially
reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at http://www.iana.org/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications.
3.4 Root-zone Information Publication. ICANN’s
publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at http://www.iana.org/domains/root/.
3.5 Authoritative Root Database. To the extent that
ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (a) ensure that the authoritative root will point to the top-level domain nameservers designated by Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction."
As a result of recommendations from this working group - additional
text could be made part of the standard gTLD registry and registrar agreements.
And we have seen that ICANN sometimes has ambitions to do more than
IANA – witness the proposal to spend money on broadband expansion.
Yes - I believe that statement was a possible area of spending noted by
the CEO. I note however that it is not part of any approved budget, and the Board would be seeking a consensus of the ICANN community before it authorised such expenditure from any auction proceeds.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hello Kavouss,
If the Board/ICANN will accept in WS1 a proposal for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2.
In my personal view - this sounds reasonable in principle. >> COMMENT FROM KAVOUSS
This has exactly been proposed by CWG in their outcome draft to which the Board disagreed in its recent publication for public comments and I have surprised to read that and thus asked to discuss that matter in the agenda of this evening ,30 December CALL
I don't believe that Board has rejected that principle. The Board public input on the CWG proposal was focussed on the idea of replacing NTIA with a new entity Contract Co. The assumption being that NTIA would transfers its stewardship to this new entity that in turn would have to have substantial accountability controls. There are other ways ICANN and its Board can be held accountable via contracts, and using external mechanisms to police that the Board is complying with its bylaws and contracts. Regards, Bruce Tonkin
On 31/12/2014 03:54, Bruce Tonkin wrote:
Hello Kavouss,
If the Board/ICANN will accept in WS1 a proposal for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2.
In my personal view - this sounds reasonable in principle.
Previously, Avri wrote:
If it does stick with separability then a contractual relationship remains as an ongoing leverage point. In terms of CWG-Stewardship work, Contract Co holding the contract, still appears to be quite active as a proposal.
Perhaps we need to look at the WS1 list in terms of the binary discriminant: is there an ongoing contractual relationship with an eternal entity or not. I expect the WS1 list will vary based on which of these is being considered.
We need to be careful not to assume CWG-Stewardship has done more than it has, or that this lessens our workload. Firstly, the contractual relationship CWG-Stewardship are proposing only concerns the operations of IANA. They have explicitly left consideration of proposals to ensure the accountability of ICANN (including anything to do with gTLD policy) to this group. So it would be dangerous to assume that we don't need to consider something we might otherwise have done on the basis that CWG-Stewardship has covered it. Of course, it's open to us to build on what CWG-Stewardship have proposed. We could, for example, come up with additional terms for the contract, and propose that the MRT be responsible for overseeing and enforcing those terms. But it will be up to us - not CWG-Stewardship - to propose this. Secondly, concerning the "separability" that Avri refers to, separation of IANA from ICANN is a nuclear option. While I support this principle, to be available as a last resort, it should BE the last resort, not the first thing to which we turn. It shouldn't be used as a reason for this group to do less to come up with mechanisms to resolve existing problems, on the grounds that "if we end up being unhappy, we've still got separability": we need mechanisms short of separation, because we don't want to get in a situation where w're left with nothing but the choice is between a bad outcome and separation (another bad outcome). Finally, regarding Bruce's point about putting "most of the rest in WS2", well, possibly. But we mustn't let this redefine the ambit of WS1: anything which is fundamental to the accountability of ICANN, that can't be added by the community later, needs to be in WS1. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd 21-27 St Thomas Street, London SE1 9RY Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
sent from Google nexus 4 kindly excuse brevity and typos. On 30 Dec 2014 15:12, "Kavouss Arasteh" <kavouss.arasteh@gmail.com> wrote:
Dear All, I ALSO think Avri is right – the solution set is binary. If the
Board/ICANN will accept in WS1 a proposl for a strong contractual boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2.
COMMENT FROM KAVOUSS
This has exactly been proposed by CWG in their outcome draft to which the
Board disagreed in its recent publication for public comments and I have surprised to read that and thus asked to discuss that matter in the agenda of this evening ,30 December CALL
But my current understanding is that the Board/ICANN will not accept such
a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
COMMENT FROM KAVOUSS
I do not understand why the Board will not accept that .They have told in
their views for public comment that " it is duplication of work " does it means that any mechanism to properly address the replacement of NTIA for IANA functions are duplication of work?
I would not make a general conclusion as above. Maybe you should have a second look at the current CWG proposal to really determine whether it's really a mechanism that improves ICANN Accountability.
Does it mean that if no replacement is proposed and the function trusted to ICANN without a clear responsibility and transparaency in an acciountable manner it is not duplication ?
I also don't think anyone wants ICANN to be unaccountable, it's just the approach that differs. There definitely has to be a replacement and such replacement would be more effective and meet NTIA requirement if the multistakeholder community is further empowered.
Are we exchanging NTIA by ICANN ? Under the current practice, at least ICANN is accountable to NTIA . After the transition ICANN WOULD BE ACCOUNTABLE TO WHICH ENTITY?
The multistakeholder community which is the NTIA requirement
This is a core issue and must be fully examined and resolved
+1 Regards
Kavouss
2014-12-30 14:16 GMT+01:00 Paul Rosenzweig < paul.rosenzweig@redbranchconsulting.com>:
Bruce
Regarding your last below re: the seeking of consensus before spending
on broadband, I think we have a fundamental disagreement. Even if the entire community were to want to do that, ICANN would be the wrong mechanism for achieving that goal -- for much the same reason that we don't ask a Department of Education to manage the health care system in a country. Both are important "good governance" functions but for reasons of expertise, focus and management we don't accept that. For that reason I see it as essential to prevent as far as is practicable ICANN from straying beyond the IANA mission. "Even the best intentions oft lead men astray."
Paul
**NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 *** 509 C St. NE Washington, DC 20002
Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 Skype: +1 (202) 738-1739 or paul.rosenzweig1066 Link to my PGP Key
-----Original Message----- From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] Sent: Tuesday, December 30, 2014 1:17 AM To: accountability-cross-community@icann.org Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2:
draft 5.1
Hello Paul,
I think Avri is exactly right – the solution set is binary. If the Board/ICANN will accept in WS1 a proposl for a strong contractual
boundary on what they may do along with an external mechanism that can be invoked by the community to police that boundary, then most of the other accountability can be in WS2. But my current understanding is that the Board/ICANN will not accept such a proposal – indeed when I last spoke of it to a Board member, I was told it was “unnecessary.”
I don’t think you should make that assumption yet. There is a
difference between the Board’s views in forming a new entity (Contract Co.) to replace the NTIA, and the aboard agreeing to terms in contracts with the users of the IANA functions that may limit what it can do. There are already requirements on ICANN in the gTLD registry agreement for example:
From:
http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-...
"Article 3 "COVENANTS OF ICANN"
ICANN covenants and agrees with Registry Operator as follows:
3.1 Open and Transparent. Consistent with ICANN’s
expressed mission and core values, ICANN shall operate in an open and transparent manner.
3.2 Equitable Treatment. ICANN shall not apply
standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause.
3.3 TLD Nameservers. ICANN will use commercially
reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at http://www.iana.org/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications.
3.4 Root-zone Information Publication. ICANN’s
publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at http://www.iana.org/domains/root/.
3.5 Authoritative Root Database. To the extent that
ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (a) ensure that the authoritative root will point to the top-level domain nameservers designated by Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction."
As a result of recommendations from this working group - additional text
could be made part of the standard gTLD registry and registrar agreements.
And we have seen that ICANN sometimes has ambitions to do more than
IANA – witness the proposal to spend money on broadband expansion.
Yes - I believe that statement was a possible area of spending noted by
the CEO. I note however that it is not part of any approved budget, and the Board would be seeking a consensus of the ICANN community before it authorised such expenditure from any auction proceeds.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hello all, Steve thank you very much for the draft and for taking into account all considerations. I would like to make a clarification: On 29/12/14 01:53, Steve DelBianco wrote:
Hope all of you are enjoying the holidays. Work Team 2 has added several ideas and requests that arrived after 21-Dec. Draft v5.1 is attached, reflecting these changes:
CWG requests: IANA Stewardship CWG co-chairs Jonathan Robinson and Lise Fuhr requested 3 new accountability items in Category 1, Work Stream 1. These 3 items are flagged as* CWG* (in red and bold)
David Johnson: For Category 1, Work Stream 1, proposed a contract between ICANN and Registries & Registrars, with Registrants as 3rd party beneficiaries. Contract lets ICANN impose rules on others only when supported by consensus of affected parties. Disputes go to independent arbitration panel that could issue binding decisions. In a discussion with David, we thought the contract could work alongside the Member structure, not _instead_ of it.
Izumi Okutani and Athina Fragkouli noted support for four accountability items, but would place them in Work Stream 2 and suggested some wording changes.
The intention of the email Izumi and I sent was to comment regarding the allocation of these four accountability items to Work Stream 1 or 2. It was not our intention to provide support for particular accountability items. Thank you. Athina
Malcolm Hutty requested an item be moved to Work Stream 1: "Ensure that the ICANN Board can be held to its Bylaws, with effective remedy if breach found by independent adjudicator.” Seun Ojedeji requested an alternative: “found by the community"
Daniel Castro of ITIF and Wisdom Donkor requested Open Data transparency rules, in Category 3, Work Stream 2.
Guru Achayra: For Category 1, Work Stream 1, proposed an Accountability Contract between ICANN and ‘Contract Co.’ to replace the Affirmation of Commitments
Carlos Gutiérrez: requested 4 new prescribed actions in Category 3, Work Stream 2
Apologies if I have missed other suggestions. Look forward to discussing on our next call.
— Steve DelBianco Executive Director NetChoice http://www.NetChoice.org <http://www.netchoice.org/> and http://blog.netchoice.org <http://blog.netchoice.org/> +1.202.420.7482
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
participants (13)
-
Alan Greenberg -
Athina Fragkouli -
Avri Doria -
Bruce Tonkin -
Carrie -
Carrie Devorah
-
Jonathan Zuck -
Kavouss Arasteh -
Malcolm Hutty -
Mathieu Weill -
Paul Rosenzweig -
Seun Ojedeji -
Steve DelBianco