[CWG-Stewardship] Principles: revised draft 11 March

Wed Mar 11 21:21:52 UTC 2015

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 at 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 at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship

-- 
Andrew Sullivan
ajs at anvilwalrusden.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Draft_of_Principles_-_updated_11_March.docx
Type: application/octet-stream
Size: 502670 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150311/eae10d41/Draft_of_Principles_-_updated_11_March-0001.docx>