[CWG-Stewardship] Principles: revised draft 9 March

[Martin Boyle]

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 at syr.edu]
Sent: 09 March 2015 22:42
To: Martin Boyle; 'cwg-stewardship at 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 at icann.org<mailto:cwg-stewardship-bounces at icann.org> [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Martin Boyle
Sent: Monday, March 9, 2015 1:35 PM
To: cwg-stewardship at icann.org<mailto:cwg-stewardship at 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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150310/8d7c8524/attachment-0001.html>