Dear Colleagues, I attach a revised draft of the principles document based on our calls on 3 & 5 March. I believe we have a text that is pretty much in its final form, with only one outstanding issue. Looking at the remaining highlighted changes: 5.ii & iii: These are mainly editorial and have been discussed without opposition on recent calls. 5.iv footnote: We had comments about the meaning of consensus in the footnote. I do not think that defining consensus is in the remit of this document, but is part of the considerations of any entity that we establish. Hence I have added, "Conditions for consensus will need to be agreed appropriate for the group" to make this clear. 5.vi: As I said when I flagged this paragraph as of concern, I am inherently uneasy about a principle that is essentially optional and where it might need to be re-written because of subsequent choices that we make. Either it is a principle or it isn't. I believe that we need to understand the implications of what we are trying to say, so I am taking editor's right to propose a new formulation that should be independent of subsequent decisions. 6.ii: Was agreed as not being a principle last week. 7.i: Editing agreed last week. 7.ii: We took this off-line. There has been some progress in discussions with Paul and Elise. I have made a drafting proposal to both for wording that tries to take into account the concerns they have expressed. However, this paragraph needs to be held in abeyance until we have heard the views of both. 8.ii: In discussion with Erick, we have identified a compromise that moves away from saying anything about the policy authority and who it might or might not be. The proposed wording ("In particular, the IANA functions operator should not impose any additional requirements on the registry unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.") turns this around to prevent the IANA functions operator making unilateral decisions that impact the ccTLD except in (rare) cases of global security, stability and resilience. Given the delicate balance behind this text, I hope that others will find this formulation acceptable and I thank Erick for his support in finding this compromise. 9.i: A minor point here that was discussed last week. The wording is not necessary to the text, but does make it clearer that i. is about separability now and iii. says we would need to include separability for all future IANA functions operators. 10: A reasonable edit proposed by Mary last week: no objections have been raised. Hence I would hold 5.ii-iv, 6.ii, 7.i, 9.i and 10 to be agreed text if there are no objections. 5.iv: I suggest we use the new wording unless there is significant opposition. 7.ii: This has to stay in abeyance subject to agreement by Elise (in discussion with the GAC) and by Paul Kane. 8.ii: Again I suggest we use the proposed wording unless there is significant opposition. I look forward to comments on this approach, and please do flag early any difficulties you might have with any of the proposals. Best Martin
Martin I am fine with all of it except 7 ii. The troublesome part is "For ccTLDs, respect national sovereignty." I don't think many people on this group fully understand the legal and operational consequences of invoking national sovereignty here. Moreover I don't think you need language that causes so much potential trouble. It is sufficient to say, "Policy decisions for ccTLDs are usually made locally through nationally agreed processes in accordance with national laws and in compliance with IETF technical standards. Post transition of the IANA function, nothing will be done by ICANN/IANA to impact the stable operation of ccTLD Registries and gTLD Registries." You might want to add a statement that IANA functions should never be exploited for political purposes; i.e., whatever state has IANA in its jurisdiction must not exploit that to attack another state. But "respect national sovereignty" is at once too vague and too sweeping. Some would read it as requiring conformity to sovereign demands in every case, no matter what, others could read it to mean that the preferences of the sovereign will be taken into account but there is no real commitment to conform to them. I think this opens a can of worms that we don't want to open. From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Martin Boyle Sent: Monday, March 9, 2015 1:35 PM To: cwg-stewardship@icann.org Subject: [CWG-Stewardship] Principles: revised draft 9 March Dear Colleagues, I attach a revised draft of the principles document based on our calls on 3 & 5 March. I believe we have a text that is pretty much in its final form, with only one outstanding issue. Looking at the remaining highlighted changes: 5.ii & iii: These are mainly editorial and have been discussed without opposition on recent calls. 5.iv footnote: We had comments about the meaning of consensus in the footnote. I do not think that defining consensus is in the remit of this document, but is part of the considerations of any entity that we establish. Hence I have added, "Conditions for consensus will need to be agreed appropriate for the group" to make this clear. 5.vi: As I said when I flagged this paragraph as of concern, I am inherently uneasy about a principle that is essentially optional and where it might need to be re-written because of subsequent choices that we make. Either it is a principle or it isn't. I believe that we need to understand the implications of what we are trying to say, so I am taking editor's right to propose a new formulation that should be independent of subsequent decisions. 6.ii: Was agreed as not being a principle last week. 7.i: Editing agreed last week. 7.ii: We took this off-line. There has been some progress in discussions with Paul and Elise. I have made a drafting proposal to both for wording that tries to take into account the concerns they have expressed. However, this paragraph needs to be held in abeyance until we have heard the views of both. 8.ii: In discussion with Erick, we have identified a compromise that moves away from saying anything about the policy authority and who it might or might not be. The proposed wording ("In particular, the IANA functions operator should not impose any additional requirements on the registry unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.") turns this around to prevent the IANA functions operator making unilateral decisions that impact the ccTLD except in (rare) cases of global security, stability and resilience. Given the delicate balance behind this text, I hope that others will find this formulation acceptable and I thank Erick for his support in finding this compromise. 9.i: A minor point here that was discussed last week. The wording is not necessary to the text, but does make it clearer that i. is about separability now and iii. says we would need to include separability for all future IANA functions operators. 10: A reasonable edit proposed by Mary last week: no objections have been raised. Hence I would hold 5.ii-iv, 6.ii, 7.i, 9.i and 10 to be agreed text if there are no objections. 5.iv: I suggest we use the new wording unless there is significant opposition. 7.ii: This has to stay in abeyance subject to agreement by Elise (in discussion with the GAC) and by Paul Kane. 8.ii: Again I suggest we use the proposed wording unless there is significant opposition. I look forward to comments on this approach, and please do flag early any difficulties you might have with any of the proposals. Best Martin
Milton, I'll leave to Elise to say what the GAC means by national sovereignty and why there needs to be a reference here! Yes, it is a difficult topic and partly because people do interpret national sovereignty in different ways. But, as you know, for the GAC, reference to national sovereignty is crucial. There are many different circumstances and so we have also needed to consider additional wording to set the context for this particular case. You need to think of 7.ii in relation to the chapeau text, "decisions and actions of the IANA Functions Operator should be made objectively based on policy agreed to through the recognised bottom-up multi-stakeholder processes. As such, decisions and actions of the IANA Functions Operator should..." In other words, this is about the difference between gTLDs and ccTLDs and marks that US extraterritoriality should not overrule the appropriate national or local processes under which the registry is operated. So IANA could not turn around and say to a ccTLD, you must submit to the gTLD WHOIS policy, for example. I guess your suggestion, "that IANA functions should never be exploited for political purposes" is a good, if only a partial, response to the issue that the IANA functions operator should not use its "power" to overrule the applicable policy basis for a ccTLD (however this might be defined under local circumstances). Martin From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 09 March 2015 22:42 To: Martin Boyle; 'cwg-stewardship@icann.org' Subject: RE: Principles: revised draft 9 March Martin I am fine with all of it except 7 ii. The troublesome part is "For ccTLDs, respect national sovereignty." I don't think many people on this group fully understand the legal and operational consequences of invoking national sovereignty here. Moreover I don't think you need language that causes so much potential trouble. It is sufficient to say, "Policy decisions for ccTLDs are usually made locally through nationally agreed processes in accordance with national laws and in compliance with IETF technical standards. Post transition of the IANA function, nothing will be done by ICANN/IANA to impact the stable operation of ccTLD Registries and gTLD Registries." You might want to add a statement that IANA functions should never be exploited for political purposes; i.e., whatever state has IANA in its jurisdiction must not exploit that to attack another state. But "respect national sovereignty" is at once too vague and too sweeping. Some would read it as requiring conformity to sovereign demands in every case, no matter what, others could read it to mean that the preferences of the sovereign will be taken into account but there is no real commitment to conform to them. I think this opens a can of worms that we don't want to open. From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Martin Boyle Sent: Monday, March 9, 2015 1:35 PM To: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: [CWG-Stewardship] Principles: revised draft 9 March Dear Colleagues, I attach a revised draft of the principles document based on our calls on 3 & 5 March. I believe we have a text that is pretty much in its final form, with only one outstanding issue. Looking at the remaining highlighted changes: 5.ii & iii: These are mainly editorial and have been discussed without opposition on recent calls. 5.iv footnote: We had comments about the meaning of consensus in the footnote. I do not think that defining consensus is in the remit of this document, but is part of the considerations of any entity that we establish. Hence I have added, "Conditions for consensus will need to be agreed appropriate for the group" to make this clear. 5.vi: As I said when I flagged this paragraph as of concern, I am inherently uneasy about a principle that is essentially optional and where it might need to be re-written because of subsequent choices that we make. Either it is a principle or it isn't. I believe that we need to understand the implications of what we are trying to say, so I am taking editor's right to propose a new formulation that should be independent of subsequent decisions. 6.ii: Was agreed as not being a principle last week. 7.i: Editing agreed last week. 7.ii: We took this off-line. There has been some progress in discussions with Paul and Elise. I have made a drafting proposal to both for wording that tries to take into account the concerns they have expressed. However, this paragraph needs to be held in abeyance until we have heard the views of both. 8.ii: In discussion with Erick, we have identified a compromise that moves away from saying anything about the policy authority and who it might or might not be. The proposed wording ("In particular, the IANA functions operator should not impose any additional requirements on the registry unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.") turns this around to prevent the IANA functions operator making unilateral decisions that impact the ccTLD except in (rare) cases of global security, stability and resilience. Given the delicate balance behind this text, I hope that others will find this formulation acceptable and I thank Erick for his support in finding this compromise. 9.i: A minor point here that was discussed last week. The wording is not necessary to the text, but does make it clearer that i. is about separability now and iii. says we would need to include separability for all future IANA functions operators. 10: A reasonable edit proposed by Mary last week: no objections have been raised. Hence I would hold 5.ii-iv, 6.ii, 7.i, 9.i and 10 to be agreed text if there are no objections. 5.iv: I suggest we use the new wording unless there is significant opposition. 7.ii: This has to stay in abeyance subject to agreement by Elise (in discussion with the GAC) and by Paul Kane. 8.ii: Again I suggest we use the proposed wording unless there is significant opposition. I look forward to comments on this approach, and please do flag early any difficulties you might have with any of the proposals. Best Martin
From: Martin Boyle [mailto:Martin.Boyle@nominet.org.uk] Yes, it is a difficult topic and partly because people do interpret national sovereignty in different ways. But, as you know, for the GAC, reference to national sovereignty is crucial. MM: Not really. What is needed is not a vague "reference to" national sovereignty, but the elimination of any opportunity for one state to exercise extraterritorial jurisdiction via the DNS root. That is a far more clearly specified way in which IANA actions might negatively impinge on legitimate sovereignty interests, but it avoids any claim that states have sovereignty over the root per se, which is a claim that we cannot and must not entertain. I reiterate: you need to think about the implications of telling 192 states that they have sovereignty over a shared global resource. Sovereignty is a claim of exclusivity. You need to think of 7.ii in relation to the chapeau text, "decisions and actions of the IANA Functions Operator should be made objectively based on policy agreed to through the recognised bottom-up multi-stakeholder processes. As such, decisions and actions of the IANA Functions Operator should..." In other words, this is about the difference between gTLDs and ccTLDs and marks that US extraterritoriality should not overrule the appropriate national or local processes under which the registry is operated. So IANA could not turn around and say to a ccTLD, you must submit to the gTLD WHOIS policy, for example. MM: That is precisely my point. As I said above, this I have no trouble with, indeed, I passionately support the point made above. That kind of a statement contributes something useful and positive, whereas a blanket reference to sovereignty would encourage precisely the kind of extraterritorial assertions of authority that we don't want to happen.
Dear Martin: Thankyou. I can appreciate the fastidious work involved in getting us thus far. If you would allow me, I have a quibble with footnote 1 on page 2: <<1. A group can be considered captured when one or more members are able to …. etc.>> There are doubtless going to be stakeholders with an interest in 'capture' who are not necessarily members of the 'group'. Best regards Christopher On 09 Mar 2015, at 18:34, Martin Boyle <Martin.Boyle@nominet.org.uk> wrote:
Dear Colleagues,
I attach a revised draft of the principles document based on our calls on 3 & 5 March. I believe we have a text that is pretty much in its final form, with only one outstanding issue.
Looking at the remaining highlighted changes:
5.ii & iii: These are mainly editorial and have been discussed without opposition on recent calls.
5.iv footnote: We had comments about the meaning of consensus in the footnote. I do not think that defining consensus is in the remit of this document, but is part of the considerations of any entity that we establish. Hence I have added, “Conditions for consensus will need to be agreed appropriate for the group” to make this clear.
5.vi: As I said when I flagged this paragraph as of concern, I am inherently uneasy about a principle that is essentially optional and where it might need to be re-written because of subsequent choices that we make. Either it is a principle or it isn’t. I believe that we need to understand the implications of what we are trying to say, so I am taking editor’s right to propose a new formulation that should be independent of subsequent decisions.
6.ii: Was agreed as not being a principle last week.
7.i: Editing agreed last week.
7.ii: We took this off-line. There has been some progress in discussions with Paul and Elise. I have made a drafting proposal to both for wording that tries to take into account the concerns they have expressed. However, this paragraph needs to be held in abeyance until we have heard the views of both.
8.ii: In discussion with Erick, we have identified a compromise that moves away from saying anything about the policy authority and who it might or might not be. The proposed wording (“In particular, the IANA functions operator should not impose any additional requirements on the registry unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.”) turns this around to prevent the IANA functions operator making unilateral decisions that impact the ccTLD except in (rare) cases of global security, stability and resilience. Given the delicate balance behind this text, I hope that others will find this formulation acceptable and I thank Erick for his support in finding this compromise.
9.i: A minor point here that was discussed last week. The wording is not necessary to the text, but does make it clearer that i. is about separability now and iii. says we would need to include separability for all future IANA functions operators.
10: A reasonable edit proposed by Mary last week: no objections have been raised.
Hence I would hold 5.ii-iv, 6.ii, 7.i, 9.i and 10 to be agreed text if there are no objections.
5.iv: I suggest we use the new wording unless there is significant opposition.
7.ii: This has to stay in abeyance subject to agreement by Elise (in discussion with the GAC) and by Paul Kane.
8.ii: Again I suggest we use the proposed wording unless there is significant opposition.
I look forward to comments on this approach, and please do flag early any difficulties you might have with any of the proposals.
Best
Martin
<Draft of Principles - updated 9 March.docx>_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
This time to the list... From: Martin Boyle Sent: 10 March 2015 17:56 To: 'CW Lists' Subject: RE: [CWG-Stewardship] Principles: revised draft 9 March Indeed, Christopher, but the group is not going to be captured except by members of the group or through capture of the processes selecting members. So I think "stakeholders" in this case is ok, but would be ok for us to substitute "members." I'll substitute unless anyone objects. Incidentally, I'd see capture as a problem not only when one or more can control the process (which is unlikely), but also when the majority of members have lost interest and are no longer active in the discussion - essentially leaving the field to others and following the lead of their "better informed" colleagues. It is a common malaise in committees when a small, but vociferous minority dominate the discussions. It can also happen when the workload is too high for most people to devote the time, leaving the work to those better resourced and (through guilt trip or otherwise) simply acceding to their conclusions. That said, I think the meaning is clear enough - it is up to the stakeholder communities to monitor how their members are performing and we can try to over-specify things. Anyway, I'd also see a committee that takes away the collective responsibility of the multi-stakeholder community as a bad substitute for accountability to the global Internet community and any committee should expect to go out to the community to get endorsement for its decisions. Martin From: CW Lists [mailto:lists@christopherwilkinson.eu] Sent: 10 March 2015 17:02 To: Martin Boyle Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Principles: revised draft 9 March Dear Martin: Thankyou. I can appreciate the fastidious work involved in getting us thus far. If you would allow me, I have a quibble with footnote 1 on page 2: <<1. A group can be considered captured when one or more members are able to .... etc.>> There are doubtless going to be stakeholders with an interest in 'capture' who are not necessarily members of the 'group'. Best regards Christopher On 09 Mar 2015, at 18:34, Martin Boyle <Martin.Boyle@nominet.org.uk<mailto:Martin.Boyle@nominet.org.uk>> wrote: Dear Colleagues, I attach a revised draft of the principles document based on our calls on 3 & 5 March. I believe we have a text that is pretty much in its final form, with only one outstanding issue. Looking at the remaining highlighted changes: 5.ii & iii: These are mainly editorial and have been discussed without opposition on recent calls. 5.iv footnote: We had comments about the meaning of consensus in the footnote. I do not think that defining consensus is in the remit of this document, but is part of the considerations of any entity that we establish. Hence I have added, "Conditions for consensus will need to be agreed appropriate for the group" to make this clear. 5.vi: As I said when I flagged this paragraph as of concern, I am inherently uneasy about a principle that is essentially optional and where it might need to be re-written because of subsequent choices that we make. Either it is a principle or it isn't. I believe that we need to understand the implications of what we are trying to say, so I am taking editor's right to propose a new formulation that should be independent of subsequent decisions. 6.ii: Was agreed as not being a principle last week. 7.i: Editing agreed last week. 7.ii: We took this off-line. There has been some progress in discussions with Paul and Elise. I have made a drafting proposal to both for wording that tries to take into account the concerns they have expressed. However, this paragraph needs to be held in abeyance until we have heard the views of both. 8.ii: In discussion with Erick, we have identified a compromise that moves away from saying anything about the policy authority and who it might or might not be. The proposed wording ("In particular, the IANA functions operator should not impose any additional requirements on the registry unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.") turns this around to prevent the IANA functions operator making unilateral decisions that impact the ccTLD except in (rare) cases of global security, stability and resilience. Given the delicate balance behind this text, I hope that others will find this formulation acceptable and I thank Erick for his support in finding this compromise. 9.i: A minor point here that was discussed last week. The wording is not necessary to the text, but does make it clearer that i. is about separability now and iii. says we would need to include separability for all future IANA functions operators. 10: A reasonable edit proposed by Mary last week: no objections have been raised. Hence I would hold 5.ii-iv, 6.ii, 7.i, 9.i and 10 to be agreed text if there are no objections. 5.iv: I suggest we use the new wording unless there is significant opposition. 7.ii: This has to stay in abeyance subject to agreement by Elise (in discussion with the GAC) and by Paul Kane. 8.ii: Again I suggest we use the proposed wording unless there is significant opposition. I look forward to comments on this approach, and please do flag early any difficulties you might have with any of the proposals. Best Martin <Draft of Principles - updated 9 March.docx>_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
Dear Colleagues, I'm afraid I will not be able to join tomorrow's call. I attach a further revised draft of the principles document based on comments received in response to the 9 March draft. I believe we have a text that is pretty much in its final form, with only one main outstanding issue. There is also an issue from Seun on the new footnote 1 in paragraph 5.ii associated with defining the IANA functions operator. I have also separated this from the proposal for general agreement on text that has not brought in any new discussion. Looking at the remaining highlighted changes: 5.ii (ex footnote) & iii: These are mainly editorial and have been discussed without opposition on recent calls. 5.ii footnote: I am not sure I agree with Seun's proposal, so it would be good to hear what others think: both versions are in the text. 5.iv footnote: We had comments about the meaning of consensus in the footnote. I do not think that defining consensus is in the remit of this document, but is part of the considerations of any entity that we establish. Hence I have added, "Conditions for consensus will need to be agreed appropriate for the group" to make this clear. In response to Christopher Wilkinson, I have amended the footnote to read "one or more members". 5.vi: As I said when I flagged this paragraph as of concern, I am inherently uneasy about a principle that is essentially optional and where it might need to be re-written because of subsequent choices that we make. Either it is a principle or it isn't. I believe that we need to understand the implications of what we are trying to say, so I am taking editor's right to propose a new formulation that should be independent of subsequent decisions. 6.ii: Was agreed as not being a principle last week. 7.i: Editing agreed last week. 7.ii: We took this off-line. There has been some progress in discussions with Paul and Elise. I have made a drafting proposal to both for wording that tries to take into account the concerns they have expressed. However, this paragraph needs to be held in abeyance until we have heard the views of both. Milton has also contributed his thoughts. 8.ii: In discussion with Erick, we have identified a compromise that moves away from saying anything about the policy authority and who it might or might not be. The proposed wording ("In particular, the IANA functions operator should not impose any additional requirements on the registry unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.") turns this around to prevent the IANA functions operator making unilateral decisions that impact the ccTLD except in (rare) cases of global security, stability and resilience. Given the delicate balance behind this text, I hope that others will find this formulation acceptable and I thank Erick for his support in finding this compromise. 9.i: A minor point here that was discussed last week. The wording is not necessary to the text, but does make it clearer that i. is about separability now and iii. says we would need to include separability for all future IANA functions operators. 10: A reasonable edit proposed by Mary last week: no objections have been raised. Hence I would hold 5.ii (ex footnote)-iv, 6.ii, 7.i, 9.i and 10 to be agreed text if there are no objections. 5.ii footnote: we need to have views on the suitability of the two versions. 5.vi: I suggest we use the new wording unless there is significant opposition. 7.ii: This has to stay in abeyance subject to agreement by Elise (in discussion with the GAC) and by Paul Kane. 8.ii: Again I suggest we use the proposed wording unless there is significant opposition. I look forward to comments on this approach, and please do flag early any difficulties you might have with any of the proposals. Best Martin
Hi, On 11-Mar-15 15:58, Martin Boyle wrote:
5.iv footnote: We had comments about the meaning of consensus in the footnote. I do not think that defining consensus is in the remit of this document, but is part of the considerations of any entity that we establish. Hence I have added, “Conditions for consensus will need to be agreed appropriate for the group” to make this clear. In response to Christopher Wilkinson, I have amended the footnote to read “one or more members”.
as this was my issue, just wanted to say I am comfortable with the change. Thanks avri --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Thanks Seun for pointing out I forgot to attach... Apologies to all and it is not attached. From: Martin Boyle Sent: 11 March 2015 19:58 To: cwg-stewardship@icann.org Subject: Principles: revised draft 11 March Dear Colleagues, I'm afraid I will not be able to join tomorrow's call. I attach a further revised draft of the principles document based on comments received in response to the 9 March draft. I believe we have a text that is pretty much in its final form, with only one main outstanding issue. There is also an issue from Seun on the new footnote 1 in paragraph 5.ii associated with defining the IANA functions operator. I have also separated this from the proposal for general agreement on text that has not brought in any new discussion. Looking at the remaining highlighted changes: 5.ii (ex footnote) & iii: These are mainly editorial and have been discussed without opposition on recent calls. 5.ii footnote: I am not sure I agree with Seun's proposal, so it would be good to hear what others think: both versions are in the text. 5.iv footnote: We had comments about the meaning of consensus in the footnote. I do not think that defining consensus is in the remit of this document, but is part of the considerations of any entity that we establish. Hence I have added, "Conditions for consensus will need to be agreed appropriate for the group" to make this clear. In response to Christopher Wilkinson, I have amended the footnote to read "one or more members". 5.vi: As I said when I flagged this paragraph as of concern, I am inherently uneasy about a principle that is essentially optional and where it might need to be re-written because of subsequent choices that we make. Either it is a principle or it isn't. I believe that we need to understand the implications of what we are trying to say, so I am taking editor's right to propose a new formulation that should be independent of subsequent decisions. 6.ii: Was agreed as not being a principle last week. 7.i: Editing agreed last week. 7.ii: We took this off-line. There has been some progress in discussions with Paul and Elise. I have made a drafting proposal to both for wording that tries to take into account the concerns they have expressed. However, this paragraph needs to be held in abeyance until we have heard the views of both. Milton has also contributed his thoughts. 8.ii: In discussion with Erick, we have identified a compromise that moves away from saying anything about the policy authority and who it might or might not be. The proposed wording ("In particular, the IANA functions operator should not impose any additional requirements on the registry unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.") turns this around to prevent the IANA functions operator making unilateral decisions that impact the ccTLD except in (rare) cases of global security, stability and resilience. Given the delicate balance behind this text, I hope that others will find this formulation acceptable and I thank Erick for his support in finding this compromise. 9.i: A minor point here that was discussed last week. The wording is not necessary to the text, but does make it clearer that i. is about separability now and iii. says we would need to include separability for all future IANA functions operators. 10: A reasonable edit proposed by Mary last week: no objections have been raised. Hence I would hold 5.ii (ex footnote)-iv, 6.ii, 7.i, 9.i and 10 to be agreed text if there are no objections. 5.ii footnote: we need to have views on the suitability of the two versions. 5.vi: I suggest we use the new wording unless there is significant opposition. 7.ii: This has to stay in abeyance subject to agreement by Elise (in discussion with the GAC) and by Paul Kane. 8.ii: Again I suggest we use the proposed wording unless there is significant opposition. I look forward to comments on this approach, and please do flag early any difficulties you might have with any of the proposals. Best Martin
Dear colleagues, I've been negligent with this document, but I attach a redlined (well, in my case, bluelined) version that has a number of what I hope are understood to be very small changes. These are intended either to keep the scope within the names functions, or to make it clear that any proposal that delivers the functions as they are working now is adequate. That's what I understand we're supposed to be working on, so I think these are just tiny clarifying items. If people disagree, I don't feel too strongly about any of these: I think that, if we produce something that steps outside of names, the other communities will tell us to take a long walk off a short pier; and I think that, if we are going to insist on improvements as part of the transition we simply won't get a transition at all, with all the negatives that implies. I am quite uneasy with this, however, in 7.ii: [Suggested compromise] For ccTLDs, respect national sovereignty: Policy decisions for ccTLDs [may be/are usually] made locally through nationally agreed processes in accordance with national laws and in compliance with IETF technical standards. Post transition of the IANA function, nothing will be done by ICANN/IANA to impact the stable operation of ccTLD Registries and gTLD Registries. It's the last sentence that alarms me. I propose something like this: "Post transition of the IANA function, IANA will continue to provide service to existing registries in conformance with prevailing technical norms, conforming with policy decisions of registries security and stability of the root zone itself." Here's why: the last sentence as written is not constrained by technical reality, the operational constraints on the root zone, or for that matter policy decisions made by ISO (who determine the relevant country codes). For instance, both of the following could be argued against using that principle: 1. ISO decides to deprecate a particular country's two-letter code, because the country ceases to exist. An existing ccTLD registry could appeal to this principle to argue that the registry should not be closed anyway. This is harmful to the policy of harmony with ISO 3166. 2. The IETF determines that it is necessary for continued security and stability that some additional resource records are added to inrastructure zones (like the root zone and TLDs) to indicate that they are infrastructure zones and mostly perform delegation. It publishes a standard to this effect, and ICANN duly adds a relevant resource record to the root zone, which causes additional queries to flow towards child zone; this causes load which negatively affects the functioning of a registry that was already marginal. This is to say nothing of a case where, say, a country passed a national law insisting that they get 25 nameservers for the ccTLD or other such technically broken decisions. I hope we can find language that is more in line with operating a global shared resource like the root zone. Best regards, A On Wed, Mar 11, 2015 at 08:10:29PM +0000, Martin Boyle wrote:
Thanks Seun for pointing out I forgot to attach... Apologies to all and it is not attached.
From: Martin Boyle Sent: 11 March 2015 19:58 To: cwg-stewardship@icann.org Subject: Principles: revised draft 11 March
Dear Colleagues,
I'm afraid I will not be able to join tomorrow's call.
I attach a further revised draft of the principles document based on comments received in response to the 9 March draft. I believe we have a text that is pretty much in its final form, with only one main outstanding issue. There is also an issue from Seun on the new footnote 1 in paragraph 5.ii associated with defining the IANA functions operator. I have also separated this from the proposal for general agreement on text that has not brought in any new discussion.
Looking at the remaining highlighted changes:
5.ii (ex footnote) & iii: These are mainly editorial and have been discussed without opposition on recent calls.
5.ii footnote: I am not sure I agree with Seun's proposal, so it would be good to hear what others think: both versions are in the text.
5.iv footnote: We had comments about the meaning of consensus in the footnote. I do not think that defining consensus is in the remit of this document, but is part of the considerations of any entity that we establish. Hence I have added, "Conditions for consensus will need to be agreed appropriate for the group" to make this clear. In response to Christopher Wilkinson, I have amended the footnote to read "one or more members".
5.vi: As I said when I flagged this paragraph as of concern, I am inherently uneasy about a principle that is essentially optional and where it might need to be re-written because of subsequent choices that we make. Either it is a principle or it isn't. I believe that we need to understand the implications of what we are trying to say, so I am taking editor's right to propose a new formulation that should be independent of subsequent decisions.
6.ii: Was agreed as not being a principle last week.
7.i: Editing agreed last week.
7.ii: We took this off-line. There has been some progress in discussions with Paul and Elise. I have made a drafting proposal to both for wording that tries to take into account the concerns they have expressed. However, this paragraph needs to be held in abeyance until we have heard the views of both. Milton has also contributed his thoughts.
8.ii: In discussion with Erick, we have identified a compromise that moves away from saying anything about the policy authority and who it might or might not be. The proposed wording ("In particular, the IANA functions operator should not impose any additional requirements on the registry unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.") turns this around to prevent the IANA functions operator making unilateral decisions that impact the ccTLD except in (rare) cases of global security, stability and resilience. Given the delicate balance behind this text, I hope that others will find this formulation acceptable and I thank Erick for his support in finding this compromise.
9.i: A minor point here that was discussed last week. The wording is not necessary to the text, but does make it clearer that i. is about separability now and iii. says we would need to include separability for all future IANA functions operators.
10: A reasonable edit proposed by Mary last week: no objections have been raised.
Hence I would hold 5.ii (ex footnote)-iv, 6.ii, 7.i, 9.i and 10 to be agreed text if there are no objections.
5.ii footnote: we need to have views on the suitability of the two versions.
5.vi: I suggest we use the new wording unless there is significant opposition.
7.ii: This has to stay in abeyance subject to agreement by Elise (in discussion with the GAC) and by Paul Kane.
8.ii: Again I suggest we use the proposed wording unless there is significant opposition.
I look forward to comments on this approach, and please do flag early any difficulties you might have with any of the proposals.
Best
Martin
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- Andrew Sullivan ajs@anvilwalrusden.com
On Mar 11, 2015, at 22:21, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
1. ISO decides to deprecate a particular country's two-letter code, because the country ceases to exist.
I scanned the ISO standard 3166-3:2014 (Part 3: Code for formerly used names of countries) which lists four categories why codes by be deprecated. I summarise below (1) Significance change of country name: EXAMPLE BURMA (BU) name changed to MYANMAR (MM) in 1989. (2) Division of country EXAMPLE CZECHOSLOVAKIA (CS) was divided into the CZECH REPUBLIC (CZ) and SLOVAKIA (SK) in 1993. (3) Merger of countries EXAMPLE 1 YEMEN, DEMOCRATIC (YD) and YEMEN ARAB REPUBLIC (YE) merged into YEMEN, REPUBLIC OF (YE) in 1990 (change of both country names). EXAMPLE 2 GERMAN DEMOCRATIC REPUBLIC (DD) united with GERMANY, FEDERAL REPUBLIC OF (DE) in 1990 (removal of one country name). (4) Obsolescence of country name (A country was gobbled up by an other(s)): EXAMPLE NEUTRAL ZONE (NT); the name was deleted in 1993. The area is now absorbed into IRAQ (IQ) and SAUDI ARABIA (SA). I haven't checked whether this rhymes with Part 1 of the standard. For the moment I don't suggest to do anything with this information but in case it comes, we should probably refer to these source Regards, jaap
participants (6)
-
Andrew Sullivan -
Avri Doria -
CW Lists -
Jaap Akkerhuis -
Martin Boyle -
Milton L Mueller