CCWG - Proposed Responses to questions on Draft Bylaws
All, Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability. These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic. The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
All, Please note that the document includes more than just the questions provided by the legal counsel. Be certain to go to the bottom of the document to see the additional questions that were included after the questions from legal counsel. Thank You. Bernard Turcotte ICANN Staff Support On Wed, Apr 6, 2016 at 6:30 PM, Bernard Turcotte <turcotte.bernard@gmail.com
wrote:
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
Please note that draft response to question 25 was missing in the circulated document. Pasting it here 25. CCWG Counsel and ICANN are not yet in alignment on the language to describe how a Petition in the EC process can be identified as based on GAC advice. Initially, “solely” was added to tie the Petition Notice to the GAC Consensus Board Resolution. For example, the ICANN Budget is an amalgamation of many different inputs. If a particular expenditure is tangentially related to GAC advice, then the GAC should not be removed from voting on that petition. CCWG Counsel has accepted this approach for purposes of this draft, with the small addition of “or almost solely”, and with the clarification that the EC could undertake two rejection petitions at the same time, one narrowly tailored to a GAC Consensus Board Resolution, and thus subject to the GAC carve out rule, and one that does not involve a GAC Consensus Board Resolution. It will be helpful to see if the CCWG thinks this approach captures the carve out rule, as CCWG understands it. ICANN’s concern rests with the issue that “almost solely” is not a generally understood standard against which to assess action, and does not provide guidance to the community, ICANN or future IRP panels. CCWG Response : The relevant sections of the Supplemental Report about the GAC carve out are : * Annex 1 - paragraph 8 and 44 * Board confirmation: When the Board takes action that is based on GAC consensus advice, the Board will need to state in its resolution that its decision was based on GAC consensus advice. * o GAC carve-out identified in petition to use Community Power: When a Board action that is based on GAC consensus advice is challenged, the petitioning SO or AC will need to indicate in the initial petition that the matter meets the requirements for the GAC carve-out and clearly identify the applicable Board action and GAC consensus advice at issue. The decision thresholds (as revised when the GAC carve-out is invoked in accordance in Annex 2) required for the escalation and enforcement processes will need to be met for the Community Power that is being exercised. Recognizing that different views exist within the CCWG about how a petition in the EC process can be identified as based on GAC Advice (solely based, entirely or almost entirely based, distinctively based…) and taking into account that (a) the Board decides whether to label a decision as based on GAC consenses advice; (b) the complaining party decides how to frame their complaint to meet the standard in the Bylaws and (c) any improper characterization could be subjected to an IRP, the CCWG recommends NOT to add any additional details on that process in the Bylaws. De : accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] De la part de Bernard Turcotte Envoyé : jeudi 7 avril 2016 00:35 À : Accountability Cross Community Objet : Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws All, Please note that the document includes more than just the questions provided by the legal counsel. Be certain to go to the bottom of the document to see the additional questions that were included after the questions from legal counsel. Thank You. Bernard Turcotte ICANN Staff Support On Wed, Apr 6, 2016 at 6:30 PM, Bernard Turcotte <turcotte.bernard@gmail.com> wrote: All, Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability. These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic. The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
Sent from my LG G4 Kindly excuse brevity and typos On 7 Apr 2016 7:33 a.m., "Mathieu Weill" <mathieu.weill@afnic.fr> wrote:
CCWG Response : The relevant sections of the Supplemental Report about
the GAC carve out are :
Annex 1 - paragraph 8 and 44 Board confirmation: When the Board takes action that is based on GAC
consensus advice, the Board will need to state in its resolution that its decision was based on GAC consensus advice.
o GAC carve-out identified in petition to use Community Power: When a Board action that is based on GAC consensus advice is challenged, the petitioning SO or AC will need to indicate in the initial petition that the matter meets the requirements for the GAC carve-out and clearly identify the applicable Board action and GAC consensus advice at issue. The decision thresholds (as revised when the GAC carve-out is invoked in accordance in Annex 2) required for the escalation and enforcement processes will need to be met for the Community Power that is being exercised.
Recognizing that different views exist within the CCWG about how a petition in the EC process can be identified as based on GAC Advice (solely based, entirely or almost entirely based, distinctively based…) and taking into account that (a) the Board decides whether to label a decision as based on GAC consenses advice; (b) the complaining party decides how to frame their complaint to meet the standard in the Bylaws and (c) any improper characterization could be subjected to an IRP, the CCWG recommends NOT to add any additional details on that process in the Bylaws.
Very good response with clear rationale. my +1 to the draft response provided by the Co-Chairs. Regards
De : accountability-cross-community-bounces@icann.org [mailto:
accountability-cross-community-bounces@icann.org] De la part de Bernard Turcotte
Envoyé : jeudi 7 avril 2016 00:35 À : Accountability Cross Community Objet : Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
All,
Please note that the document includes more than just the questions provided by the legal counsel. Be certain to go to the bottom of the document to see the additional questions that were included after the questions from legal counsel.
Thank You.
Bernard Turcotte
ICANN Staff Support
On Wed, Apr 6, 2016 at 6:30 PM, Bernard Turcotte < turcotte.bernard@gmail.com> wrote:
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Thanks Bernard Whose response is the very last „CCWG response“ (p. 15 of the pdf)? Thanks and regards Jorge Von: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] Im Auftrag von Bernard Turcotte Gesendet: Donnerstag, 7. April 2016 00:30 An: Accountability Cross Community <accountability-cross-community@icann.org> Betreff: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws All, Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability. These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic. The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
Hi Jorge, please note that the responses to the questions are draft proposals for the CCWG's consideration during the call later today. These have been prepared by rapporteurs and Co-Chairs in order to facilitate the discussion. Thanks and regards, Thomas Am 07.04.2016 um 09:24 schrieb Jorge.Cancio@bakom.admin.ch:
Thanks Bernard
Whose response is the very last „/CCWG response/“ (p. 15 of the pdf)?
Thanks and regards
Jorge
*Von:*accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] *Im Auftrag von *Bernard Turcotte *Gesendet:* Donnerstag, 7. April 2016 00:30 *An:* Accountability Cross Community <accountability-cross-community@icann.org> *Betreff:* [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
--
2016-04-07 9:24 GMT+02:00 <Jorge.Cancio@bakom.admin.ch>:
Thanks Bernard
Whose response is the very last „*CCWG response*“ (p. 15 of the pdf)?
Thanks and regards
Jorge
*Von:* accountability-cross-community-bounces@icann.org [mailto: accountability-cross-community-bounces@icann.org] *Im Auftrag von *Bernard Turcotte *Gesendet:* Donnerstag, 7. April 2016 00:30 *An:* Accountability Cross Community < accountability-cross-community@icann.org> *Betreff:* [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear Bertrand I have ck my notes and hereby send you back my comments regarding questions raised Kavouss
Dear colleagues, Many apologies for missing calls this week, but as I noted in Marrakesh this week is the IETF meeting and I have approximately no time. Anyway, I have some remarks. I'm sorry these are lengthy. Q1 On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone". I reject unequivocally the argument, "It is not true that ICANN coordinates assignment ONLY in the root zone, as such term is currently understood. ICANN’s gTLD registry and registrar agreements and policies deal substantially and primarily with issues relating to assignment of names at the second (and in some cases lower) levels of the DNS." ICANN's gTLD registry and registrar agreements an policies deal susbtantially and primarily with how _those registries and registrars_ coordinate assignment in zones outside the root zone. That is, ICANN's agreements are a meta-requirement on how other people do co-ordination in the DNS, and do not actualy perform the co-ordination I know that this seems like a fine distinction. But it's important to keep it in mind because the language that have been in the bylaws historically, and that the CCWG has agreed to restore, is the very basis on which various people around the Internet mistake ICANN for the Internet Police. By removing the restriction to the root zone, we are once again freeing ICANN to assert control down the DNS -- a control that is very much inconsistent with the distributed authority design of the DNS. Q3 It might be worth observing also that, since the requester is the person who asked for the transcripts and recordings, presumably the requester could be asked about certain redactions due to the issues outlined. Q6 The proposal for the community just to endorse whatever the board decides here strikes me as potentially risky. Supposed the community replaces a recalled board member with a new one that is less accommodating of a prevailing majority of the Board. The Board would be able to remove that new director with a 75% majority. If the EC does not have the ability to reject the Board's decision to remove, then there could be a procedural deadlock that could only be ameliorated by a complete replacement of the Board. That seems undesirable. Q17 I believe the requested addition is overspecification. It will simply yield disputes about whether a given recommendation is limited in the relevant way. Q25 The document says Initially, “solely” was added to tie the Petition Notice to the GAC Consensus Board Resolution. For example, the ICANN Budget is an amalgamation of many different inputs. If a particular expenditure is tangentially related to GAC advice, then the GAC should not be removed from voting on that petition. I don't understand this argument. There are two possibilities: either the expenditure is solely related to GAC advice (in which case, whether it's "tangential" is irrelevant) or it is not. If it is not, then the GAC exclusion is not entailed. If it is solely related to GAC advice, then I don't get the claim above that the GAC should not be excluded -- that's the whole point of the "carve out". I hope these remarks are useful. Please see also the remarks that I sent in collaboration with my colleagues on the IAB. Best regards, A On Wed, Apr 06, 2016 at 06:30:14PM -0400, Bernard Turcotte wrote:
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Andrew Sullivan ajs@anvilwalrusden.com
Thanks Andrew, these are interesting comments. I agree on 6 and raised similar concerns in the chat Tuesday. On 25, I agree that the problem is lack of clarity. It needs to be clear when a decision is based on GAC consensus or not. Also, there is the danger of wrapping a decision based GAC consensus advice into a larger group of unrelated matters. Intentionally or not, it could force the EC into the undesirable position of (1) not opposing a decision based on GAC consensus advice it does not like or (2) opposing it knowing that the unrelated matters that have broad support will also be blocked with it. This is why I suggested echoing Article 25.3 to avoid this dilemma. Article 25.3 states: · The Board shall not combine an amendment of these Bylaws that was the result of a policy development process of a Supporting Organization (a “PDP Amendment”) with any other amendment. The Board shall indicate in the applicable Board Notice whether such amendment is a PDP Amendment. Here is the text that I suggested: · The Board shall not combine a decision based on or consistent with consensus GAC advice with any other decision. The Board shall indicate in the applicable Board Notice whether such a decision is based on or is consistent with consensus GAC advice. If people have helpful edits, go at it. But I think this would separate – in a helpful way – Board decisions based on GAC consensus advice. I don’t think it would be onerous. Consensus GAC decisions are not all that frequent and, under the amended bylaws, must be indicated as such when sent to the Board. If the GAC advice is supported elsewhere in the community this requirement should not be problematic because broadly supported advice would not pass thresholds for EC escalation. But it would allow the EC to consider and, if desired, address decisions based on GAC consensus advice in a targeted manner. As mentioned in the chat, this in no way is an extension of the GAC carve-out. It would just help clarify when it might apply. Best, Brett ________________________________ Brett Schaefer Jay Kingham Senior Research Fellow in International Regulatory Affairs Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy The Heritage Foundation 214 Massachusetts Avenue, NE Washington, DC 20002 202-608-6097 heritage.org<http://heritage.org/> From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, April 07, 2016 9:48 AM To: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws Dear colleagues, Many apologies for missing calls this week, but as I noted in Marrakesh this week is the IETF meeting and I have approximately no time. Anyway, I have some remarks. I'm sorry these are lengthy. Q1 On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone". I reject unequivocally the argument, "It is not true that ICANN coordinates assignment ONLY in the root zone, as such term is currently understood. ICANN’s gTLD registry and registrar agreements and policies deal substantially and primarily with issues relating to assignment of names at the second (and in some cases lower) levels of the DNS." ICANN's gTLD registry and registrar agreements an policies deal susbtantially and primarily with how _those registries and registrars_ coordinate assignment in zones outside the root zone. That is, ICANN's agreements are a meta-requirement on how other people do co-ordination in the DNS, and do not actualy perform the co-ordination I know that this seems like a fine distinction. But it's important to keep it in mind because the language that have been in the bylaws historically, and that the CCWG has agreed to restore, is the very basis on which various people around the Internet mistake ICANN for the Internet Police. By removing the restriction to the root zone, we are once again freeing ICANN to assert control down the DNS -- a control that is very much inconsistent with the distributed authority design of the DNS. Q3 It might be worth observing also that, since the requester is the person who asked for the transcripts and recordings, presumably the requester could be asked about certain redactions due to the issues outlined. Q6 The proposal for the community just to endorse whatever the board decides here strikes me as potentially risky. Supposed the community replaces a recalled board member with a new one that is less accommodating of a prevailing majority of the Board. The Board would be able to remove that new director with a 75% majority. If the EC does not have the ability to reject the Board's decision to remove, then there could be a procedural deadlock that could only be ameliorated by a complete replacement of the Board. That seems undesirable. Q17 I believe the requested addition is overspecification. It will simply yield disputes about whether a given recommendation is limited in the relevant way. Q25 The document says Initially, “solely” was added to tie the Petition Notice to the GAC Consensus Board Resolution. For example, the ICANN Budget is an amalgamation of many different inputs. If a particular expenditure is tangentially related to GAC advice, then the GAC should not be removed from voting on that petition. I don't understand this argument. There are two possibilities: either the expenditure is solely related to GAC advice (in which case, whether it's "tangential" is irrelevant) or it is not. If it is not, then the GAC exclusion is not entailed. If it is solely related to GAC advice, then I don't get the claim above that the GAC should not be excluded -- that's the whole point of the "carve out". I hope these remarks are useful. Please see also the remarks that I sent in collaboration with my colleagues on the IAB. Best regards, A On Wed, Apr 06, 2016 at 06:30:14PM -0400, Bernard Turcotte wrote:
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
_______________________________________________ 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<https://mm.icann.org/mailman/listinfo/accountability-cross-community>
-- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> _______________________________________________ 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<https://mm.icann.org/mailman/listinfo/accountability-cross-community>
Dear all Just to reiterate what some of us said in the chat yesterday: - GAC Advice is almost always linked to a community process, and the tendency (and wish) is to increase this - GAC Advice is actually quite frequent (at least three times a year) - There is no basis in the CCWG report for isolating GAC Advice from other inputs from the community, and it would be counter to the multistakeholder fashion we work and/or we are trying to work within ICANN Hope this helps Regards Jorge Von: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] Im Auftrag von Schaefer, Brett Gesendet: Donnerstag, 7. April 2016 16:31 An: Andrew Sullivan <ajs@anvilwalrusden.com>; accountability-cross-community@icann.org Betreff: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws Thanks Andrew, these are interesting comments. I agree on 6 and raised similar concerns in the chat Tuesday. On 25, I agree that the problem is lack of clarity. It needs to be clear when a decision is based on GAC consensus or not. Also, there is the danger of wrapping a decision based GAC consensus advice into a larger group of unrelated matters. Intentionally or not, it could force the EC into the undesirable position of (1) not opposing a decision based on GAC consensus advice it does not like or (2) opposing it knowing that the unrelated matters that have broad support will also be blocked with it. This is why I suggested echoing Article 25.3 to avoid this dilemma. Article 25.3 states: · The Board shall not combine an amendment of these Bylaws that was the result of a policy development process of a Supporting Organization (a “PDP Amendment”) with any other amendment. The Board shall indicate in the applicable Board Notice whether such amendment is a PDP Amendment. Here is the text that I suggested: · The Board shall not combine a decision based on or consistent with consensus GAC advice with any other decision. The Board shall indicate in the applicable Board Notice whether such a decision is based on or is consistent with consensus GAC advice. If people have helpful edits, go at it. But I think this would separate – in a helpful way – Board decisions based on GAC consensus advice. I don’t think it would be onerous. Consensus GAC decisions are not all that frequent and, under the amended bylaws, must be indicated as such when sent to the Board. If the GAC advice is supported elsewhere in the community this requirement should not be problematic because broadly supported advice would not pass thresholds for EC escalation. But it would allow the EC to consider and, if desired, address decisions based on GAC consensus advice in a targeted manner. As mentioned in the chat, this in no way is an extension of the GAC carve-out. It would just help clarify when it might apply. Best, Brett ________________________________ Brett Schaefer Jay Kingham Senior Research Fellow in International Regulatory Affairs Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy The Heritage Foundation 214 Massachusetts Avenue, NE Washington, DC 20002 202-608-6097 heritage.org<http://heritage.org/> From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, April 07, 2016 9:48 AM To: accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws Dear colleagues, Many apologies for missing calls this week, but as I noted in Marrakesh this week is the IETF meeting and I have approximately no time. Anyway, I have some remarks. I'm sorry these are lengthy. Q1 On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone". I reject unequivocally the argument, "It is not true that ICANN coordinates assignment ONLY in the root zone, as such term is currently understood. ICANN’s gTLD registry and registrar agreements and policies deal substantially and primarily with issues relating to assignment of names at the second (and in some cases lower) levels of the DNS." ICANN's gTLD registry and registrar agreements an policies deal susbtantially and primarily with how _those registries and registrars_ coordinate assignment in zones outside the root zone. That is, ICANN's agreements are a meta-requirement on how other people do co-ordination in the DNS, and do not actualy perform the co-ordination I know that this seems like a fine distinction. But it's important to keep it in mind because the language that have been in the bylaws historically, and that the CCWG has agreed to restore, is the very basis on which various people around the Internet mistake ICANN for the Internet Police. By removing the restriction to the root zone, we are once again freeing ICANN to assert control down the DNS -- a control that is very much inconsistent with the distributed authority design of the DNS. Q3 It might be worth observing also that, since the requester is the person who asked for the transcripts and recordings, presumably the requester could be asked about certain redactions due to the issues outlined. Q6 The proposal for the community just to endorse whatever the board decides here strikes me as potentially risky. Supposed the community replaces a recalled board member with a new one that is less accommodating of a prevailing majority of the Board. The Board would be able to remove that new director with a 75% majority. If the EC does not have the ability to reject the Board's decision to remove, then there could be a procedural deadlock that could only be ameliorated by a complete replacement of the Board. That seems undesirable. Q17 I believe the requested addition is overspecification. It will simply yield disputes about whether a given recommendation is limited in the relevant way. Q25 The document says Initially, “solely” was added to tie the Petition Notice to the GAC Consensus Board Resolution. For example, the ICANN Budget is an amalgamation of many different inputs. If a particular expenditure is tangentially related to GAC advice, then the GAC should not be removed from voting on that petition. I don't understand this argument. There are two possibilities: either the expenditure is solely related to GAC advice (in which case, whether it's "tangential" is irrelevant) or it is not. If it is not, then the GAC exclusion is not entailed. If it is solely related to GAC advice, then I don't get the claim above that the GAC should not be excluded -- that's the whole point of the "carve out". I hope these remarks are useful. Please see also the remarks that I sent in collaboration with my colleagues on the IAB. Best regards, A On Wed, Apr 06, 2016 at 06:30:14PM -0400, Bernard Turcotte wrote:
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
_______________________________________________ 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
-- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> _______________________________________________ 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
Jorge+1 Kavousd Sent from my iPhone
On 8 Apr 2016, at 08:52, <Jorge.Cancio@bakom.admin.ch> <Jorge.Cancio@bakom.admin.ch> wrote:
Dear all
Just to reiterate what some of us said in the chat yesterday:
- GAC Advice is almost always linked to a community process, and the tendency (and wish) is to increase this - GAC Advice is actually quite frequent (at least three times a year) - There is no basis in the CCWG report for isolating GAC Advice from other inputs from the community, and it would be counter to the multistakeholder fashion we work and/or we are trying to work within ICANN
Hope this helps
Regards
Jorge
Von: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] Im Auftrag von Schaefer, Brett Gesendet: Donnerstag, 7. April 2016 16:31 An: Andrew Sullivan <ajs@anvilwalrusden.com>; accountability-cross-community@icann.org Betreff: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
Thanks Andrew, these are interesting comments.
I agree on 6 and raised similar concerns in the chat Tuesday.
On 25, I agree that the problem is lack of clarity. It needs to be clear when a decision is based on GAC consensus or not.
Also, there is the danger of wrapping a decision based GAC consensus advice into a larger group of unrelated matters. Intentionally or not, it could force the EC into the undesirable position of (1) not opposing a decision based on GAC consensus advice it does not like or (2) opposing it knowing that the unrelated matters that have broad support will also be blocked with it.
This is why I suggested echoing Article 25.3 to avoid this dilemma. Article 25.3 states:
· The Board shall not combine an amendment of these Bylaws that was the result of a policy development process of a Supporting Organization (a “PDP Amendment”) with any other amendment. The Board shall indicate in the applicable Board Notice whether such amendment is a PDP Amendment.
Here is the text that I suggested:
· The Board shall not combine a decision based on or consistent with consensus GAC advice with any other decision. The Board shall indicate in the applicable Board Notice whether such a decision is based on or is consistent with consensus GAC advice.
If people have helpful edits, go at it. But I think this would separate – in a helpful way – Board decisions based on GAC consensus advice. I don’t think it would be onerous. Consensus GAC decisions are not all that frequent and, under the amended bylaws, must be indicated as such when sent to the Board.
If the GAC advice is supported elsewhere in the community this requirement should not be problematic because broadly supported advice would not pass thresholds for EC escalation. But it would allow the EC to consider and, if desired, address decisions based on GAC consensus advice in a targeted manner.
As mentioned in the chat, this in no way is an extension of the GAC carve-out. It would just help clarify when it might apply.
Best,
Brett
Brett Schaefer Jay Kingham Senior Research Fellow in International Regulatory Affairs Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy The Heritage Foundation 214 Massachusetts Avenue, NE Washington, DC 20002 202-608-6097 heritage.org From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, April 07, 2016 9:48 AM To: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
Dear colleagues,
Many apologies for missing calls this week, but as I noted in Marrakesh this week is the IETF meeting and I have approximately no time.
Anyway, I have some remarks. I'm sorry these are lengthy.
Q1
On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone".
I reject unequivocally the argument, "It is not true that ICANN coordinates assignment ONLY in the root zone, as such term is currently understood. ICANN’s gTLD registry and registrar agreements and policies deal substantially and primarily with issues relating to assignment of names at the second (and in some cases lower) levels of the DNS." ICANN's gTLD registry and registrar agreements an policies deal susbtantially and primarily with how _those registries and registrars_ coordinate assignment in zones outside the root zone. That is, ICANN's agreements are a meta-requirement on how other people do co-ordination in the DNS, and do not actualy perform the co-ordination
I know that this seems like a fine distinction. But it's important to keep it in mind because the language that have been in the bylaws historically, and that the CCWG has agreed to restore, is the very basis on which various people around the Internet mistake ICANN for the Internet Police. By removing the restriction to the root zone, we are once again freeing ICANN to assert control down the DNS -- a control that is very much inconsistent with the distributed authority design of the DNS.
Q3
It might be worth observing also that, since the requester is the person who asked for the transcripts and recordings, presumably the requester could be asked about certain redactions due to the issues outlined.
Q6
The proposal for the community just to endorse whatever the board decides here strikes me as potentially risky. Supposed the community replaces a recalled board member with a new one that is less accommodating of a prevailing majority of the Board. The Board would be able to remove that new director with a 75% majority. If the EC does not have the ability to reject the Board's decision to remove, then there could be a procedural deadlock that could only be ameliorated by a complete replacement of the Board. That seems undesirable.
Q17
I believe the requested addition is overspecification. It will simply yield disputes about whether a given recommendation is limited in the relevant way.
Q25
The document says
Initially, “solely” was added to tie the Petition Notice to the GAC Consensus Board Resolution. For example, the ICANN Budget is an amalgamation of many different inputs. If a particular expenditure is tangentially related to GAC advice, then the GAC should not be removed from voting on that petition.
I don't understand this argument. There are two possibilities: either the expenditure is solely related to GAC advice (in which case, whether it's "tangential" is irrelevant) or it is not. If it is not, then the GAC exclusion is not entailed. If it is solely related to GAC advice, then I don't get the claim above that the GAC should not be excluded -- that's the whole point of the "carve out".
I hope these remarks are useful. Please see also the remarks that I sent in collaboration with my colleagues on the IAB.
Best regards,
A
On Wed, Apr 06, 2016 at 06:30:14PM -0400, Bernard Turcotte wrote:
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ 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
Dear Jorge I think this serves to underline that in the new era of transversal working with the GNSO in particular, the so-called "carve-out" from a community escalation decision in instances where the Board decision would be based solely on GAC advice, would be an extremely rare occurrence. Plus of course the GAC would be advising the community throughout such a decision stage: as has been made clear in the CCWG discussions several times, while not being able to exercise a vote due to the carve-out, governments would not be excluded from this process. Kind regards Mark Mark Carvell Global Internet Governance Policy Department for Culture, Media and Sport mark.carvell@culture.gov.uk tel +44 (0) 20 7211 6062 On 8 April 2016 at 08:54, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:
Jorge+1 Kavousd
Sent from my iPhone
On 8 Apr 2016, at 08:52, <Jorge.Cancio@bakom.admin.ch> < Jorge.Cancio@bakom.admin.ch> wrote:
Dear all
Just to reiterate what some of us said in the chat yesterday:
- GAC Advice is almost always linked to a community process, and the tendency (and wish) is to increase this
- GAC Advice is actually quite frequent (at least three times a year)
- There is no basis in the CCWG report for isolating GAC Advice from other inputs from the community, and it would be counter to the multistakeholder fashion we work and/or we are trying to work within ICANN
Hope this helps
Regards
Jorge
*Von:* accountability-cross-community-bounces@icann.org [ mailto:accountability-cross-community-bounces@icann.org <accountability-cross-community-bounces@icann.org>] *Im Auftrag von *Schaefer, Brett *Gesendet:* Donnerstag, 7. April 2016 16:31 *An:* Andrew Sullivan <ajs@anvilwalrusden.com>; accountability-cross-community@icann.org *Betreff:* Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
Thanks Andrew, these are interesting comments.
I agree on 6 and raised similar concerns in the chat Tuesday.
On 25, I agree that the problem is lack of clarity. It needs to be clear when a decision is based on GAC consensus or not.
Also, there is the danger of wrapping a decision based GAC consensus advice into a larger group of unrelated matters. Intentionally or not, it could force the EC into the undesirable position of (1) not opposing a decision based on GAC consensus advice it does not like or (2) opposing it knowing that the unrelated matters that have broad support will also be blocked with it.
This is why I suggested echoing Article 25.3 to avoid this dilemma. Article 25.3 states:
· The Board shall not combine an amendment of these Bylaws that was the result of a policy development process of a Supporting Organization (a “PDP Amendment”) with any other amendment. The Board shall indicate in the applicable Board Notice whether such amendment is a PDP Amendment.
Here is the text that I suggested:
· The Board shall not combine a decision based on or consistent with consensus GAC advice with any other decision. The Board shall indicate in the applicable Board Notice whether such a decision is based on or is consistent with consensus GAC advice.
If people have helpful edits, go at it. But I think this would separate – in a helpful way – Board decisions based on GAC consensus advice. I don’t think it would be onerous. Consensus GAC decisions are not all that frequent and, under the amended bylaws, must be indicated as such when sent to the Board.
If the GAC advice is supported elsewhere in the community this requirement should not be problematic because broadly supported advice would not pass thresholds for EC escalation. But it would allow the EC to consider and, if desired, address decisions based on GAC consensus advice in a targeted manner.
As mentioned in the chat, this in no way is an extension of the GAC carve-out. It would just help clarify when it might apply.
Best,
Brett
------------------------------
*Brett* *Schaefer*
* Jay Kingham Senior Research Fellow in International Regulatory Affairs Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy* The Heritage Foundation 214 Massachusetts Avenue, NE Washington, DC 20002 202-608-6097 heritage.org
*From:* accountability-cross-community-bounces@icann.org [ mailto:accountability-cross-community-bounces@icann.org <accountability-cross-community-bounces@icann.org>] *On Behalf Of *Andrew Sullivan *Sent:* Thursday, April 07, 2016 9:48 AM *To:* accountability-cross-community@icann.org *Subject:* Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
Dear colleagues,
Many apologies for missing calls this week, but as I noted in Marrakesh this week is the IETF meeting and I have approximately no time.
Anyway, I have some remarks. I'm sorry these are lengthy.
Q1
On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone".
I reject unequivocally the argument, "It is not true that ICANN coordinates assignment ONLY in the root zone, as such term is currently understood. ICANN’s gTLD registry and registrar agreements and policies deal substantially and primarily with issues relating to assignment of names at the second (and in some cases lower) levels of the DNS." ICANN's gTLD registry and registrar agreements an policies deal susbtantially and primarily with how _those registries and registrars_ coordinate assignment in zones outside the root zone. That is, ICANN's agreements are a meta-requirement on how other people do co-ordination in the DNS, and do not actualy perform the co-ordination
I know that this seems like a fine distinction. But it's important to keep it in mind because the language that have been in the bylaws historically, and that the CCWG has agreed to restore, is the very basis on which various people around the Internet mistake ICANN for the Internet Police. By removing the restriction to the root zone, we are once again freeing ICANN to assert control down the DNS -- a control that is very much inconsistent with the distributed authority design of the DNS.
Q3
It might be worth observing also that, since the requester is the person who asked for the transcripts and recordings, presumably the requester could be asked about certain redactions due to the issues outlined.
Q6
The proposal for the community just to endorse whatever the board decides here strikes me as potentially risky. Supposed the community replaces a recalled board member with a new one that is less accommodating of a prevailing majority of the Board. The Board would be able to remove that new director with a 75% majority. If the EC does not have the ability to reject the Board's decision to remove, then there could be a procedural deadlock that could only be ameliorated by a complete replacement of the Board. That seems undesirable.
Q17
I believe the requested addition is overspecification. It will simply yield disputes about whether a given recommendation is limited in the relevant way.
Q25
The document says
Initially, “solely” was added to tie the Petition Notice to the GAC Consensus Board Resolution. For example, the ICANN Budget is an amalgamation of many different inputs. If a particular expenditure is tangentially related to GAC advice, then the GAC should not be removed from voting on that petition.
I don't understand this argument. There are two possibilities: either the expenditure is solely related to GAC advice (in which case, whether it's "tangential" is irrelevant) or it is not. If it is not, then the GAC exclusion is not entailed. If it is solely related to GAC advice, then I don't get the claim above that the GAC should not be excluded -- that's the whole point of the "carve out".
I hope these remarks are useful. Please see also the remarks that I sent in collaboration with my colleagues on the IAB.
Best regards,
A
On Wed, Apr 06, 2016 at 06:30:14PM -0400, Bernard Turcotte wrote:
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ 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
Mark It is good that you replied to one of the small angle of the famous carve out However, all GAC members were expected seriously consider my proposal as sent to GAC list re not going to the heavy and rigoureous drafting for inclusion many many improbable cases in the Bylaws but just cut and paste the texts as contained in Recs. 1 &2 Pls reply KAVOUSS 2016-04-08 13:04 GMT+02:00 Mark Carvell <mark.carvell@culture.gov.uk>:
Dear Jorge
I think this serves to underline that in the new era of transversal working with the GNSO in particular, the so-called "carve-out" from a community escalation decision in instances where the Board decision would be based solely on GAC advice, would be an extremely rare occurrence. Plus of course the GAC would be advising the community throughout such a decision stage: as has been made clear in the CCWG discussions several times, while not being able to exercise a vote due to the carve-out, governments would not be excluded from this process.
Kind regards
Mark
Mark Carvell Global Internet Governance Policy Department for Culture, Media and Sport mark.carvell@culture.gov.uk tel +44 (0) 20 7211 6062
On 8 April 2016 at 08:54, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:
Jorge+1 Kavousd
Sent from my iPhone
On 8 Apr 2016, at 08:52, <Jorge.Cancio@bakom.admin.ch> < Jorge.Cancio@bakom.admin.ch> wrote:
Dear all
Just to reiterate what some of us said in the chat yesterday:
- GAC Advice is almost always linked to a community process, and the tendency (and wish) is to increase this
- GAC Advice is actually quite frequent (at least three times a year)
- There is no basis in the CCWG report for isolating GAC Advice from other inputs from the community, and it would be counter to the multistakeholder fashion we work and/or we are trying to work within ICANN
Hope this helps
Regards
Jorge
*Von:* accountability-cross-community-bounces@icann.org [ mailto:accountability-cross-community-bounces@icann.org <accountability-cross-community-bounces@icann.org>] *Im Auftrag von *Schaefer, Brett *Gesendet:* Donnerstag, 7. April 2016 16:31 *An:* Andrew Sullivan <ajs@anvilwalrusden.com>; accountability-cross-community@icann.org *Betreff:* Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
Thanks Andrew, these are interesting comments.
I agree on 6 and raised similar concerns in the chat Tuesday.
On 25, I agree that the problem is lack of clarity. It needs to be clear when a decision is based on GAC consensus or not.
Also, there is the danger of wrapping a decision based GAC consensus advice into a larger group of unrelated matters. Intentionally or not, it could force the EC into the undesirable position of (1) not opposing a decision based on GAC consensus advice it does not like or (2) opposing it knowing that the unrelated matters that have broad support will also be blocked with it.
This is why I suggested echoing Article 25.3 to avoid this dilemma. Article 25.3 states:
· The Board shall not combine an amendment of these Bylaws that was the result of a policy development process of a Supporting Organization (a “PDP Amendment”) with any other amendment. The Board shall indicate in the applicable Board Notice whether such amendment is a PDP Amendment.
Here is the text that I suggested:
· The Board shall not combine a decision based on or consistent with consensus GAC advice with any other decision. The Board shall indicate in the applicable Board Notice whether such a decision is based on or is consistent with consensus GAC advice.
If people have helpful edits, go at it. But I think this would separate – in a helpful way – Board decisions based on GAC consensus advice. I don’t think it would be onerous. Consensus GAC decisions are not all that frequent and, under the amended bylaws, must be indicated as such when sent to the Board.
If the GAC advice is supported elsewhere in the community this requirement should not be problematic because broadly supported advice would not pass thresholds for EC escalation. But it would allow the EC to consider and, if desired, address decisions based on GAC consensus advice in a targeted manner.
As mentioned in the chat, this in no way is an extension of the GAC carve-out. It would just help clarify when it might apply.
Best,
Brett
------------------------------
*Brett* *Schaefer*
* Jay Kingham Senior Research Fellow in International Regulatory Affairs Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy* The Heritage Foundation 214 Massachusetts Avenue, NE Washington, DC 20002 202-608-6097 heritage.org
*From:* accountability-cross-community-bounces@icann.org [ mailto:accountability-cross-community-bounces@icann.org <accountability-cross-community-bounces@icann.org>] *On Behalf Of *Andrew Sullivan *Sent:* Thursday, April 07, 2016 9:48 AM *To:* accountability-cross-community@icann.org *Subject:* Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
Dear colleagues,
Many apologies for missing calls this week, but as I noted in Marrakesh this week is the IETF meeting and I have approximately no time.
Anyway, I have some remarks. I'm sorry these are lengthy.
Q1
On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone".
I reject unequivocally the argument, "It is not true that ICANN coordinates assignment ONLY in the root zone, as such term is currently understood. ICANN’s gTLD registry and registrar agreements and policies deal substantially and primarily with issues relating to assignment of names at the second (and in some cases lower) levels of the DNS." ICANN's gTLD registry and registrar agreements an policies deal susbtantially and primarily with how _those registries and registrars_ coordinate assignment in zones outside the root zone. That is, ICANN's agreements are a meta-requirement on how other people do co-ordination in the DNS, and do not actualy perform the co-ordination
I know that this seems like a fine distinction. But it's important to keep it in mind because the language that have been in the bylaws historically, and that the CCWG has agreed to restore, is the very basis on which various people around the Internet mistake ICANN for the Internet Police. By removing the restriction to the root zone, we are once again freeing ICANN to assert control down the DNS -- a control that is very much inconsistent with the distributed authority design of the DNS.
Q3
It might be worth observing also that, since the requester is the person who asked for the transcripts and recordings, presumably the requester could be asked about certain redactions due to the issues outlined.
Q6
The proposal for the community just to endorse whatever the board decides here strikes me as potentially risky. Supposed the community replaces a recalled board member with a new one that is less accommodating of a prevailing majority of the Board. The Board would be able to remove that new director with a 75% majority. If the EC does not have the ability to reject the Board's decision to remove, then there could be a procedural deadlock that could only be ameliorated by a complete replacement of the Board. That seems undesirable.
Q17
I believe the requested addition is overspecification. It will simply yield disputes about whether a given recommendation is limited in the relevant way.
Q25
The document says
Initially, “solely” was added to tie the Petition Notice to the GAC Consensus Board Resolution. For example, the ICANN Budget is an amalgamation of many different inputs. If a particular expenditure is tangentially related to GAC advice, then the GAC should not be removed from voting on that petition.
I don't understand this argument. There are two possibilities: either the expenditure is solely related to GAC advice (in which case, whether it's "tangential" is irrelevant) or it is not. If it is not, then the GAC exclusion is not entailed. If it is solely related to GAC advice, then I don't get the claim above that the GAC should not be excluded -- that's the whole point of the "carve out".
I hope these remarks are useful. Please see also the remarks that I sent in collaboration with my colleagues on the IAB.
Best regards,
A
On Wed, Apr 06, 2016 at 06:30:14PM -0400, Bernard Turcotte wrote:
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ 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
Sent from my LG G4 Kindly excuse brevity and typos On 7 Apr 2016 14:48, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
Q6
The proposal for the community just to endorse whatever the board decides here strikes me as potentially risky. Supposed the community replaces a recalled board member with a new one that is less accommodating of a prevailing majority of the Board. The Board would be able to remove that new director with a 75% majority. If the EC does not have the ability to reject the Board's decision to remove, then there could be a procedural deadlock that could only be ameliorated by a complete replacement of the Board. That seems undesirable.
SO: The way I understand it is that the EC powers is applicable on board action or inaction hence is not restricted in the manner you've described above. I think we all should agree first that board should indeed be able to remove their colleague if they do wish and if the requirements meet. The question then is whether the community can challenge that action of board and based on my understanding I believe the SO/AC could just re-appoint their removed member OR in the case of a nomcom appointee, the community could initiate a board spill process unless board re-admit the board member(s) removed. My understanding of question 6 response is that it attempts to ensure board is indeed(and rightly) able to remove their members without the need for a formal community approval process. However the EC can still challenge that using one of its powers which is the designator power(power to appoint and remove one or all the directors). I am not sure there is any deadlock that such act will pose. Nevertheless, I am open to be convinced otherwise.
Q17
I believe the requested addition is overspecification. It will simply yield disputes about whether a given recommendation is limited in the relevant way.
Q25
The document says
Initially, “solely” was added to tie the Petition Notice to the GAC Consensus Board Resolution. For example, the ICANN Budget is an amalgamation of many different inputs. If a particular expenditure is tangentially related to GAC advice, then the GAC should not be removed from voting on that petition.
I don't understand this argument. There are two possibilities: either the expenditure is solely related to GAC advice (in which case, whether it's "tangential" is irrelevant) or it is not. If it is not, then the GAC exclusion is not entailed. If it is solely related to GAC advice, then I don't get the claim above that the GAC should not be excluded -- that's the whole point of the "carve out".
SO: I think your response is somewhat inline with that of the Co-Chairs and I also agree with the rationale. Regards
Best regards,
A
On Wed, Apr 06, 2016 at 06:30:14PM -0400, Bernard Turcotte wrote:
All,
Co-chairs and rapporteurs have reviewed and proposed answers to all questions some based on the results of the Tuesday April 5th meeting of the CCWG-Accountability.
These are attached in preparation for the Thursday April 7th meeting of the CCWG-Accountability on this topic.
The CCWG-Accountability Co-chairs Mathieu, Thomas and Leon
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Thu, Apr 07, 2016 at 04:34:14PM +0100, Seun Ojedeji wrote:
SO: The way I understand it is that the EC powers is applicable on board action or inaction hence is not restricted in the manner you've described above.
The proposed text I saw appeared to me to say that the EC would effectively be required to rubber-stamp the decision. Maybe I misunderstood it; if so, good. (The reason for the rubber stamp is that the EC is actually required to make such an affirmation.)
I think we all should agree first that board should indeed be able to remove their colleague if they do wish and if the requirements meet.
Well, yes and no. The point I'm trying to make is that this agreement could represent an attack against an approach to additional accountability short of the full replacement of the Board. Let me try to lay it out in more detail. Suppose the community were to decide that the Board was insufficiently sensitive to $issue, and were to appoint someone to the Board who was more sensitive to it. It is not too hard to imagine a case in which such a member would be regarded by the rest of the Board as too disruptive and so on. So, they remove the member. The Empowered Community permits the removal. The community (whichever way the member is appointed) re-appoints, the Board removes again, and so on. This could be short-circuited by simply making the required Empowered Community action to be a real one, so that if the EC doesn't agree with the Board's decision it can say, "No." I don't feel super strongly about this -- you could get the same result another way (like by making it plain that's what's going to happen -- I don't believe anyone likes that many trips to the dentist -- or by just removing the Board). But since the EC is required to act anyway, it seems one might as well use that occasion to allow the power to be used effectively. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
On 6, I also have a little concern with the meeting's conclusion: "The inclusion of the EC consent is required as a legal constraint due to the nature of the Designator model. To keep as close as possible to the conclusions of the CCWG Accountability Report, which did not amend the ability for the ICANN Board to remove one of its members, we recommend that the EC consent should be drafted in the Bylaws only as a matter of formality to endorse the Board decision, without any escalation or consultation process." Some points: a) It is true that there was no discussion on the Board's existing autonomy to dismiss directors; however b) it is equally true that there was no discussion on the new power of EC to provide consent, which has always been at least documented (see "designated directors cannot be removed without cause unless Sole Designator consents" from pg. 10 attached). c) what WAS discussed thoroughly, and received broad support, was the sovereignty of the SO/ACs to appoint and dismiss "their" directors, balanced (in response to the Board) with strong due diligence accorded the director. d) moreover, there is also the proposal's strong support of the EC's ability to check multiple other consequential Board actions. So I have difficulty saying that rubberstamping the board's decision to remove an SO/AC is "as close as possible to the conclusions of the CCWG Accountability Report". And therefore I think the proposal by legal counsel, to give the EC the opportunity to oppose, much closer to the Report. -----Original Message----- From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, April 7, 2016 11:58 AM To: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws On Thu, Apr 07, 2016 at 04:34:14PM +0100, Seun Ojedeji wrote:
SO: The way I understand it is that the EC powers is applicable on
board action or inaction hence is not restricted in the manner you've
described above.
The proposed text I saw appeared to me to say that the EC would effectively be required to rubber-stamp the decision. Maybe I misunderstood it; if so, good. (The reason for the rubber stamp is that the EC is actually required to make such an affirmation.)
I think we all should agree first that board should indeed be able to
remove their colleague if they do wish and if the requirements meet.
Well, yes and no. The point I'm trying to make is that this agreement could represent an attack against an approach to additional accountability short of the full replacement of the Board. Let me try to lay it out in more detail. Suppose the community were to decide that the Board was insufficiently sensitive to $issue, and were to appoint someone to the Board who was more sensitive to it. It is not too hard to imagine a case in which such a member would be regarded by the rest of the Board as too disruptive and so on. So, they remove the member. The Empowered Community permits the removal. The community (whichever way the member is appointed) re-appoints, the Board removes again, and so on. This could be short-circuited by simply making the required Empowered Community action to be a real one, so that if the EC doesn't agree with the Board's decision it can say, "No." I don't feel super strongly about this -- you could get the same result another way (like by making it plain that's what's going to happen -- I don't believe anyone likes that many trips to the dentist -- or by just removing the Board). But since the EC is required to act anyway, it seems one might as well use that occasion to allow the power to be used effectively. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> _______________________________________________ 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
Sent from my LG G4 Kindly excuse brevity and typos On 7 Apr 2016 4:58 p.m., "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
So, they remove the member. The Empowered Community permits the removal. The community (whichever way the member is appointed) re-appoints, the Board removes again, and so on.
SO: while there could be a first instance, I don't think there would "be and so on" as I think a board spill may be the next option if the board remove the same member again (although we may argue that the spill requirement may not be achieve if this is a SO/AC appointed member). One way to address the concern could be to secure any board member that was initially removed by board but re-appointed from being removed by board again (but can be removed by the appointing SO/AC alone). Something similar to the following: "A board member removed by the board and re-appointed within the same term can only be removed again with the approval of the appointing SO/AC" I assume that of nomcom does not pose such concern.
This could be short-circuited by simply making the required Empowered Community action to be a real one, so that if the EC doesn't agree with the Board's decision it can say, "No."
SO: That IMO seem to limit the board so much and could make the board incapacitated; the process to getting the community's approval/agreement is not just one click hence I have strong reservation about following that process.
I don't feel super strongly about this -- you could get the same result another way (like by making it plain that's what's going to happen -- I don't believe anyone likes that many trips to the dentist -- or by just removing the Board). But since the EC is required to act anyway, it seems one might as well use that occasion to allow the power to be used effectively.
SO: I understand it's the designator that is required to act and a section of our proposal did allow just a part of the EC to act on behalf of the entire EC (which is what we did in the case of removal of SO/AC designated board members). So I think such drafting that allows the EC(designator) to automatically approve the removal but that allows ability to challenge the action is much closer to our proposal. Regards
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I agree that this would be an abuse. And I would be happy to add a condition that the Board cannot unilaterally remove the same director a second time. In addition, the EC always has the ability to question the removal action (its automatic approval notwithstanding) and use its various powers to address that Board action. If its automatic approval would prevent that, I am happy to explicitly say that the automatic approval is given without prejudice to any future EC action. Alan At 07/04/2016 11:57 AM, Andrew Sullivan wrote:
<snip>
Suppose the community were to decide that the Board was insufficiently sensitive to $issue, and were to appoint someone to the Board who was more sensitive to it. It is not too hard to imagine a case in which such a member would be regarded by the rest of the Board as too disruptive and so on. So, they remove the member. The Empowered Community permits the removal. The community (whichever way the member is appointed) re-appoints, the Board removes again, and so on.
<snip>
-----Original Message----- Q1
On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone".
I agree. In fact, I was shocked to see in the explanation for this removal the idea that ICANN has authority over third-level domains, which as far as I know it has never even attempted to exercise. Dr. Milton L Mueller Professor, School of Public Policy Georgia Institute of Technology Internet Governance Project
Hi, I agree, as I had always thought that third level names were outside ICANN's purview. avri On 08-Apr-16 15:38, Mueller, Milton L wrote:
-----Original Message----- Q1
On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone".
I agree. In fact, I was shocked to see in the explanation for this removal the idea that ICANN has authority over third-level domains, which as far as I know it has never even attempted to exercise.
Dr. Milton L Mueller Professor, School of Public Policy Georgia Institute of Technology
Internet Governance Project
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Avri-1 Kavousd Sent from my iPhone
On 8 Apr 2016, at 21:29, avri doria <avri@apc.org> wrote:
Hi,
I agree, as I had always thought that third level names were outside ICANN's purview.
avri
On 08-Apr-16 15:38, Mueller, Milton L wrote:
-----Original Message----- Q1
On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone". I agree. In fact, I was shocked to see in the explanation for this removal the idea that ICANN has authority over third-level domains, which as far as I know it has never even attempted to exercise.
Dr. Milton L Mueller Professor, School of Public Policy Georgia Institute of Technology
Internet Governance Project
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Em 8 de abr de 2016, à(s) 15:38:000, Mueller, Milton L <milton@gatech.edu> escreveu:
-----Original Message----- Q1
On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone".
I agree. In fact, I was shocked to see in the explanation for this removal the idea that ICANN has authority over third-level domains, which as far as I know it has never even attempted to exercise.
ICANN might have authority over third-level in very specific circumstances. The one I know is a gTLD registry offering registrations on the 3rd level; even though most gTLDs offer registrations at 2nd level, if registry operator wishes to sell domains at 3rd level, ICANN has contractual authority to establish conditions (like which 2nd levels) and requirements (like proper escrow of registration data). This RSEP public comment is one of such cases: https://www.icann.org/public-comments/wed-amendment-2014-06-04-en And that probably won't be even limited to 3rd level per se... the DNS maximum label size is the limit. Rubens
Hi, On Fri, Apr 08, 2016 at 04:54:44PM -0300, Rubens Kuhl wrote:
ICANN might have authority over third-level in very specific circumstances. The one I know is a gTLD registry offering registrations on the 3rd level; even though most gTLDs offer registrations at 2nd level, if registry operator wishes to sell domains at 3rd level, ICANN has contractual authority to establish conditions (like which 2nd levels) and requirements (like proper escrow of registration data). This RSEP public comment is one of such cases: https://www.icann.org/public-comments/wed-amendment-2014-06-04-en
And that probably won't be even limited to 3rd level per se... the DNS maximum label size is the limit.
I think the above demands very careful attention to the reasoning. I believe that, if we consider the above argument, there are two possibilities: 1. ICANN can do this due to its commercial relationships flowing from its control of the root zone. 2. ICANN can do this because it really is in charge overall of names in the DNS. Let me start with the latter. I believe that, if that is true, then ICANN and anyone who uses the present IANA root servers are complicit in undermining the architecture of the DNS. The design of the DNS is decentralized authority. Indeed, the "SOA" record, which marks the apex of every zone in the DNS, stands for "start of authority". The point of this arrangement is to permit distributed management of the names in the DNS in accordance with the operational distribution of most of the Internet: your network, your rules. I do not believe for a moment that we are all -- or even that ICANN is -- involved in some conspiracy to undermine the Internet. So this explanation makes no sense, and therefore the reason for ICANN's ability to set rules about registration at parts of the domain name tree must come from something else. That something else is the first option. ICANN has the policy authority over what labels go into the root zone. ICANN does this by coming to some agreement with those who are allocated these labels. Those who are allocated such labels may choose to have them activated by having them appear in the root zone, in which case the label becomes a "top-level domain name", by getting a delegation (some NS records in the root zone) to another name server. At that name server, there is an SOA record that marks the start of authority. So, TLD operators after such a delegation are authoritative over the name space so delegated. So, then, how does ICANN get policy authority? Simple: commercial agreement. Since ICANN holds the policy over the root zone, it can in theory remove the delegation of the name in question at any time. So, it can set as conditions of its delegation of a name any policies it wants on the entity that gets that delegation. What ICANN does in fact is use ICANN-community-developed consensus policies and imposes them on these operators. The condition, then, is on the _operator_, and not on the top-level domain as such. If the operator wants to operate some lower domain as a delegation-centric domain [*], then it's not too surprising that ICANN believes its agreements cover that too. And hence ICANN's ability to impose terms on registrars: it can require TLD registries to permit retail operation only through accredited registrars, and then it can set conditions on how that accreditation is maintained. This is ICANN's market-making activity, but it is able to do it only through its control of the root zone. [* Aside: that's what we DNS geeks call TLDs and similar kinds of domains: delegation-centric, because they mostly contain delegations. Other zones have mostly resource records that point to service offerings and so on, like AAAA and A and MX records. Com is delegation-centric because it mostly exists to delegate out to others; Verisign doesn't run anvilwalrusden.com any more than ICANN runs com.] I claim that the above is the reason ICANN's Mission involving allocation and assignment of domain names is only in the root. [+] It doesn't assign things generally in the DNS. I am not a direct customer of ICANN and I do not have a direct commercial relationship with them. If they told me to register icann.anvilwalrusden.com in my zone, I would quite correctly tell them about a short pier awaiting their long walk. Indeed, avoiding such a power (which nobody, including I think ICANN, really wants ICANN to have) is precisely what the clarifications to ICANN's limited mission is all about. It would be bad for ICANN to have a Mission that gave it overall authority over names in the DNS, because that would allow it to be used as a regulator. And indeed, with the new community powers, it would be possible for the Empowered Community to force ICANN to act that way unless the explicit restriction (to the root zone) is restored to the bylaws. [+ Aside: "only in the root" is a slight exaggeration, because of int. But as we all know, int is a bit of a wart on the arrangements and it would probably be better if ICANN were out of that. The only reason it hangs around is because of the misfortune that it's already there; it isn't clear how to fix it, and we have a different political hot potato to cool just now so it'll have to wait. It's permissable anyway under the new bylaws, AFAICT, because the bylaws encourage such temporary arrangements in order to support security and stability of the DNS.] Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew, That is a carefully thought out discussion about why we should not eliminate the "in the root zone" in the general context, but the issue remains that ICANN DOES have authority to impose rules on higher levels for gTLDs. So we either need to leave the general mission statement without the restriction, or add somewhere else that with respect to gTLDs, it is within its mission to impose rules on higher level names. Alan At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
I think the above demands very careful attention to the reasoning. I believe that, if we consider the above argument, there are two possibilities:
1. ICANN can do this due to its commercial relationships flowing from its control of the root zone.
2. ICANN can do this because it really is in charge overall of names in the DNS.
Let me start with the latter. I believe that, if that is true, then ICANN and anyone who uses the present IANA root servers are complicit in undermining the architecture of the DNS. The design of the DNS is decentralized authority. Indeed, the "SOA" record, which marks the apex of every zone in the DNS, stands for "start of authority". The point of this arrangement is to permit distributed management of the names in the DNS in accordance with the operational distribution of most of the Internet: your network, your rules. I do not believe for a moment that we are all -- or even that ICANN is -- involved in some conspiracy to undermine the Internet. So this explanation makes no sense, and therefore the reason for ICANN's ability to set rules about registration at parts of the domain name tree must come from something else.
That something else is the first option. ICANN has the policy authority over what labels go into the root zone. ICANN does this by coming to some agreement with those who are allocated these labels. Those who are allocated such labels may choose to have them activated by having them appear in the root zone, in which case the label becomes a "top-level domain name", by getting a delegation (some NS records in the root zone) to another name server. At that name server, there is an SOA record that marks the start of authority. So, TLD operators after such a delegation are authoritative over the name space so delegated. So, then, how does ICANN get policy authority? Simple: commercial agreement.
Since ICANN holds the policy over the root zone, it can in theory remove the delegation of the name in question at any time. So, it can set as conditions of its delegation of a name any policies it wants on the entity that gets that delegation. What ICANN does in fact is use ICANN-community-developed consensus policies and imposes them on these operators. The condition, then, is on the _operator_, and not on the top-level domain as such. If the operator wants to operate some lower domain as a delegation-centric domain [*], then it's not too surprising that ICANN believes its agreements cover that too. And hence ICANN's ability to impose terms on registrars: it can require TLD registries to permit retail operation only through accredited registrars, and then it can set conditions on how that accreditation is maintained. This is ICANN's market-making activity, but it is able to do it only through its control of the root zone.
[* Aside: that's what we DNS geeks call TLDs and similar kinds of domains: delegation-centric, because they mostly contain delegations. Other zones have mostly resource records that point to service offerings and so on, like AAAA and A and MX records. Com is delegation-centric because it mostly exists to delegate out to others; Verisign doesn't run anvilwalrusden.com any more than ICANN runs com.]
I claim that the above is the reason ICANN's Mission involving allocation and assignment of domain names is only in the root. [+] It doesn't assign things generally in the DNS. I am not a direct customer of ICANN and I do not have a direct commercial relationship with them. If they told me to register icann.anvilwalrusden.com in my zone, I would quite correctly tell them about a short pier awaiting their long walk. Indeed, avoiding such a power (which nobody, including I think ICANN, really wants ICANN to have) is precisely what the clarifications to ICANN's limited mission is all about. It would be bad for ICANN to have a Mission that gave it overall authority over names in the DNS, because that would allow it to be used as a regulator. And indeed, with the new community powers, it would be possible for the Empowered Community to force ICANN to act that way unless the explicit restriction (to the root zone) is restored to the bylaws.
[+ Aside: "only in the root" is a slight exaggeration, because of int. But as we all know, int is a bit of a wart on the arrangements and it would probably be better if ICANN were out of that. The only reason it hangs around is because of the misfortune that it's already there; it isn't clear how to fix it, and we have a different political hot potato to cool just now so it'll have to wait. It's permissable anyway under the new bylaws, AFAICT, because the bylaws encourage such temporary arrangements in order to support security and stability of the DNS.]
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Fri, Apr 08, 2016 at 09:38:50PM -0400, Alan Greenberg wrote:
Andrew, That is a carefully thought out discussion about why we should not eliminate the "in the root zone" in the general context, but the issue remains that ICANN DOES have authority to impose rules on higher levels for gTLDs. So we either need to leave the general mission statement without the restriction, or add somewhere else that with respect to gTLDs, it is within its mission to impose rules on higher level names.
No, you are not taking into account the argument I made: ICANN is not imposing rules on names, but on those with whom it has a contract because of their delegation out of the root zone. The imposition of rules is not on TLDs, or other level domains, or anything of the kind. It's restrictions on what those contracted to ICANN (under its authority over the root zone) can do. The level of the zone in the DNS tree is a red herring. Best regards, A
Alan
At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
I think the above demands very careful attention to the reasoning. I believe that, if we consider the above argument, there are two possibilities:
1. ICANN can do this due to its commercial relationships flowing from its control of the root zone.
2. ICANN can do this because it really is in charge overall of names in the DNS.
Let me start with the latter. I believe that, if that is true, then ICANN and anyone who uses the present IANA root servers are complicit in undermining the architecture of the DNS. The design of the DNS is decentralized authority. Indeed, the "SOA" record, which marks the apex of every zone in the DNS, stands for "start of authority". The point of this arrangement is to permit distributed management of the names in the DNS in accordance with the operational distribution of most of the Internet: your network, your rules. I do not believe for a moment that we are all -- or even that ICANN is -- involved in some conspiracy to undermine the Internet. So this explanation makes no sense, and therefore the reason for ICANN's ability to set rules about registration at parts of the domain name tree must come from something else.
That something else is the first option. ICANN has the policy authority over what labels go into the root zone. ICANN does this by coming to some agreement with those who are allocated these labels. Those who are allocated such labels may choose to have them activated by having them appear in the root zone, in which case the label becomes a "top-level domain name", by getting a delegation (some NS records in the root zone) to another name server. At that name server, there is an SOA record that marks the start of authority. So, TLD operators after such a delegation are authoritative over the name space so delegated. So, then, how does ICANN get policy authority? Simple: commercial agreement.
Since ICANN holds the policy over the root zone, it can in theory remove the delegation of the name in question at any time. So, it can set as conditions of its delegation of a name any policies it wants on the entity that gets that delegation. What ICANN does in fact is use ICANN-community-developed consensus policies and imposes them on these operators. The condition, then, is on the _operator_, and not on the top-level domain as such. If the operator wants to operate some lower domain as a delegation-centric domain [*], then it's not too surprising that ICANN believes its agreements cover that too. And hence ICANN's ability to impose terms on registrars: it can require TLD registries to permit retail operation only through accredited registrars, and then it can set conditions on how that accreditation is maintained. This is ICANN's market-making activity, but it is able to do it only through its control of the root zone.
[* Aside: that's what we DNS geeks call TLDs and similar kinds of domains: delegation-centric, because they mostly contain delegations. Other zones have mostly resource records that point to service offerings and so on, like AAAA and A and MX records. Com is delegation-centric because it mostly exists to delegate out to others; Verisign doesn't run anvilwalrusden.com any more than ICANN runs com.]
I claim that the above is the reason ICANN's Mission involving allocation and assignment of domain names is only in the root. [+] It doesn't assign things generally in the DNS. I am not a direct customer of ICANN and I do not have a direct commercial relationship with them. If they told me to register icann.anvilwalrusden.com in my zone, I would quite correctly tell them about a short pier awaiting their long walk. Indeed, avoiding such a power (which nobody, including I think ICANN, really wants ICANN to have) is precisely what the clarifications to ICANN's limited mission is all about. It would be bad for ICANN to have a Mission that gave it overall authority over names in the DNS, because that would allow it to be used as a regulator. And indeed, with the new community powers, it would be possible for the Empowered Community to force ICANN to act that way unless the explicit restriction (to the root zone) is restored to the bylaws.
[+ Aside: "only in the root" is a slight exaggeration, because of int. But as we all know, int is a bit of a wart on the arrangements and it would probably be better if ICANN were out of that. The only reason it hangs around is because of the misfortune that it's already there; it isn't clear how to fix it, and we have a different political hot potato to cool just now so it'll have to wait. It's permissable anyway under the new bylaws, AFAICT, because the bylaws encourage such temporary arrangements in order to support security and stability of the DNS.]
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Andrew Sullivan ajs@anvilwalrusden.com
Good morning: I prefer Alan's first option which was the conclusion that I thought had been reached at the last CCWG call. i gather that there are still a few participants who consider that the mission statement should exclude any ICANN responsibility for rules on higher level names. May I say that should that have been the case at the time, I very much doubt that ICANN would have been created in its present form. Regards CW On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
Andrew, That is a carefully thought out discussion about why we should not eliminate the "in the root zone" in the general context, but the issue remains that ICANN DOES have authority to impose rules on higher levels for gTLDs. So we either need to leave the general mission statement without the restriction, or add somewhere else that with respect to gTLDs, it is within its mission to impose rules on higher level names.
Alan
At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
I think the above demands very careful attention to the reasoning. I believe that, if we consider the above argument, there are two possibilities:
1. ICANN can do this due to its commercial relationships flowing from its control of the root zone.
2. ICANN can do this because it really is in charge overall of names in the DNS.
Let me start with the latter. I believe that, if that is true, then ICANN and anyone who uses the present IANA root servers are complicit in undermining the architecture of the DNS. The design of the DNS is decentralized authority. Indeed, the "SOA" record, which marks the apex of every zone in the DNS, stands for "start of authority". The point of this arrangement is to permit distributed management of the names in the DNS in accordance with the operational distribution of most of the Internet: your network, your rules. I do not believe for a moment that we are all -- or even that ICANN is -- involved in some conspiracy to undermine the Internet. So this explanation makes no sense, and therefore the reason for ICANN's ability to set rules about registration at parts of the domain name tree must come from something else.
That something else is the first option. ICANN has the policy authority over what labels go into the root zone. ICANN does this by coming to some agreement with those who are allocated these labels. Those who are allocated such labels may choose to have them activated by having them appear in the root zone, in which case the label becomes a "top-level domain name", by getting a delegation (some NS records in the root zone) to another name server. At that name server, there is an SOA record that marks the start of authority. So, TLD operators after such a delegation are authoritative over the name space so delegated. So, then, how does ICANN get policy authority? Simple: commercial agreement.
Since ICANN holds the policy over the root zone, it can in theory remove the delegation of the name in question at any time. So, it can set as conditions of its delegation of a name any policies it wants on the entity that gets that delegation. What ICANN does in fact is use ICANN-community-developed consensus policies and imposes them on these operators. The condition, then, is on the _operator_, and not on the top-level domain as such. If the operator wants to operate some lower domain as a delegation-centric domain [*], then it's not too surprising that ICANN believes its agreements cover that too. And hence ICANN's ability to impose terms on registrars: it can require TLD registries to permit retail operation only through accredited registrars, and then it can set conditions on how that accreditation is maintained. This is ICANN's market-making activity, but it is able to do it only through its control of the root zone.
[* Aside: that's what we DNS geeks call TLDs and similar kinds of domains: delegation-centric, because they mostly contain delegations. Other zones have mostly resource records that point to service offerings and so on, like AAAA and A and MX records. Com is delegation-centric because it mostly exists to delegate out to others; Verisign doesn't run anvilwalrusden.com any more than ICANN runs com.]
I claim that the above is the reason ICANN's Mission involving allocation and assignment of domain names is only in the root. [+] It doesn't assign things generally in the DNS. I am not a direct customer of ICANN and I do not have a direct commercial relationship with them. If they told me to register icann.anvilwalrusden.com in my zone, I would quite correctly tell them about a short pier awaiting their long walk. Indeed, avoiding such a power (which nobody, including I think ICANN, really wants ICANN to have) is precisely what the clarifications to ICANN's limited mission is all about. It would be bad for ICANN to have a Mission that gave it overall authority over names in the DNS, because that would allow it to be used as a regulator. And indeed, with the new community powers, it would be possible for the Empowered Community to force ICANN to act that way unless the explicit restriction (to the root zone) is restored to the bylaws.
[+ Aside: "only in the root" is a slight exaggeration, because of int. But as we all know, int is a bit of a wart on the arrangements and it would probably be better if ICANN were out of that. The only reason it hangs around is because of the misfortune that it's already there; it isn't clear how to fix it, and we have a different political hot potato to cool just now so it'll have to wait. It's permissable anyway under the new bylaws, AFAICT, because the bylaws encourage such temporary arrangements in order to support security and stability of the DNS.]
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ 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
If the CCWG's current position stands, then there is no reason that ICANN cannot make rules at parts of the tree for which it has no responsibility. It could make a rule requiring me to add some.stupid.label.anvilwalrusden.com, and there would be no reason in principle that it didn't have that authority. But it does not. Moreover, this retreat by the CCWG is not consistent with the approved document. The bylaw text and the CCWG proposal are substantively different. A -- Andrew Sullivan Please excuse my clumbsy thums.
On Apr 9, 2016, at 13:44, Christopher Wilkinson <lists@christopherwilkinson.eu> wrote:
Good morning:
I prefer Alan's first option which was the conclusion that I thought had been reached at the last CCWG call.
i gather that there are still a few participants who consider that the mission statement should exclude any ICANN responsibility for rules on higher level names. May I say that should that have been the case at the time, I very much doubt that ICANN would have been created in its present form.
Regards
CW
On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
Andrew, That is a carefully thought out discussion about why we should not eliminate the "in the root zone" in the general context, but the issue remains that ICANN DOES have authority to impose rules on higher levels for gTLDs. So we either need to leave the general mission statement without the restriction, or add somewhere else that with respect to gTLDs, it is within its mission to impose rules on higher level names.
Alan
At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
I think the above demands very careful attention to the reasoning. I believe that, if we consider the above argument, there are two possibilities:
1. ICANN can do this due to its commercial relationships flowing from its control of the root zone.
2. ICANN can do this because it really is in charge overall of names in the DNS.
Let me start with the latter. I believe that, if that is true, then ICANN and anyone who uses the present IANA root servers are complicit in undermining the architecture of the DNS. The design of the DNS is decentralized authority. Indeed, the "SOA" record, which marks the apex of every zone in the DNS, stands for "start of authority". The point of this arrangement is to permit distributed management of the names in the DNS in accordance with the operational distribution of most of the Internet: your network, your rules. I do not believe for a moment that we are all -- or even that ICANN is -- involved in some conspiracy to undermine the Internet. So this explanation makes no sense, and therefore the reason for ICANN's ability to set rules about registration at parts of the domain name tree must come from something else.
That something else is the first option. ICANN has the policy authority over what labels go into the root zone. ICANN does this by coming to some agreement with those who are allocated these labels. Those who are allocated such labels may choose to have them activated by having them appear in the root zone, in which case the label becomes a "top-level domain name", by getting a delegation (some NS records in the root zone) to another name server. At that name server, there is an SOA record that marks the start of authority. So, TLD operators after such a delegation are authoritative over the name space so delegated. So, then, how does ICANN get policy authority? Simple: commercial agreement.
Since ICANN holds the policy over the root zone, it can in theory remove the delegation of the name in question at any time. So, it can set as conditions of its delegation of a name any policies it wants on the entity that gets that delegation. What ICANN does in fact is use ICANN-community-developed consensus policies and imposes them on these operators. The condition, then, is on the _operator_, and not on the top-level domain as such. If the operator wants to operate some lower domain as a delegation-centric domain [*], then it's not too surprising that ICANN believes its agreements cover that too. And hence ICANN's ability to impose terms on registrars: it can require TLD registries to permit retail operation only through accredited registrars, and then it can set conditions on how that accreditation is maintained. This is ICANN's market-making activity, but it is able to do it only through its control of the root zone.
[* Aside: that's what we DNS geeks call TLDs and similar kinds of domains: delegation-centric, because they mostly contain delegations. Other zones have mostly resource records that point to service offerings and so on, like AAAA and A and MX records. Com is delegation-centric because it mostly exists to delegate out to others; Verisign doesn't run anvilwalrusden.com any more than ICANN runs com.]
I claim that the above is the reason ICANN's Mission involving allocation and assignment of domain names is only in the root. [+] It doesn't assign things generally in the DNS. I am not a direct customer of ICANN and I do not have a direct commercial relationship with them. If they told me to register icann.anvilwalrusden.com in my zone, I would quite correctly tell them about a short pier awaiting their long walk. Indeed, avoiding such a power (which nobody, including I think ICANN, really wants ICANN to have) is precisely what the clarifications to ICANN's limited mission is all about. It would be bad for ICANN to have a Mission that gave it overall authority over names in the DNS, because that would allow it to be used as a regulator. And indeed, with the new community powers, it would be possible for the Empowered Community to force ICANN to act that way unless the explicit restriction (to the root zone) is restored to the bylaws.
[+ Aside: "only in the root" is a slight exaggeration, because of int. But as we all know, int is a bit of a wart on the arrangements and it would probably be better if ICANN were out of that. The only reason it hangs around is because of the misfortune that it's already there; it isn't clear how to fix it, and we have a different political hot potato to cool just now so it'll have to wait. It's permissable anyway under the new bylaws, AFAICT, because the bylaws encourage such temporary arrangements in order to support security and stability of the DNS.]
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ 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
some.stupid.label.anvilwalrusden.com
Hmmm … I suggest that it is not very helpful to try and deny common sense through a reductio ad absurdum. CW On 10 Apr 2016, at 18:34, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
If the CCWG's current position stands, then there is no reason that ICANN cannot make rules at parts of the tree for which it has no responsibility. It could make a rule requiring me to add some.stupid.label.anvilwalrusden.com, and there would be no reason in principle that it didn't have that authority. But it does not.
Moreover, this retreat by the CCWG is not consistent with the approved document. The bylaw text and the CCWG proposal are substantively different.
A
-- Andrew Sullivan Please excuse my clumbsy thums.
On Apr 9, 2016, at 13:44, Christopher Wilkinson <lists@christopherwilkinson.eu> wrote:
Good morning:
I prefer Alan's first option which was the conclusion that I thought had been reached at the last CCWG call.
i gather that there are still a few participants who consider that the mission statement should exclude any ICANN responsibility for rules on higher level names. May I say that should that have been the case at the time, I very much doubt that ICANN would have been created in its present form.
Regards
CW
On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
Andrew, That is a carefully thought out discussion about why we should not eliminate the "in the root zone" in the general context, but the issue remains that ICANN DOES have authority to impose rules on higher levels for gTLDs. So we either need to leave the general mission statement without the restriction, or add somewhere else that with respect to gTLDs, it is within its mission to impose rules on higher level names.
Alan
At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
I think the above demands very careful attention to the reasoning. I believe that, if we consider the above argument, there are two possibilities:
1. ICANN can do this due to its commercial relationships flowing from its control of the root zone.
2. ICANN can do this because it really is in charge overall of names in the DNS.
Let me start with the latter. I believe that, if that is true, then ICANN and anyone who uses the present IANA root servers are complicit in undermining the architecture of the DNS. The design of the DNS is decentralized authority. Indeed, the "SOA" record, which marks the apex of every zone in the DNS, stands for "start of authority". The point of this arrangement is to permit distributed management of the names in the DNS in accordance with the operational distribution of most of the Internet: your network, your rules. I do not believe for a moment that we are all -- or even that ICANN is -- involved in some conspiracy to undermine the Internet. So this explanation makes no sense, and therefore the reason for ICANN's ability to set rules about registration at parts of the domain name tree must come from something else.
That something else is the first option. ICANN has the policy authority over what labels go into the root zone. ICANN does this by coming to some agreement with those who are allocated these labels. Those who are allocated such labels may choose to have them activated by having them appear in the root zone, in which case the label becomes a "top-level domain name", by getting a delegation (some NS records in the root zone) to another name server. At that name server, there is an SOA record that marks the start of authority. So, TLD operators after such a delegation are authoritative over the name space so delegated. So, then, how does ICANN get policy authority? Simple: commercial agreement.
Since ICANN holds the policy over the root zone, it can in theory remove the delegation of the name in question at any time. So, it can set as conditions of its delegation of a name any policies it wants on the entity that gets that delegation. What ICANN does in fact is use ICANN-community-developed consensus policies and imposes them on these operators. The condition, then, is on the _operator_, and not on the top-level domain as such. If the operator wants to operate some lower domain as a delegation-centric domain [*], then it's not too surprising that ICANN believes its agreements cover that too. And hence ICANN's ability to impose terms on registrars: it can require TLD registries to permit retail operation only through accredited registrars, and then it can set conditions on how that accreditation is maintained. This is ICANN's market-making activity, but it is able to do it only through its control of the root zone.
[* Aside: that's what we DNS geeks call TLDs and similar kinds of domains: delegation-centric, because they mostly contain delegations. Other zones have mostly resource records that point to service offerings and so on, like AAAA and A and MX records. Com is delegation-centric because it mostly exists to delegate out to others; Verisign doesn't run anvilwalrusden.com any more than ICANN runs com.]
I claim that the above is the reason ICANN's Mission involving allocation and assignment of domain names is only in the root. [+] It doesn't assign things generally in the DNS. I am not a direct customer of ICANN and I do not have a direct commercial relationship with them. If they told me to register icann.anvilwalrusden.com in my zone, I would quite correctly tell them about a short pier awaiting their long walk. Indeed, avoiding such a power (which nobody, including I think ICANN, really wants ICANN to have) is precisely what the clarifications to ICANN's limited mission is all about. It would be bad for ICANN to have a Mission that gave it overall authority over names in the DNS, because that would allow it to be used as a regulator. And indeed, with the new community powers, it would be possible for the Empowered Community to force ICANN to act that way unless the explicit restriction (to the root zone) is restored to the bylaws.
[+ Aside: "only in the root" is a slight exaggeration, because of int. But as we all know, int is a bit of a wart on the arrangements and it would probably be better if ICANN were out of that. The only reason it hangs around is because of the misfortune that it's already there; it isn't clear how to fix it, and we have a different political hot potato to cool just now so it'll have to wait. It's permissable anyway under the new bylaws, AFAICT, because the bylaws encourage such temporary arrangements in order to support security and stability of the DNS.]
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ 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
Hi, I do not think this comes up to the level of reduction. The idea that ICANN could tell me what I should or not create at the third level of m17m.org is unreasonable. The transition is no time to create new content powers for ICANN. And the third level is most definitely a content level in m opinion. avri On 10-Apr-16 13:40, Christopher Wilkinson wrote:
some.stupid.label.anvilwalrusden.com
Hmmm … I suggest that it is not very helpful to try and deny common sense through a /reductio ad absurdum./
CW
On 10 Apr 2016, at 18:34, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
If the CCWG's current position stands, then there is no reason that ICANN cannot make rules at parts of the tree for which it has no responsibility. It could make a rule requiring me to add some.stupid.label.anvilwalrusden.com, and there would be no reason in principle that it didn't have that authority. But it does not.
Moreover, this retreat by the CCWG is not consistent with the approved document. The bylaw text and the CCWG proposal are substantively different.
A
-- Andrew Sullivan Please excuse my clumbsy thums.
On Apr 9, 2016, at 13:44, Christopher Wilkinson <lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>> wrote:
Good morning:
I prefer Alan's first option which was the conclusion that I thought had been reached at the last CCWG call.
i gather that there are still a few participants who consider that the mission statement should exclude any ICANN responsibility for rules on higher level names. May I say that should that have been the case at the time, I very much doubt that ICANN would have been created in its present form.
Regards
CW
On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca>> wrote:
Andrew, That is a carefully thought out discussion about why we should not eliminate the "in the root zone" in the general context, but the issue remains that ICANN DOES have authority to impose rules on higher levels for gTLDs. So we either need to leave the general mission statement without the restriction, or add somewhere else that with respect to gTLDs, it is within its mission to impose rules on higher level names.
Alan
At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
I think the above demands very careful attention to the reasoning. I believe that, if we consider the above argument, there are two possibilities:
1. ICANN can do this due to its commercial relationships flowing from its control of the root zone.
2. ICANN can do this because it really is in charge overall of names in the DNS.
Let me start with the latter. I believe that, if that is true, then ICANN and anyone who uses the present IANA root servers are complicit in undermining the architecture of the DNS. The design of the DNS is decentralized authority. Indeed, the "SOA" record, which marks the apex of every zone in the DNS, stands for "start of authority". The point of this arrangement is to permit distributed management of the names in the DNS in accordance with the operational distribution of most of the Internet: your network, your rules. I do not believe for a moment that we are all -- or even that ICANN is -- involved in some conspiracy to undermine the Internet. So this explanation makes no sense, and therefore the reason for ICANN's ability to set rules about registration at parts of the domain name tree must come from something else.
That something else is the first option. ICANN has the policy authority over what labels go into the root zone. ICANN does this by coming to some agreement with those who are allocated these labels. Those who are allocated such labels may choose to have them activated by having them appear in the root zone, in which case the label becomes a "top-level domain name", by getting a delegation (some NS records in the root zone) to another name server. At that name server, there is an SOA record that marks the start of authority. So, TLD operators after such a delegation are authoritative over the name space so delegated. So, then, how does ICANN get policy authority? Simple: commercial agreement.
Since ICANN holds the policy over the root zone, it can in theory remove the delegation of the name in question at any time. So, it can set as conditions of its delegation of a name any policies it wants on the entity that gets that delegation. What ICANN does in fact is use ICANN-community-developed consensus policies and imposes them on these operators. The condition, then, is on the _operator_, and not on the top-level domain as such. If the operator wants to operate some lower domain as a delegation-centric domain [*], then it's not too surprising that ICANN believes its agreements cover that too. And hence ICANN's ability to impose terms on registrars: it can require TLD registries to permit retail operation only through accredited registrars, and then it can set conditions on how that accreditation is maintained. This is ICANN's market-making activity, but it is able to do it only through its control of the root zone.
[* Aside: that's what we DNS geeks call TLDs and similar kinds of domains: delegation-centric, because they mostly contain delegations. Other zones have mostly resource records that point to service offerings and so on, like AAAA and A and MX records. Com is delegation-centric because it mostly exists to delegate out to others; Verisign doesn't run anvilwalrusden.com <http://anvilwalrusden.com> any more than ICANN runs com.]
I claim that the above is the reason ICANN's Mission involving allocation and assignment of domain names is only in the root. [+] It doesn't assign things generally in the DNS. I am not a direct customer of ICANN and I do not have a direct commercial relationship with them. If they told me to register icann.anvilwalrusden.com <http://icann.anvilwalrusden.com> in my zone, I would quite correctly tell them about a short pier awaiting their long walk. Indeed, avoiding such a power (which nobody, including I think ICANN, really wants ICANN to have) is precisely what the clarifications to ICANN's limited mission is all about. It would be bad for ICANN to have a Mission that gave it overall authority over names in the DNS, because that would allow it to be used as a regulator. And indeed, with the new community powers, it would be possible for the Empowered Community to force ICANN to act that way unless the explicit restriction (to the root zone) is restored to the bylaws.
[+ Aside: "only in the root" is a slight exaggeration, because of int. But as we all know, int is a bit of a wart on the arrangements and it would probably be better if ICANN were out of that. The only reason it hangs around is because of the misfortune that it's already there; it isn't clear how to fix it, and we have a different political hot potato to cool just now so it'll have to wait. It's permissable anyway under the new bylaws, AFAICT, because the bylaws encourage such temporary arrangements in order to support security and stability of the DNS.]
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> _______________________________________________ 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 <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
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
The third level can function (or be marketed) just like the second level. Look at <example>.uk.com or <example>.co.no, for example. I believe a number of the new gTLDs offer or intend to offer or enable others to offer registrations at the third level, in many of these cases keeping the second level label within the registry (or an affiliate). That's one of the reasons we are seeing requests for country and territory names/codes to be allowed at the second level. It would be incorrect to assume that all third level labels are owned and managed by the owner of the second level domain. A policy based on that assumption would be likewise incorrect. Greg [image: http://hilweb1/images/signature.jpg] *Gregory S. Shatan | Partner*McCARTER & ENGLISH, LLP 245 Park Avenue, 27th Floor | New York, New York 10167 T: 212-609-6873 F: 212-416-7613 gshatan @mccarter.com | www.mccarter.com BOSTON | HARTFORD | STAMFORD | NEW YORK | NEWARK EAST BRUNSWICK | PHILADELPHIA | WILMINGTON | WASHINGTON, DC On Sun, Apr 10, 2016 at 1:42 PM, avri doria <avri@acm.org> wrote:
Hi,
I do not think this comes up to the level of reduction.
The idea that ICANN could tell me what I should or not create at the third level of m17m.org is unreasonable.
The transition is no time to create new content powers for ICANN. And the third level is most definitely a content level in m opinion.
avri
On 10-Apr-16 13:40, Christopher Wilkinson wrote:
some.stupid.label.anvilwalrusden.com
Hmmm … I suggest that it is not very helpful to try and deny common sense through a /reductio ad absurdum./
CW
On 10 Apr 2016, at 18:34, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
If the CCWG's current position stands, then there is no reason that ICANN cannot make rules at parts of the tree for which it has no responsibility. It could make a rule requiring me to add some.stupid.label.anvilwalrusden.com, and there would be no reason in principle that it didn't have that authority. But it does not.
Moreover, this retreat by the CCWG is not consistent with the approved document. The bylaw text and the CCWG proposal are substantively different.
A
-- Andrew Sullivan Please excuse my clumbsy thums.
On Apr 9, 2016, at 13:44, Christopher Wilkinson <lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>> wrote:
Good morning:
I prefer Alan's first option which was the conclusion that I thought had been reached at the last CCWG call.
i gather that there are still a few participants who consider that the mission statement should exclude any ICANN responsibility for rules on higher level names. May I say that should that have been the case at the time, I very much doubt that ICANN would have been created in its present form.
Regards
CW
On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca>> wrote:
Andrew, That is a carefully thought out discussion about why we should not eliminate the "in the root zone" in the general context, but the issue remains that ICANN DOES have authority to impose rules on higher levels for gTLDs. So we either need to leave the general mission statement without the restriction, or add somewhere else that with respect to gTLDs, it is within its mission to impose rules on higher level names.
Alan
At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
I think the above demands very careful attention to the reasoning. I believe that, if we consider the above argument, there are two possibilities:
1. ICANN can do this due to its commercial relationships flowing from its control of the root zone.
2. ICANN can do this because it really is in charge overall of names in the DNS.
Let me start with the latter. I believe that, if that is true, then ICANN and anyone who uses the present IANA root servers are complicit in undermining the architecture of the DNS. The design of the DNS is decentralized authority. Indeed, the "SOA" record, which marks the apex of every zone in the DNS, stands for "start of authority". The point of this arrangement is to permit distributed management of the names in the DNS in accordance with the operational distribution of most of the Internet: your network, your rules. I do not believe for a moment that we are all -- or even that ICANN is -- involved in some conspiracy to undermine the Internet. So this explanation makes no sense, and therefore the reason for ICANN's ability to set rules about registration at parts of the domain name tree must come from something else.
That something else is the first option. ICANN has the policy authority over what labels go into the root zone. ICANN does this by coming to some agreement with those who are allocated these labels. Those who are allocated such labels may choose to have them activated by having them appear in the root zone, in which case the label becomes a "top-level domain name", by getting a delegation (some NS records in the root zone) to another name server. At that name server, there is an SOA record that marks the start of authority. So, TLD operators after such a delegation are authoritative over the name space so delegated. So, then, how does ICANN get policy authority? Simple: commercial agreement.
Since ICANN holds the policy over the root zone, it can in theory remove the delegation of the name in question at any time. So, it can set as conditions of its delegation of a name any policies it wants on the entity that gets that delegation. What ICANN does in fact is use ICANN-community-developed consensus policies and imposes them on these operators. The condition, then, is on the _operator_, and not on the top-level domain as such. If the operator wants to operate some lower domain as a delegation-centric domain [*], then it's not too surprising that ICANN believes its agreements cover that too. And hence ICANN's ability to impose terms on registrars: it can require TLD registries to permit retail operation only through accredited registrars, and then it can set conditions on how that accreditation is maintained. This is ICANN's market-making activity, but it is able to do it only through its control of the root zone.
[* Aside: that's what we DNS geeks call TLDs and similar kinds of domains: delegation-centric, because they mostly contain delegations. Other zones have mostly resource records that point to service offerings and so on, like AAAA and A and MX records. Com is delegation-centric because it mostly exists to delegate out to others; Verisign doesn't run anvilwalrusden.com <http://anvilwalrusden.com> any more than ICANN runs com.]
I claim that the above is the reason ICANN's Mission involving allocation and assignment of domain names is only in the root. [+] It doesn't assign things generally in the DNS. I am not a direct customer of ICANN and I do not have a direct commercial relationship with them. If they told me to register icann.anvilwalrusden.com <http://icann.anvilwalrusden.com> in my zone, I would quite correctly tell them about a short pier awaiting their long walk. Indeed, avoiding such a power (which nobody, including I think ICANN, really wants ICANN to have) is precisely what the clarifications to ICANN's limited mission is all about. It would be bad for ICANN to have a Mission that gave it overall authority over names in the DNS, because that would allow it to be used as a regulator. And indeed, with the new community powers, it would be possible for the Empowered Community to force ICANN to act that way unless the explicit restriction (to the root zone) is restored to the bylaws.
[+ Aside: "only in the root" is a slight exaggeration, because of int. But as we all know, int is a bit of a wart on the arrangements and it would probably be better if ICANN were out of that. The only reason it hangs around is because of the misfortune that it's already there; it isn't clear how to fix it, and we have a different political hot potato to cool just now so it'll have to wait. It's permissable anyway under the new bylaws, AFAICT, because the bylaws encourage such temporary arrangements in order to support security and stability of the DNS.]
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> _______________________________________________ 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 <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
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Sorry to ask but is this actually a suitable discussion for CCWG Accountability? I need to focus on the actual work of this CCWG and I find other postings diverting. Date: Sun, 10 Apr 2016 14:14:50 -0400 From: gregshatanipc@gmail.com To: avri@acm.org CC: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws The third level can function (or be marketed) just like the second level. Look at <example>.uk.com or <example>.co.no, for example. I believe a number of the new gTLDs offer or intend to offer or enable others to offer registrations at the third level, in many of these cases keeping the second level label within the registry (or an affiliate). That's one of the reasons we are seeing requests for country and territory names/codes to be allowed at the second level. It would be incorrect to assume that all third level labels are owned and managed by the owner of the second level domain. A policy based on that assumption would be likewise incorrect. Greg Gregory S. Shatan | Partner McCARTER & ENGLISH, LLP 245 Park Avenue, 27th Floor | New York, New York 10167 T: 212-609-6873 F: 212-416-7613 gshatan @mccarter.com | www.mccarter.com BOSTON | HARTFORD | STAMFORD | NEW YORK | NEWARK EAST BRUNSWICK | PHILADELPHIA | WILMINGTON | WASHINGTON, DC On Sun, Apr 10, 2016 at 1:42 PM, avri doria <avri@acm.org> wrote: Hi, I do not think this comes up to the level of reduction. The idea that ICANN could tell me what I should or not create at the third level of m17m.org is unreasonable. The transition is no time to create new content powers for ICANN. And the third level is most definitely a content level in m opinion. avri On 10-Apr-16 13:40, Christopher Wilkinson wrote:
some.stupid.label.anvilwalrusden.com
Hmmm … I suggest that it is not very helpful to try and deny common
sense through a /reductio ad absurdum./
CW
On 10 Apr 2016, at 18:34, Andrew Sullivan <ajs@anvilwalrusden.com
<mailto:ajs@anvilwalrusden.com>> wrote:
If the CCWG's current position stands, then there is no reason that
ICANN cannot make rules at parts of the tree for which it has no
responsibility. It could make a rule requiring me to add
some.stupid.label.anvilwalrusden.com, and there would be no reason in
principle that it didn't have that authority. But it does not.
Moreover, this retreat by the CCWG is not consistent with the
approved document. The bylaw text and the CCWG proposal are
substantively different.
A
--
Andrew Sullivan
Please excuse my clumbsy thums.
On Apr 9, 2016, at 13:44, Christopher Wilkinson
<lists@christopherwilkinson.eu
<mailto:lists@christopherwilkinson.eu>> wrote:
Good morning:
I prefer Alan's first option which was the conclusion that I thought
had been reached at the last CCWG call.
i gather that there are still a few participants who consider that
the mission statement should exclude any ICANN responsibility for
rules on higher level names.
May I say that should that have been the case at the time, I very
much doubt that ICANN would have been created in its present form.
Regards
CW
On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca
<mailto:alan.greenberg@mcgill.ca>> wrote:
Andrew, That is a carefully thought out discussion about why we
should not eliminate the "in the root zone" in the general context,
but the issue remains that ICANN DOES have authority to impose
rules on higher levels for gTLDs. So we either need to leave the
general mission statement without the restriction, or add somewhere
else that with respect to gTLDs, it is within its mission to impose
rules on higher level names.
Alan
At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
I think the above demands very careful attention to the reasoning. I
believe that, if we consider the above argument, there are two
possibilities:
1. ICANN can do this due to its commercial relationships flowing
from its control of the root zone.
2. ICANN can do this because it really is in charge overall of
names in the DNS.
Let me start with the latter. I believe that, if that is true, then
ICANN and anyone who uses the present IANA root servers are complicit
in undermining the architecture of the DNS. The design of the DNS is
decentralized authority. Indeed, the "SOA" record, which marks the
apex of every zone in the DNS, stands for "start of authority". The
point of this arrangement is to permit distributed management of the
names in the DNS in accordance with the operational distribution of
most of the Internet: your network, your rules. I do not believe for
a moment that we are all -- or even that ICANN is -- involved in some
conspiracy to undermine the Internet. So this explanation makes no
sense, and therefore the reason for ICANN's ability to set rules about
registration at parts of the domain name tree must come from something
else.
That something else is the first option. ICANN has the policy
authority over what labels go into the root zone. ICANN does this by
coming to some agreement with those who are allocated these labels.
Those who are allocated such labels may choose to have them activated
by having them appear in the root zone, in which case the label
becomes a "top-level domain name", by getting a delegation (some NS
records in the root zone) to another name server. At that name
server, there is an SOA record that marks the start of authority. So,
TLD operators after such a delegation are authoritative over the name
space so delegated. So, then, how does ICANN get policy authority?
Simple: commercial agreement.
Since ICANN holds the policy over the root zone, it can in theory
remove the delegation of the name in question at any time. So, it can
set as conditions of its delegation of a name any policies it wants on
the entity that gets that delegation. What ICANN does in fact is use
ICANN-community-developed consensus policies and imposes them on these
operators. The condition, then, is on the _operator_, and not on the
top-level domain as such. If the operator wants to operate some lower
domain as a delegation-centric domain [*], then it's not too
surprising that ICANN believes its agreements cover that too. And
hence ICANN's ability to impose terms on registrars: it can require
TLD registries to permit retail operation only through accredited
registrars, and then it can set conditions on how that accreditation
is maintained. This is ICANN's market-making activity, but it is able
to do it only through its control of the root zone.
[* Aside: that's what we DNS geeks call TLDs and similar kinds of
domains: delegation-centric, because they mostly contain delegations.
Other zones have mostly resource records that point to service
offerings and so on, like AAAA and A and MX records. Com is
delegation-centric because it mostly exists to delegate out to others;
Verisign doesn't run anvilwalrusden.com
<http://anvilwalrusden.com> any more than ICANN runs com.]
I claim that the above is the reason ICANN's Mission involving
allocation and assignment of domain names is only in the root. [+] It
doesn't assign things generally in the DNS. I am not a direct
customer of ICANN and I do not have a direct commercial relationship
with them. If they told me to register icann.anvilwalrusden.com
<http://icann.anvilwalrusden.com> in my
zone, I would quite correctly tell them about a short pier awaiting
their long walk. Indeed, avoiding such a power (which nobody,
including I think ICANN, really wants ICANN to have) is precisely what
the clarifications to ICANN's limited mission is all about. It
would be bad for ICANN to have a Mission that gave it overall
authority over names in the DNS, because that would allow it to be
used as a regulator. And indeed, with the new community powers, it
would be possible for the Empowered Community to force ICANN to act
that way unless the explicit restriction (to the root zone) is
restored to the bylaws.
[+ Aside: "only in the root" is a slight exaggeration, because of int.
But as we all know, int is a bit of a wart on the arrangements and it
would probably be better if ICANN were out of that. The only reason
it hangs around is because of the misfortune that it's already there;
it isn't clear how to fix it, and we have a different political hot
potato to cool just now so it'll have to wait. It's permissable
anyway under the new bylaws, AFAICT, because the bylaws encourage such
temporary arrangements in order to support security and stability of
the DNS.]
Best regards,
A
--
Andrew Sullivan
ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>
_______________________________________________
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
<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
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus _______________________________________________ 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
Exactly. This aspirational goal some may have to control the content of the entire name tree is not a fit topic for this list. thank you Marilyn. avri On 10-Apr-16 15:21, Marilyn Cade wrote:
Sorry to ask but is this actually a suitable discussion for CCWG Accountability?
I need to focus on the actual work of this CCWG and I find other postings diverting.
------------------------------------------------------------------------ Date: Sun, 10 Apr 2016 14:14:50 -0400 From: gregshatanipc@gmail.com To: avri@acm.org CC: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
The third level can function (or be marketed) just like the second level. Look at <example>.uk.com <http://uk.com> or <example>.co.no <http://co.no>, for example. I believe a number of the new gTLDs offer or intend to offer or enable others to offer registrations at the third level, in many of these cases keeping the second level label within the registry (or an affiliate). That's one of the reasons we are seeing requests for country and territory names/codes to be allowed at the second level. It would be incorrect to assume that all third level labels are owned and managed by the owner of the second level domain. A policy based on that assumption would be likewise incorrect.
Greg
http://hilweb1/images/signature.jpg
*Gregory S. Shatan | Partner *McCARTER & ENGLISH, LLP
245 Park Avenue, 27th Floor | New York, New York 10167 T: 212-609-6873 F: 212-416-7613 gshatan @mccarter.com <mailto:gshatan%20@mccarter.com> | www.mccarter.com <http://www.mccarter.com/>
BOSTON | HARTFORD | STAMFORD | NEW YORK | NEWARK EAST BRUNSWICK | PHILADELPHIA | WILMINGTON | WASHINGTON, DC
On Sun, Apr 10, 2016 at 1:42 PM, avri doria <avri@acm.org <mailto:avri@acm.org>> wrote:
Hi,
I do not think this comes up to the level of reduction.
The idea that ICANN could tell me what I should or not create at the third level of m17m.org <http://m17m.org> is unreasonable.
The transition is no time to create new content powers for ICANN. And the third level is most definitely a content level in m opinion.
avri
On 10-Apr-16 13:40, Christopher Wilkinson wrote: > > some.stupid.label.anvilwalrusden.com <http://some.stupid.label.anvilwalrusden.com> > > Hmmm … I suggest that it is not very helpful to try and deny common > sense through a /reductio ad absurdum./ > > CW > > > On 10 Apr 2016, at 18:34, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> > <mailto:ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>>> wrote: > >> If the CCWG's current position stands, then there is no reason that >> ICANN cannot make rules at parts of the tree for which it has no >> responsibility. It could make a rule requiring me to add >> some.stupid.label.anvilwalrusden.com <http://some.stupid.label.anvilwalrusden.com>, and there would be no reason in >> principle that it didn't have that authority. But it does not. >> >> Moreover, this retreat by the CCWG is not consistent with the >> approved document. The bylaw text and the CCWG proposal are >> substantively different. >> >> A >> >> -- >> Andrew Sullivan >> Please excuse my clumbsy thums. >> >>> On Apr 9, 2016, at 13:44, Christopher Wilkinson >>> <lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu> >>> <mailto:lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>>> wrote: >>> >>> Good morning: >>> >>> I prefer Alan's first option which was the conclusion that I thought >>> had been reached at the last CCWG call. >>> >>> i gather that there are still a few participants who consider that >>> the mission statement should exclude any ICANN responsibility for >>> rules on higher level names. >>> May I say that should that have been the case at the time, I very >>> much doubt that ICANN would have been created in its present form. >>> >>> Regards >>> >>> CW >>> >>> >>>> On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca> >>>> <mailto:alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca>>> wrote: >>>> >>>> Andrew, That is a carefully thought out discussion about why we >>>> should not eliminate the "in the root zone" in the general context, >>>> but the issue remains that ICANN DOES have authority to impose >>>> rules on higher levels for gTLDs. So we either need to leave the >>>> general mission statement without the restriction, or add somewhere >>>> else that with respect to gTLDs, it is within its mission to impose >>>> rules on higher level names. >>>> >>>> Alan >>>> >>>> At 08/04/2016 08:41 PM, Andrew Sullivan wrote: >>>> >>>>> I think the above demands very careful attention to the reasoning. I >>>>> believe that, if we consider the above argument, there are two >>>>> possibilities: >>>>> >>>>> 1. ICANN can do this due to its commercial relationships flowing >>>>> from its control of the root zone. >>>>> >>>>> 2. ICANN can do this because it really is in charge overall of >>>>> names in the DNS. >>>>> >>>>> Let me start with the latter. I believe that, if that is true, then >>>>> ICANN and anyone who uses the present IANA root servers are complicit >>>>> in undermining the architecture of the DNS. The design of the DNS is >>>>> decentralized authority. Indeed, the "SOA" record, which marks the >>>>> apex of every zone in the DNS, stands for "start of authority". The >>>>> point of this arrangement is to permit distributed management of the >>>>> names in the DNS in accordance with the operational distribution of >>>>> most of the Internet: your network, your rules. I do not believe for >>>>> a moment that we are all -- or even that ICANN is -- involved in some >>>>> conspiracy to undermine the Internet. So this explanation makes no >>>>> sense, and therefore the reason for ICANN's ability to set rules about >>>>> registration at parts of the domain name tree must come from something >>>>> else. >>>>> >>>>> That something else is the first option. ICANN has the policy >>>>> authority over what labels go into the root zone. ICANN does this by >>>>> coming to some agreement with those who are allocated these labels. >>>>> Those who are allocated such labels may choose to have them activated >>>>> by having them appear in the root zone, in which case the label >>>>> becomes a "top-level domain name", by getting a delegation (some NS >>>>> records in the root zone) to another name server. At that name >>>>> server, there is an SOA record that marks the start of authority. So, >>>>> TLD operators after such a delegation are authoritative over the name >>>>> space so delegated. So, then, how does ICANN get policy authority? >>>>> Simple: commercial agreement. >>>>> >>>>> Since ICANN holds the policy over the root zone, it can in theory >>>>> remove the delegation of the name in question at any time. So, it can >>>>> set as conditions of its delegation of a name any policies it wants on >>>>> the entity that gets that delegation. What ICANN does in fact is use >>>>> ICANN-community-developed consensus policies and imposes them on these >>>>> operators. The condition, then, is on the _operator_, and not on the >>>>> top-level domain as such. If the operator wants to operate some lower >>>>> domain as a delegation-centric domain [*], then it's not too >>>>> surprising that ICANN believes its agreements cover that too. And >>>>> hence ICANN's ability to impose terms on registrars: it can require >>>>> TLD registries to permit retail operation only through accredited >>>>> registrars, and then it can set conditions on how that accreditation >>>>> is maintained. This is ICANN's market-making activity, but it is able >>>>> to do it only through its control of the root zone. >>>>> >>>>> [* Aside: that's what we DNS geeks call TLDs and similar kinds of >>>>> domains: delegation-centric, because they mostly contain delegations. >>>>> Other zones have mostly resource records that point to service >>>>> offerings and so on, like AAAA and A and MX records. Com is >>>>> delegation-centric because it mostly exists to delegate out to others; >>>>> Verisign doesn't run anvilwalrusden.com <http://anvilwalrusden.com> >>>>> <http://anvilwalrusden.com> any more than ICANN runs com.] >>>>> >>>>> I claim that the above is the reason ICANN's Mission involving >>>>> allocation and assignment of domain names is only in the root. [+] It >>>>> doesn't assign things generally in the DNS. I am not a direct >>>>> customer of ICANN and I do not have a direct commercial relationship >>>>> with them. If they told me to register icann.anvilwalrusden.com <http://icann.anvilwalrusden.com> >>>>> <http://icann.anvilwalrusden.com> in my >>>>> zone, I would quite correctly tell them about a short pier awaiting >>>>> their long walk. Indeed, avoiding such a power (which nobody, >>>>> including I think ICANN, really wants ICANN to have) is precisely what >>>>> the clarifications to ICANN's limited mission is all about. It >>>>> would be bad for ICANN to have a Mission that gave it overall >>>>> authority over names in the DNS, because that would allow it to be >>>>> used as a regulator. And indeed, with the new community powers, it >>>>> would be possible for the Empowered Community to force ICANN to act >>>>> that way unless the explicit restriction (to the root zone) is >>>>> restored to the bylaws. >>>>> >>>>> [+ Aside: "only in the root" is a slight exaggeration, because of int. >>>>> But as we all know, int is a bit of a wart on the arrangements and it >>>>> would probably be better if ICANN were out of that. The only reason >>>>> it hangs around is because of the misfortune that it's already there; >>>>> it isn't clear how to fix it, and we have a different political hot >>>>> potato to cool just now so it'll have to wait. It's permissable >>>>> anyway under the new bylaws, AFAICT, because the bylaws encourage such >>>>> temporary arrangements in order to support security and stability of >>>>> the DNS.] >>>>> >>>>> Best regards, >>>>> >>>>> A >>>>> >>>>> -- >>>>> Andrew Sullivan >>>>> ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> <mailto:ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> >>>>> _______________________________________________ >>>>> 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> >>>> <mailto: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
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ 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
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Hi, I don't think anyone is saying that, the point about whether "root zone" be included or removed in the mission is within scope of the CCWG and the discussions has tend towards people providing reasons why it should be included or not. However, I understand that it may be looking like a policy discussion. The discussions so far kind-of confirm for me that we could indeed remove "root zone" while things can be defined/restricted at policy level (and other fora where the discussion belongs) Regards Sent from my LG G4 Kindly excuse brevity and typos On 10 Apr 2016 20:31, "avri doria" <avri@acm.org> wrote:
Exactly.
This aspirational goal some may have to control the content of the entire name tree is not a fit topic for this list.
thank you Marilyn.
avri
On 10-Apr-16 15:21, Marilyn Cade wrote:
Sorry to ask but is this actually a suitable discussion for CCWG Accountability?
I need to focus on the actual work of this CCWG and I find other postings diverting.
------------------------------------------------------------------------ Date: Sun, 10 Apr 2016 14:14:50 -0400 From: gregshatanipc@gmail.com To: avri@acm.org CC: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
The third level can function (or be marketed) just like the second level. Look at <example>.uk.com <http://uk.com> or <example>.co.no <http://co.no>, for example. I believe a number of the new gTLDs offer or intend to offer or enable others to offer registrations at the third level, in many of these cases keeping the second level label within the registry (or an affiliate). That's one of the reasons we are seeing requests for country and territory names/codes to be allowed at the second level. It would be incorrect to assume that all third level labels are owned and managed by the owner of the second level domain. A policy based on that assumption would be likewise incorrect.
Greg
http://hilweb1/images/signature.jpg
*Gregory S. Shatan | Partner *McCARTER & ENGLISH, LLP
245 Park Avenue, 27th Floor | New York, New York 10167 T: 212-609-6873 F: 212-416-7613 gshatan @mccarter.com <mailto:gshatan%20@mccarter.com> | www.mccarter.com <http://www.mccarter.com/>
BOSTON | HARTFORD | STAMFORD | NEW YORK | NEWARK EAST BRUNSWICK | PHILADELPHIA | WILMINGTON | WASHINGTON, DC
On Sun, Apr 10, 2016 at 1:42 PM, avri doria <avri@acm.org <mailto:avri@acm.org>> wrote:
Hi,
I do not think this comes up to the level of reduction.
The idea that ICANN could tell me what I should or not create at the third level of m17m.org <http://m17m.org> is unreasonable.
The transition is no time to create new content powers for ICANN. And the third level is most definitely a content level in m opinion.
avri
On 10-Apr-16 13:40, Christopher Wilkinson wrote: > > some.stupid.label.anvilwalrusden.com <http://some.stupid.label.anvilwalrusden.com> > > Hmmm … I suggest that it is not very helpful to try and deny common > sense through a /reductio ad absurdum./ > > CW > > > On 10 Apr 2016, at 18:34, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> > <mailto:ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>>> wrote: > >> If the CCWG's current position stands, then there is no reason that >> ICANN cannot make rules at parts of the tree for which it has no >> responsibility. It could make a rule requiring me to add >> some.stupid.label.anvilwalrusden.com <http://some.stupid.label.anvilwalrusden.com>, and there would be no reason in >> principle that it didn't have that authority. But it does not. >> >> Moreover, this retreat by the CCWG is not consistent with the >> approved document. The bylaw text and the CCWG proposal are >> substantively different. >> >> A >> >> -- >> Andrew Sullivan >> Please excuse my clumbsy thums. >> >>> On Apr 9, 2016, at 13:44, Christopher Wilkinson >>> <lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu> >>> <mailto:lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>>> wrote: >>> >>> Good morning: >>> >>> I prefer Alan's first option which was the conclusion that I thought >>> had been reached at the last CCWG call. >>> >>> i gather that there are still a few participants who consider that >>> the mission statement should exclude any ICANN responsibility for >>> rules on higher level names. >>> May I say that should that have been the case at the time, I very >>> much doubt that ICANN would have been created in its present form. >>> >>> Regards >>> >>> CW >>> >>> >>>> On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca> >>>> <mailto:alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca>>> wrote: >>>> >>>> Andrew, That is a carefully thought out discussion about why we >>>> should not eliminate the "in the root zone" in the general context, >>>> but the issue remains that ICANN DOES have authority to impose >>>> rules on higher levels for gTLDs. So we either need to leave the >>>> general mission statement without the restriction, or add somewhere >>>> else that with respect to gTLDs, it is within its mission to impose >>>> rules on higher level names. >>>> >>>> Alan >>>> >>>> At 08/04/2016 08:41 PM, Andrew Sullivan wrote: >>>> >>>>> I think the above demands very careful attention to the reasoning. I >>>>> believe that, if we consider the above argument, there are two >>>>> possibilities: >>>>> >>>>> 1. ICANN can do this due to its commercial relationships flowing >>>>> from its control of the root zone. >>>>> >>>>> 2. ICANN can do this because it really is in charge overall of >>>>> names in the DNS. >>>>> >>>>> Let me start with the latter. I believe that, if that is true, then >>>>> ICANN and anyone who uses the present IANA root servers are complicit >>>>> in undermining the architecture of the DNS. The design of the DNS is >>>>> decentralized authority. Indeed, the "SOA" record, which marks the >>>>> apex of every zone in the DNS, stands for "start of authority". The >>>>> point of this arrangement is to permit distributed management of the >>>>> names in the DNS in accordance with the operational distribution of >>>>> most of the Internet: your network, your rules. I do not believe for >>>>> a moment that we are all -- or even that ICANN is -- involved in some >>>>> conspiracy to undermine the Internet. So this explanation makes no >>>>> sense, and therefore the reason for ICANN's ability to set rules about >>>>> registration at parts of the domain name tree must come from something >>>>> else. >>>>> >>>>> That something else is the first option. ICANN has the policy >>>>> authority over what labels go into the root zone. ICANN does this by >>>>> coming to some agreement with those who are allocated these labels. >>>>> Those who are allocated such labels may choose to have them activated >>>>> by having them appear in the root zone, in which case the label >>>>> becomes a "top-level domain name", by getting a delegation (some NS >>>>> records in the root zone) to another name server. At that name >>>>> server, there is an SOA record that marks the start of authority. So, >>>>> TLD operators after such a delegation are authoritative over the name >>>>> space so delegated. So, then, how does ICANN get policy authority? >>>>> Simple: commercial agreement. >>>>> >>>>> Since ICANN holds the policy over the root zone, it can in theory >>>>> remove the delegation of the name in question at any time. So, it can >>>>> set as conditions of its delegation of a name any policies it wants on >>>>> the entity that gets that delegation. What ICANN does in fact is use >>>>> ICANN-community-developed consensus policies and imposes them on these >>>>> operators. The condition, then, is on the _operator_, and not on the >>>>> top-level domain as such. If the operator wants to operate some lower >>>>> domain as a delegation-centric domain [*], then it's not too >>>>> surprising that ICANN believes its agreements cover that too. And >>>>> hence ICANN's ability to impose terms on registrars: it can require >>>>> TLD registries to permit retail operation only through accredited >>>>> registrars, and then it can set conditions on how that accreditation >>>>> is maintained. This is ICANN's market-making activity, but it is able >>>>> to do it only through its control of the root zone. >>>>> >>>>> [* Aside: that's what we DNS geeks call TLDs and similar kinds of >>>>> domains: delegation-centric, because they mostly contain delegations. >>>>> Other zones have mostly resource records that point to service >>>>> offerings and so on, like AAAA and A and MX records. Com is >>>>> delegation-centric because it mostly exists to delegate out to others; >>>>> Verisign doesn't run anvilwalrusden.com <http://anvilwalrusden.com> >>>>> <http://anvilwalrusden.com> any more than ICANN runs com.] >>>>> >>>>> I claim that the above is the reason ICANN's Mission involving >>>>> allocation and assignment of domain names is only in the root. [+] It >>>>> doesn't assign things generally in the DNS. I am not a direct >>>>> customer of ICANN and I do not have a direct commercial relationship >>>>> with them. If they told me to register icann.anvilwalrusden.com <http://icann.anvilwalrusden.com> >>>>> <http://icann.anvilwalrusden.com> in my >>>>> zone, I would quite correctly tell them about a short pier awaiting >>>>> their long walk. Indeed, avoiding such a power (which nobody, >>>>> including I think ICANN, really wants ICANN to have) is precisely what >>>>> the clarifications to ICANN's limited mission is all about. It >>>>> would be bad for ICANN to have a Mission that gave it overall >>>>> authority over names in the DNS, because that would allow it to be >>>>> used as a regulator. And indeed, with the new community powers, it >>>>> would be possible for the Empowered Community to force ICANN to act >>>>> that way unless the explicit restriction (to the root zone) is >>>>> restored to the bylaws. >>>>> >>>>> [+ Aside: "only in the root" is a slight exaggeration, because of int. >>>>> But as we all know, int is a bit of a wart on the arrangements and it >>>>> would probably be better if ICANN were out of that. The only reason >>>>> it hangs around is because of the misfortune that it's already there; >>>>> it isn't clear how to fix it, and we have a different political hot >>>>> potato to cool just now so it'll have to wait. It's permissable >>>>> anyway under the new bylaws, AFAICT, because the bylaws encourage such >>>>> temporary arrangements in order to support security and stability of >>>>> the DNS.] >>>>> >>>>> Best regards, >>>>> >>>>> A >>>>> >>>>> -- >>>>> Andrew Sullivan >>>>> ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> <mailto:ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> >>>>> _______________________________________________ >>>>> 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> >>>> <mailto: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
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ 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
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
It is not content for SOME TLDs. In those cases, registrants apply for and get third level names and ICANN and registrars get paid for names at those levels. The Bylaws must sanction this. As Andrew has pointed out, this is contractual matter and only applies to selected TLDs, but we need to ensure that the Bylaws do not prohibit it. Alan At 10/04/2016 01:42 PM, avri doria wrote:
Hi,
I do not think this comes up to the level of reduction.
The idea that ICANN could tell me what I should or not create at the third level of m17m.org is unreasonable.
The transition is no time to create new content powers for ICANN. And the third level is most definitely a content level in m opinion.
avri
On 10-Apr-16 13:40, Christopher Wilkinson wrote:
some.stupid.label.anvilwalrusden.com
Hmmm I suggest that it is not very helpful to try and deny common sense through a /reductio ad absurdum./
CW
On 10 Apr 2016, at 18:34, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
If the CCWG's current position stands, then there is no reason that ICANN cannot make rules at parts of the tree for which it has no responsibility. It could make a rule requiring me to add some.stupid.label.anvilwalrusden.com, and there would be no reason in principle that it didn't have that authority. But it does not.
Moreover, this retreat by the CCWG is not consistent with the approved document. The bylaw text and the CCWG proposal are substantively different.
A
-- Andrew Sullivan Please excuse my clumbsy thums.
On Apr 9, 2016, at 13:44, Christopher Wilkinson <lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>> wrote:
Good morning:
I prefer Alan's first option which was the conclusion that I thought had been reached at the last CCWG call.
i gather that there are still a few participants who consider that the mission statement should exclude any ICANN responsibility for rules on higher level names. May I say that should that have been the case at the time, I very much doubt that ICANN would have been created in its present form.
Regards
CW
On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca>> wrote:
Andrew, That is a carefully thought out discussion about why we should not eliminate the "in the root zone" in the general context, but the issue remains that ICANN DOES have authority to impose rules on higher levels for gTLDs. So we either need to leave the general mission statement without the restriction, or add somewhere else that with respect to gTLDs, it is within its mission to impose rules on higher level names.
Alan
At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
I think the above demands very careful attention to the reasoning. I believe that, if we consider the above argument, there are two possibilities:
1. ICANN can do this due to its commercial relationships flowing from its control of the root zone.
2. ICANN can do this because it really is in charge overall of names in the DNS.
Let me start with the latter. I believe that, if that is true, then ICANN and anyone who uses the present IANA root servers are complicit in undermining the architecture of the DNS. The design of the DNS is decentralized authority. Indeed, the "SOA" record, which marks the apex of every zone in the DNS, stands for "start of authority". The point of this arrangement is to permit distributed management of the names in the DNS in accordance with the operational distribution of most of the Internet: your network, your rules. I do not believe for a moment that we are all -- or even that ICANN is -- involved in some conspiracy to undermine the Internet. So this explanation makes no sense, and therefore the reason for ICANN's ability to set rules about registration at parts of the domain name tree must come from something else.
That something else is the first option. ICANN has the policy authority over what labels go into the root zone. ICANN does this by coming to some agreement with those who are allocated these labels. Those who are allocated such labels may choose to have them activated by having them appear in the root zone, in which case the label becomes a "top-level domain name", by getting a delegation (some NS records in the root zone) to another name server. At that name server, there is an SOA record that marks the start of authority. So, TLD operators after such a delegation are authoritative over the name space so delegated. So, then, how does ICANN get policy authority? Simple: commercial agreement.
Since ICANN holds the policy over the root zone, it can in theory remove the delegation of the name in question at any time. So, it can set as conditions of its delegation of a name any policies it wants on the entity that gets that delegation. What ICANN does in fact is use ICANN-community-developed consensus policies and imposes them on these operators. The condition, then, is on the _operator_, and not on the top-level domain as such. If the operator wants to operate some lower domain as a delegation-centric domain [*], then it's not too surprising that ICANN believes its agreements cover that too. And hence ICANN's ability to impose terms on registrars: it can require TLD registries to permit retail operation only through accredited registrars, and then it can set conditions on how that accreditation is maintained. This is ICANN's market-making activity, but it is able to do it only through its control of the root zone.
[* Aside: that's what we DNS geeks call TLDs and similar kinds of domains: delegation-centric, because they mostly contain delegations. Other zones have mostly resource records that point to service offerings and so on, like AAAA and A and MX records. Com is delegation-centric because it mostly exists to delegate out to others; Verisign doesn't run anvilwalrusden.com <http://anvilwalrusden.com> any more than ICANN runs com.]
I claim that the above is the reason ICANN's Mission involving allocation and assignment of domain names is only in the root. [+] It doesn't assign things generally in the DNS. I am not a direct customer of ICANN and I do not have a direct commercial relationship with them. If they told me to register icann.anvilwalrusden.com <http://icann.anvilwalrusden.com> in my zone, I would quite correctly tell them about a short pier awaiting their long walk. Indeed, avoiding such a power (which nobody, including I think ICANN, really wants ICANN to have) is precisely what the clarifications to ICANN's limited mission is all about. It would be bad for ICANN to have a Mission that gave it overall authority over names in the DNS, because that would allow it to be used as a regulator. And indeed, with the new community powers, it would be possible for the Empowered Community to force ICANN to act that way unless the explicit restriction (to the root zone) is restored to the bylaws.
[+ Aside: "only in the root" is a slight exaggeration, because of int. But as we all know, int is a bit of a wart on the arrangements and it would probably be better if ICANN were out of that. The only reason it hangs around is because of the misfortune that it's already there; it isn't clear how to fix it, and we have a different political hot potato to cool just now so it'll have to wait. It's permissable anyway under the new bylaws, AFAICT, because the bylaws encourage such temporary arrangements in order to support security and stability of the DNS.]
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> _______________________________________________ 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 <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
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Alan, Isn't the flip-side of this to ensure that the Bylaws allow the development of policies that govern it? Greg [image: http://hilweb1/images/signature.jpg] *Gregory S. Shatan | Partner*McCARTER & ENGLISH, LLP 245 Park Avenue, 27th Floor | New York, New York 10167 T: 212-609-6873 F: 212-416-7613 gshatan @mccarter.com | www.mccarter.com BOSTON | HARTFORD | STAMFORD | NEW YORK | NEWARK EAST BRUNSWICK | PHILADELPHIA | WILMINGTON | WASHINGTON, DC On Sun, Apr 10, 2016 at 2:58 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
It is not content for SOME TLDs. In those cases, registrants apply for and get third level names and ICANN and registrars get paid for names at those levels. The Bylaws must sanction this. As Andrew has pointed out, this is contractual matter and only applies to selected TLDs, but we need to ensure that the Bylaws do not prohibit it.
Alan
At 10/04/2016 01:42 PM, avri doria wrote:
Hi,
I do not think this comes up to the level of reduction.
The idea that ICANN could tell me what I should or not create at the third level of m17m.org is unreasonable.
The transition is no time to create new content powers for ICANN. And the third level is most definitely a content level in m opinion.
avri
On 10-Apr-16 13:40, Christopher Wilkinson wrote:
some.stupid.label.anvilwalrusden.com
Hmmm … I suggest that it is not very helpful to try and deny common sense through a /reductio ad absurdum./
CW
On 10 Apr 2016, at 18:34, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
If the CCWG's current position stands, then there is no reason that ICANN cannot make rules at parts of the tree for which it has no responsibility. It could make a rule requiring me to add some.stupid.label.anvilwalrusden.com, and there would be no reason in principle that it didn't have that authority. But it does not.
Moreover, this retreat by the CCWG is not consistent with the approved document. The bylaw text and the CCWG proposal are substantively different.
A
-- Andrew Sullivan Please excuse my clumbsy thums.
On Apr 9, 2016, at 13:44, Christopher Wilkinson <lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>> wrote:
Good morning:
I prefer Alan's first option which was the conclusion that I thought had been reached at the last CCWG call.
i gather that there are still a few participants who consider that the mission statement should exclude any ICANN responsibility for rules on higher level names. May I say that should that have been the case at the time, I very much doubt that ICANN would have been created in its present form.
Regards
CW
On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca>> wrote:
Andrew, That is a carefully thought out discussion about why we should not eliminate the "in the root zone" in the general context, but the issue remains that ICANN DOES have authority to impose rules on higher levels for gTLDs. So we either need to leave the general mission statement without the restriction, or add somewhere else that with respect to gTLDs, it is within its mission to impose rules on higher level names.
Alan
At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
> I think the above demands very careful attention to the reasoning. I > believe that, if we consider the above argument, there are two > possibilities: > > 1. ICANN can do this due to its commercial relationships flowing > from its control of the root zone. > > 2. ICANN can do this because it really is in charge overall of > names in the DNS. > > Let me start with the latter. I believe that, if that is true, then > ICANN and anyone who uses the present IANA root servers are complicit > in undermining the architecture of the DNS. The design of the DNS is > decentralized authority. Indeed, the "SOA" record, which marks the > apex of every zone in the DNS, stands for "start of authority". The > point of this arrangement is to permit distributed management of the > names in the DNS in accordance with the operational distribution of > most of the Internet: your network, your rules. I do not believe for > a moment that we are all -- or even that ICANN is -- involved in some > conspiracy to undermine the Internet. So this explanation makes no > sense, and therefore the reason for ICANN's ability to set rules about > registration at parts of the domain name tree must come from something > else. > > That something else is the first option. ICANN has the policy > authority over what labels go into the root zone. ICANN does this by > coming to some agreement with those who are allocated these labels. > Those who are allocated such labels may choose to have them activated > by having them appear in the root zone, in which case the label > becomes a "top-level domain name", by getting a delegation (some NS > records in the root zone) to another name server. At that name > server, there is an SOA record that marks the start of authority. So, > TLD operators after such a delegation are authoritative over the name > space so delegated. So, then, how does ICANN get policy authority? > Simple: commercial agreement. > > Since ICANN holds the policy over the root zone, it can in theory > remove the delegation of the name in question at any time. So, it can > set as conditions of its delegation of a name any policies it wants on > the entity that gets that delegation. What ICANN does in fact is use > ICANN-community-developed consensus policies and imposes them on these > operators. The condition, then, is on the _operator_, and not on the > top-level domain as such. If the operator wants to operate some lower > domain as a delegation-centric domain [*], then it's not too > surprising that ICANN believes its agreements cover that too. And > hence ICANN's ability to impose terms on registrars: it can require > TLD registries to permit retail operation only through accredited > registrars, and then it can set conditions on how that accreditation > is maintained. This is ICANN's market-making activity, but it is able > to do it only through its control of the root zone. > > [* Aside: that's what we DNS geeks call TLDs and similar kinds of > domains: delegation-centric, because they mostly contain delegations. > Other zones have mostly resource records that point to service > offerings and so on, like AAAA and A and MX records. Com is > delegation-centric because it mostly exists to delegate out to others; > Verisign doesn't run anvilwalrusden.com > <http://anvilwalrusden.com> any more than ICANN runs com.] > > I claim that the above is the reason ICANN's Mission involving > allocation and assignment of domain names is only in the root. [+] It > doesn't assign things generally in the DNS. I am not a direct > customer of ICANN and I do not have a direct commercial relationship > with them. If they told me to register icann.anvilwalrusden.com > <http://icann.anvilwalrusden.com> in my > zone, I would quite correctly tell them about a short pier awaiting > their long walk. Indeed, avoiding such a power (which nobody, > including I think ICANN, really wants ICANN to have) is precisely what > the clarifications to ICANN's limited mission is all about. It > would be bad for ICANN to have a Mission that gave it overall > authority over names in the DNS, because that would allow it to be > used as a regulator. And indeed, with the new community powers, it > would be possible for the Empowered Community to force ICANN to act > that way unless the explicit restriction (to the root zone) is > restored to the bylaws. > > [+ Aside: "only in the root" is a slight exaggeration, because of int. > But as we all know, int is a bit of a wart on the arrangements and it > would probably be better if ICANN were out of that. The only reason > it hangs around is because of the misfortune that it's already there; > it isn't clear how to fix it, and we have a different political hot > potato to cool just now so it'll have to wait. It's permissable > anyway under the new bylaws, AFAICT, because the bylaws encourage such > temporary arrangements in order to support security and stability of > the DNS.] > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> > _______________________________________________ > 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 <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
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ 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 rules that created the original TLDs were supposed to apply recursively to all nodes in the tree. But that principle was abandoned at least two decades ago. On 04/10/2016 05:34 PM, Andrew Sullivan wrote:
If the CCWG's current position stands, then there is no reason that ICANN cannot make rules at parts of the tree for which it has no responsibility. It could make a rule requiring me to add some.stupid.label.anvilwalrusden.com, and there would be no reason in principle that it didn't have that authority. But it does not.
Moreover, this retreat by the CCWG is not consistent with the approved document. The bylaw text and the CCWG proposal are substantively different.
A
Sent from my LG G4 Kindly excuse brevity and typos On 10 Apr 2016 17:35, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
If the CCWG's current position stands, then there is no reason that ICANN
cannot make rules at parts of the tree for which it has no responsibility. It could make a rule requiring me to add some.stupid.label.anvilwalrusden.com, and there would be no reason in principle that it didn't have that authority. But it does not.
SO: If this were possible (in practice) then I will indeed see no problem with adding the restriction. However, there is a chance that adding the "in the root" could indeed validate claims that ICANN cannot make such rules as above. A layman thought is a scenario where there is a rule by ICANN that requires gTLDs to consider icann.tld to be forbidden, so if removing the "in the root" can permit that legitimately then I would be fine. Or a scenario where ICANN bans a Registrar/registry and then decide to transfer the domains to another Registrar/registry which will sure involve engaging lower layer names.
Moreover, this retreat by the CCWG is not consistent with the approved document. The bylaw text and the CCWG proposal are substantively different.
SO: I agree and this bothers me as well. If there is other way to do this without going out of the scope then it will be good otherwise, I think this change should be clearly marked during the PC with our rationale indicated. Regards
A
-- Andrew Sullivan Please excuse my clumbsy thums.
On Apr 9, 2016, at 13:44, Christopher Wilkinson < lists@christopherwilkinson.eu> wrote:
Good morning:
I prefer Alan's first option which was the conclusion that I thought had been reached at the last CCWG call.
i gather that there are still a few participants who consider that the mission statement should exclude any ICANN responsibility for rules on higher level names. May I say that should that have been the case at the time, I very much doubt that ICANN would have been created in its present form.
Regards
CW
On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
Andrew, That is a carefully thought out discussion about why we should not eliminate the "in the root zone" in the general context, but the issue remains that ICANN DOES have authority to impose rules on higher levels for gTLDs. So we either need to leave the general mission statement without the restriction, or add somewhere else that with respect to gTLDs, it is within its mission to impose rules on higher level names.
Alan
At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
I think the above demands very careful attention to the reasoning. I believe that, if we consider the above argument, there are two possibilities:
1. ICANN can do this due to its commercial relationships flowing from its control of the root zone.
2. ICANN can do this because it really is in charge overall of names in the DNS.
Let me start with the latter. I believe that, if that is true, then ICANN and anyone who uses the present IANA root servers are complicit in undermining the architecture of the DNS. The design of the DNS is decentralized authority. Indeed, the "SOA" record, which marks the apex of every zone in the DNS, stands for "start of authority". The point of this arrangement is to permit distributed management of the names in the DNS in accordance with the operational distribution of most of the Internet: your network, your rules. I do not believe for a moment that we are all -- or even that ICANN is -- involved in some conspiracy to undermine the Internet. So this explanation makes no sense, and therefore the reason for ICANN's ability to set rules about registration at parts of the domain name tree must come from something else.
That something else is the first option. ICANN has the policy authority over what labels go into the root zone. ICANN does this by coming to some agreement with those who are allocated these labels. Those who are allocated such labels may choose to have them activated by having them appear in the root zone, in which case the label becomes a "top-level domain name", by getting a delegation (some NS records in the root zone) to another name server. At that name server, there is an SOA record that marks the start of authority. So, TLD operators after such a delegation are authoritative over the name space so delegated. So, then, how does ICANN get policy authority? Simple: commercial agreement.
Since ICANN holds the policy over the root zone, it can in theory remove the delegation of the name in question at any time. So, it can set as conditions of its delegation of a name any policies it wants on the entity that gets that delegation. What ICANN does in fact is use ICANN-community-developed consensus policies and imposes them on these operators. The condition, then, is on the _operator_, and not on the top-level domain as such. If the operator wants to operate some lower domain as a delegation-centric domain [*], then it's not too surprising that ICANN believes its agreements cover that too. And hence ICANN's ability to impose terms on registrars: it can require TLD registries to permit retail operation only through accredited registrars, and then it can set conditions on how that accreditation is maintained. This is ICANN's market-making activity, but it is able to do it only through its control of the root zone.
[* Aside: that's what we DNS geeks call TLDs and similar kinds of domains: delegation-centric, because they mostly contain delegations. Other zones have mostly resource records that point to service offerings and so on, like AAAA and A and MX records. Com is delegation-centric because it mostly exists to delegate out to others; Verisign doesn't run anvilwalrusden.com any more than ICANN runs com.]
I claim that the above is the reason ICANN's Mission involving allocation and assignment of domain names is only in the root. [+] It doesn't assign things generally in the DNS. I am not a direct customer of ICANN and I do not have a direct commercial relationship with them. If they told me to register icann.anvilwalrusden.com in my zone, I would quite correctly tell them about a short pier awaiting their long walk. Indeed, avoiding such a power (which nobody, including I think ICANN, really wants ICANN to have) is precisely what the clarifications to ICANN's limited mission is all about. It would be bad for ICANN to have a Mission that gave it overall authority over names in the DNS, because that would allow it to be used as a regulator. And indeed, with the new community powers, it would be possible for the Empowered Community to force ICANN to act that way unless the explicit restriction (to the root zone) is restored to the bylaws.
[+ Aside: "only in the root" is a slight exaggeration, because of int. But as we all know, int is a bit of a wart on the arrangements and it would probably be better if ICANN were out of that. The only reason it hangs around is because of the misfortune that it's already there; it isn't clear how to fix it, and we have a different political hot potato to cool just now so it'll have to wait. It's permissable anyway under the new bylaws, AFAICT, because the bylaws encourage such temporary arrangements in order to support security and stability of the DNS.]
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ 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
On Sun, Apr 10, 2016 at 06:40:46PM +0100, Seun Ojedeji wrote:
above. A layman thought is a scenario where there is a rule by ICANN that requires gTLDs to consider icann.tld to be forbidden, so if removing the "in the root" can permit that legitimately then I would be fine.
SO: I agree and this bothers me as well. If there is other way to do this without going out of the scope then it will be good otherwise, I think this change should be clearly marked during the PC with our rationale indicated.
Apparently I have still failed to communicate this clearly enough: there is a way to do that. It stems from ICANN's control of delegations from the root zone. Every delegation in the root involves delegation to another party. Those parties are TLD registries. When ICANN delegates to a registry, it can attach conditions to that delegation. And in fact, that's what it does today: when an entity (organization, corporation, individual, whatever) gets a delegation from the root, it agrees to all sorts of consensus policies. The key thing here is that it is the _entity_ that makes the agreement. That agreement often imposes terms on the operation of the delegated name space. These are terms that control the actions of the entity -- it's not about "levels" in the DNS. So, ICANN can also control the actions of the entity lower in the tree, or even elsewhere in the tree (this sort of term, for instance, is what made it possible for ICANN to require registries not to be registrars -- it's not regulation, but commercial agreement. I won't agree to X unless you agree to Y). It all stems from ICANN's policy control over the root zone. If there is language needed to make it clear that such contractual terms required for deletation are ok (and I do not believe there is such a need, but let's suppose it), then the language must be about that. It must not weaken the claim that ICANN's proper DNS mission is with respect to the root zone and not others. This sort of term allows for ICANN's ability to impose conditions on contracted parties anywhere in the DNS name space at all, without specifying what ICANN can do at this or that "level" of the DNS. In DNS terms, the "levels" of the DNS are a figment of the imagination. There's no technical difference between name deletation from really.dumb.long.name.anvilwalrusden.com and com itself. There's a _legal_ difference, though, and that's the parties to the agreement. I registered anvilwalrusden.com with Verisign through a reseller that resells Tucows services. I have an agreement with the reseller. The reseller has an agreement with Tucows. Tucows has an agreement with ICANN and also with Verisign, and Verisign has an agreement with ICANN too. I don't have an agreement with ICANN, so ICANN can't impose contractual terms on me except indirectly (via a long chain). I hope this makes clear why ICANN doesn't need to have control over assignment or allocation of names in the DNS generally in order to impose limits on the freedom of TLD registries even outside the name directly deleted. It only needs to work on the root.[1] A [1] Again, int is a special case, and I hope we can treat it as the exception it is. I can provide a more complicated account if need be. -- Andrew Sullivan ajs@anvilwalrusden.com
-----Original Message----- Apparently I have still failed to communicate this clearly enough: there is a way to do that. It stems from ICANN's control of delegations from the root zone.
Every delegation in the root involves delegation to another party. Those parties are TLD registries.
When ICANN delegates to a registry, it can attach conditions to that delegation. And in fact, that's what it does today: when an entity (organization, corporation, individual, whatever) gets a delegation from the root, it agrees to all sorts of consensus policies. The key thing here is that it is the _entity_ that makes the agreement. That agreement often imposes terms on the operation of the delegated name space.
This is correct. So I agree with Andrew, Avri and others that we need to keep the "in the root zone" in there. I would have to add, however, that even the contractual requirements it imposes on registries are limited by its mission, which is to coordinate the global DNS name space. ICANN could not, I hope you agree, put into a registry contract that the registry operator must steal Andrew Sullivan's fedora whenever he is seen wearing it. Just to use a random example. Insofar as ICANN can touch domain names beyond the TLD it does so contractually via its delegation of the top level domains in the root zone. It does NOT have any free-floating authority to issue commands about what happens elsewhere in the DNS.
These are terms that control the actions of the entity -- it's not about "levels" in the DNS. So, ICANN can also control the actions of the entity lower in the tree, or even elsewhere in the tree (this sort of term, for instance, is what made it possible for ICANN to require registries not to be registrars -- it's not regulation, but commercial agreement. I won't agree to X unless you agree to Y). It all stems from ICANN's policy control over the root zone. If there is language needed to make it clear that such contractual terms required for deletation are ok (and I do not believe there is such a need, but let's suppose it), then the language must be about that. It must not weaken the claim that ICANN's proper DNS mission is with respect to the root zone and not others.
This sort of term allows for ICANN's ability to impose conditions on contracted parties anywhere in the DNS name space at all, without specifying what ICANN can do at this or that "level" of the DNS. In DNS terms, the "levels" of the DNS are a figment of the imagination. There's no technical difference between name deletation from really.dumb.long.name.anvilwalrusden.com and com itself. There's a _legal_ difference, though, and that's the parties to the agreement. I registered anvilwalrusden.com with Verisign through a reseller that resells Tucows services. I have an agreement with the reseller. The reseller has an agreement with Tucows. Tucows has an agreement with ICANN and also with Verisign, and Verisign has an agreement with ICANN too. I don't have an agreement with ICANN, so ICANN can't impose contractual terms on me except indirectly (via a long chain).
I hope this makes clear why ICANN doesn't need to have control over assignment or allocation of names in the DNS generally in order to impose limits on the freedom of TLD registries even outside the name directly deleted. It only needs to work on the root.[1]
A
[1] Again, int is a special case, and I hope we can treat it as the exception it is. I can provide a more complicated account if need be.
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross- Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hi, On Mon, Apr 11, 2016 at 02:45:21AM +0000, Mueller, Milton L wrote:
I would have to add, however, that even the contractual requirements it imposes on registries are limited by its mission, which is to coordinate the global DNS name space. ICANN could not, I hope you agree, put into a registry contract that the registry operator must steal Andrew Sullivan's fedora whenever he is seen wearing it. Just to use a random example.
I agree with this, but I'd go a little further. Part of the point of restricting this to the root zone and thereby to ICANN and those who have direct contractual relationships with ICANN is to ensure that the contractual relationships are likely to be fit to that purpose. For instance, suppose that the RAA were under renegotiation and someone wanted to add a clause to the effect, "No delegations are allowed below delegations made from names delegated to any registry." I don't have a hard time imagining such a rule proposal, because it'd probably be intended to prevent more so-called "public suffixes" lower in the DNS tree. Yet under the same policy, it would not be possible for it.example.com and jp.example.com and us.example.com to be different delegations (in the DNS sense of the word) to different operating departments of the example.com corporation. I think people would be justifiably outraged, and might even have legal recourse, because this would really be an extra-contractual claim that ICANN was making (i.e. it would be a way of ICANN directly affecting the interests of parties with whom it has no direct agreement). It would certainly be contrary to the limited Mission. The current bylaw language quite clearly says not only that ICANN can make such a rule, but that making rules of this sort is part of ICANN's mission. By restricting the policy making throughout the tree to the contractual relationships ICANN actually has, we stop making this about where in the DNS the name appears and turn it into a normal contractual obligation. This gets away from the notion of ICANN-as-regulator. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Agree 100%, this really is a mission-critical issue, to coin a phrase. This is not a quibble over phrasing.
-----Original Message----- The current bylaw language quite clearly says not only that ICANN can make such a rule, but that making rules of this sort is part of ICANN's mission. By restricting the policy making throughout the tree to the contractual relationships ICANN actually has, we stop making this about where in the DNS the name appears and turn it into a normal contractual obligation. This gets away from the notion of ICANN-as-regulator.
I agree with Andrew and Milton et al. Jordan On 11 April 2016 at 15:17, Mueller, Milton L <milton@gatech.edu> wrote:
Agree 100%, this really is a mission-critical issue, to coin a phrase. This is not a quibble over phrasing.
-----Original Message----- The current bylaw language quite clearly says not only that ICANN can make such a rule, but that making rules of this sort is part of ICANN's mission. By restricting the policy making throughout the tree to the contractual relationships ICANN actually has, we stop making this about where in the DNS the name appears and turn it into a normal contractual obligation. This gets away from the notion of ICANN-as-regulator.
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Jordan Carter Chief Executive *InternetNZ * +64-4-495-2118 (office) | +64-21-442-649 (mob) | Skype: jordancarter jordan@internetnz.net.nz | www.internetnz.nz *A better world through a better Internet*
Agreed. -Jg From: <accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>> on behalf of Jordan Carter <jordan@internetnz.net.nz<mailto:jordan@internetnz.net.nz>> Date: Monday 11 April 2016 at 4:47 a.m. To: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Cc: "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] ICANN doesn't "allocate" or "assign" beyond the root (was Re: CCWG - Proposed Responses to questions on Draft Bylaws) I agree with Andrew and Milton et al. Jordan On 11 April 2016 at 15:17, Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>> wrote: Agree 100%, this really is a mission-critical issue, to coin a phrase. This is not a quibble over phrasing.
-----Original Message----- The current bylaw language quite clearly says not only that ICANN can make such a rule, but that making rules of this sort is part of ICANN's mission. By restricting the policy making throughout the tree to the contractual relationships ICANN actually has, we stop making this about where in the DNS the name appears and turn it into a normal contractual obligation. This gets away from the notion of ICANN-as-regulator.
_______________________________________________ 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 -- Jordan Carter Chief Executive InternetNZ +64-4-495-2118 (office) | +64-21-442-649 (mob) | Skype: jordancarter jordan@internetnz.net.nz<mailto:jordan@internetnz.net.nz> | www.internetnz.nz<http://www.internetnz.nz> A better world through a better Internet
Hi Andrew, Thanks for providing convincing explanation to confirm there is indeed a way to approach this (based on ICANN policy authority on the root). That said, I like to quote a specific part of your message below which I think may be quite important. "...If there is language needed to make it clear that such contractual terms required for deletation are ok (and I do not believe there is such a need, but let's suppose it), then the language must be about that. It must not weaken the claim that ICANN's proper DNS mission is with respect to the root zone and not others...." Considering that staff has implementation experience on this, it may be good hear their thought on the first part of your comment above. Hopefully we will not be taking the question to legal (well maybe we could ask ICANN staff legal since they are expected to have some implementation experience as well). Regards Sent from my LG G4 Kindly excuse brevity and typos On 11 Apr 2016 03:28, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
On Sun, Apr 10, 2016 at 06:40:46PM +0100, Seun Ojedeji wrote:
above. A layman thought is a scenario where there is a rule by ICANN that requires gTLDs to consider icann.tld to be forbidden, so if removing the "in the root" can permit that legitimately then I would be fine.
SO: I agree and this bothers me as well. If there is other way to do this without going out of the scope then it will be good otherwise, I think this change should be clearly marked during the PC with our rationale indicated.
Apparently I have still failed to communicate this clearly enough: there is a way to do that. It stems from ICANN's control of delegations from the root zone.
Every delegation in the root involves delegation to another party. Those parties are TLD registries.
When ICANN delegates to a registry, it can attach conditions to that delegation. And in fact, that's what it does today: when an entity (organization, corporation, individual, whatever) gets a delegation from the root, it agrees to all sorts of consensus policies. The key thing here is that it is the _entity_ that makes the agreement. That agreement often imposes terms on the operation of the delegated name space.
These are terms that control the actions of the entity -- it's not about "levels" in the DNS. So, ICANN can also control the actions of the entity lower in the tree, or even elsewhere in the tree (this sort of term, for instance, is what made it possible for ICANN to require registries not to be registrars -- it's not regulation, but commercial agreement. I won't agree to X unless you agree to Y). It all stems from ICANN's policy control over the root zone. If there is language needed to make it clear that such contractual terms required for deletation are ok (and I do not believe there is such a need, but let's suppose it), then the language must be about that. It must not weaken the claim that ICANN's proper DNS mission is with respect to the root zone and not others.
This sort of term allows for ICANN's ability to impose conditions on contracted parties anywhere in the DNS name space at all, without specifying what ICANN can do at this or that "level" of the DNS. In DNS terms, the "levels" of the DNS are a figment of the imagination. There's no technical difference between name deletation from really.dumb.long.name.anvilwalrusden.com and com itself. There's a _legal_ difference, though, and that's the parties to the agreement. I registered anvilwalrusden.com with Verisign through a reseller that resells Tucows services. I have an agreement with the reseller. The reseller has an agreement with Tucows. Tucows has an agreement with ICANN and also with Verisign, and Verisign has an agreement with ICANN too. I don't have an agreement with ICANN, so ICANN can't impose contractual terms on me except indirectly (via a long chain).
I hope this makes clear why ICANN doesn't need to have control over assignment or allocation of names in the DNS generally in order to impose limits on the freedom of TLD registries even outside the name directly deleted. It only needs to work on the root.[1]
A
[1] Again, int is a special case, and I hope we can treat it as the exception it is. I can provide a more complicated account if need be.
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Ruben +1 Kavousd Sent from my iPhone
On 8 Apr 2016, at 21:54, Rubens Kuhl <rubensk@nic.br> wrote:
Em 8 de abr de 2016, à(s) 15:38:000, Mueller, Milton L <milton@gatech.edu> escreveu:
-----Original Message----- Q1
On the Mission, q1, I think it is extremely unfortunate to agree to remove the restriction of "in the root zone".
I agree. In fact, I was shocked to see in the explanation for this removal the idea that ICANN has authority over third-level domains, which as far as I know it has never even attempted to exercise.
ICANN might have authority over third-level in very specific circumstances. The one I know is a gTLD registry offering registrations on the 3rd level; even though most gTLDs offer registrations at 2nd level, if registry operator wishes to sell domains at 3rd level, ICANN has contractual authority to establish conditions (like which 2nd levels) and requirements (like proper escrow of registration data). This RSEP public comment is one of such cases: https://www.icann.org/public-comments/wed-amendment-2014-06-04-en
And that probably won't be even limited to 3rd level per se... the DNS maximum label size is the limit.
Rubens
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
participants (21)
-
Alan Greenberg -
Andrew Sullivan -
avri doria -
avri doria -
Bernard Turcotte -
Chartier, Mike S -
Christopher Wilkinson -
Greg Shatan -
James Gannon -
Jordan Carter -
Jorge.Cancio@bakom.admin.ch -
Kavouss Arasteh -
Marilyn Cade -
Mark Carvell -
Mathieu Weill -
Mueller, Milton L -
Nigel Roberts -
Rubens Kuhl -
Schaefer, Brett -
Seun Ojedeji -
Thomas Rickert