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

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

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>

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

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

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

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

-----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

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

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

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

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

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

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

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

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

-----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

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.

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

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