[CWG-Stewardship] For your review - Draft Transition Plan V3.2

Mon Apr 20 16:54:14 UTC 2015

Hi all,

Under I.C on page 4, the registries involved are the root-zone and root-zone WHOIS databases, the .int zone and WHOIS databases, the root-zone trust anchor and the IDN language tables registry, aren't they?  This section is about the registries that are being amended, not the customers, if I understood the question and the annex A analysis correctly.

The footnote on page 6 should (I think) read redelegation (twice, replacing relegation).

Page 9:  II.A-2.iii last paragraph:  "are developed" would more correctly read "might be developed".  Laws are not necessarily in place in every country.

Page 9: II.A-3.i:  Isn't this more than delegation and redelegation for gTLDs?  I am not sure I understand the different service for gTLDs and ccTLDs.  Don't gTLDs also need "all functions which apply to gTLDs and can modify the Root Zone database or its WHOIS database...?"

Page 14 II.B-3.iii final paragraph:  it might be worth emphasising "For the few ccTLD registries with a contract, the language..."  This is a rarity and that should be clear in the text.  Is there a knock-on problem with II.B-3.iv ("Where applicable, the results...")?

Page 17 III.A second bullet:  Am I missing something?  I thought the PTI was the IANA functions operator.  In this case the SLA would be between ICANN and the PTI.

More importantly, could we include in this bullet a requirement for consultation with registries to allow continuing development of the SLA - something along the lines of, "as might be agreed with TLDs from time to time"?

Page 19 penultimate paragraph in III.A.iii:  I thought we had agreed that the CSC would escalate by asking for a review - subject to agreement by the ccNSO and GNSO (subject to this being a role that they could do) who would initiate the review.  Did we agree a change?  (I would prefer to see an intermediary and more inclusive step, rather than the responsibility for such a decision falling on a very limited number of registries.)  Can we make sure that we are consistent?

Page 22 III.A.vii.1.b:  should this read "as requested by the IANA functions operator"?  Or is it now the PTI?  (There are other places where the various names IANA/IANA functions operator/PTI are used interchangeably. And where there might be confusion.  So for III.A.vii.2.c (page 23) it is not clear who is funding whom.  I think that the budget would be provided by ICANN to the PTI Board to support the IANA functions operator's capability...)

Page 23 III.A.vii.4:  I'm firmly of the view of separation of these two functions at least during transition and subject to a clear review before any changes are made.  The RZ Maintainer should be required to carry out the changes requested by the IANA functions operator, but has the option (and even the obligation) to query instructions if there is any reason for doubt.

Page 26 IV.A 3rd of the first set of bullets:  I thought that we had agreed that the authorisation function would not e maintained.  Then on page 27 there is a reference (IV.B first bullet) to an appeal mechanism for ccTLD delegations & redelegations.  If I remember correctly we put this off to further assessment by the ccNSO, but there was a request for this to be retained for gTLDs.

I have not reviewed the annexes yet, but thought that my (mainly editorial) changes should not wait until the last possible minute!

Hope this helps

Martin

From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Marika Konings
Sent: 19 April 2015 23:34
To: Avri Doria; cwg-stewardship at icann.org
Subject: Re: [CWG-Stewardship] For your review - Draft Transition Plan V3.2
Importance: High

Thanks Avri and others that have commented so far. We are working hard to incorporate your comments / edits as well as the new materials received. In the meantime, please find attached a pdf version of the files circulated on Friday that may make it easier to identify the correct page numbers.

Best regards,

Marika

From: Avri Doria <avri at acm.org<mailto:avri at acm.org>>
Organization: Technicalities
Reply-To: Avri Doria <avri at acm.org<mailto:avri at acm.org>>
Date: Monday 20 April 2015 00:23
To: "cwg-stewardship at icann.org<mailto:cwg-stewardship at icann.org>" <cwg-stewardship at icann.org<mailto:cwg-stewardship at icann.org>>
Subject: Re: [CWG-Stewardship] For your review - Draft Transition Plan V3.2

Hi,

It would be good it there pages numbers.  Maybe because I am using libreoffice i did not see them.  In my notes I use the page numbers I added to my version.

The suggestion of numbers paragraphs that was made on list, it is a pretty good idea as well.

Overall comment.  Our proposal still seems somewhat disjoint.  That and the number of things that are still listed as TBD makes it ever harder to suspend disbelief about making the deadline.  We have a lot of work to do yet.

Some specific comments/questions below:

--

Page 5

Overlap or interdependencies between your IANA requirements and the functions required by other customer communities

What process is there for dealing with possible future  differences of opinion between operational communities on those issues?  Does something need to be elaborated?

--

Page 9

Local laws applicable to ccTLDs, or IDN ccTLDs, associated with a specific country or territory are developed by the governments of those countries or territories

Is it worth mentioning that they are also only applicable within those countries or territories?

--

Page  13

For most gTLDs the language is: Disputes arising under or in connection with this Agreement that are not resolved pursuant to Section 5.1, including requests for specific performance, will be resolved through binding arbitration conducted pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce. Any arbitration will be in front of a single arbitrator, unless (i) ICANN is seeking punitive or exemplary damages, or operational sanctions, (ii) the parties agree in writing to a greater number of arbitrators, or (iii) the dispute arises under Section 7.6 or 7.7. In the case of clauses (i), (ii) or (iii) in the preceding sentence, the arbitration will be in front of three arbitrators with each party selecting one arbitrator and the two selected arbitrators selecting the third arbitrator.

For ccTLDs the language relating to this is usually a version of the following: Each party shall nominate one arbitrator, and the two arbitrators so nominated shall, within 30 days of the confirmation of their appointment, nominate the third arbitrator, who will act as Chairman of the Arbitral Tribunal.

Does some form of this language belong in the bylaws as one of appeals/redress mechanisms.  Is this something that should be discussed by CCWG?

--

Page 14

For gTLDs the arbitration will be conducted in the English language and will occur in Los Angeles County, California, USA

Given the international dispute resolution concerns, is this still appropriate?

--

Page 17

A.     The elements of this proposal

Should the possibility of an SLA between ICANN and the the IFO be include in the list?

Even with a functional separation configuration defining an SLA, or rather a Service Level Requirement, might be reasonable.

--

Page 18/19

While the IANA Function Review will normally be scheduled based on a regular 5 year rotation with other ICANN reviews, it may also be initiated by a the Customer Standing Committee (CSC).

Is this the only way to trigger it?

The latest suggestion from the DT-N short text was:

"While the IANA Review Function will normally be scheduled based on a regular 5 year rotation with other ICANN reviews, it may also be initiated by  a defined community process."

The 'community process' has not yet been agreed upon.

I also note that Annex D (CT-N), includes the following:

While the Periodic Review will normally be scheduled based on a regular 5 year rotation with other ICANN reviews. A Special Periodic Review may be also be initiated by community action:

*         Recommendation of the CSC and 1 SO

*         Recommendation of a combination of 3 AC/SO, including at least one SO and one AC in agreement.

Unfortunately that text was not reproduced under the triggers section (my fault).
I also do not think it has been discussed in the full group yet.

In any case this needs further discussion

--

Page 24

III.A.x.    Regulatory and Legal Obligations

Formatting error:  it is listed under III.A.ix and does not have its own header/number.

--

Page 24

In a previous note this is a place I suggested listing -- iii.A.xi  Separation Decision Mechanism  (which is different from DT-F which is separation operation requirements - which could happen as either the result of a catastrophe or a decision.)

--

Page 26

Operational requirements to achieve continuity of service and possible new service integration throughout the transition

Do any of these require Bylaws changes?

--

Annex A -

Does this need to also deal with possible RFC6791 Special-use domain names issues?

---

Annex A

a.       Redelegation and Operation of the .INT TLD (NTIA IANA Functions Contract: C.2.9.4)
NTIA could have decided to that at any point.  If the contract is replaced by transition mechanisms, will it still be possible to

Upon designation of a successor registry

Do we need a process and triggers for such a process?  Seems to me we do.  Otherwise are we are saying this stays with IANA for evermore?

--

Annex D

In general needs to be edited for general reference to IRT instead of various forms of [Periodic] IANA Function Review.  If indeed IRT  is the name we are settling on.  Personally I am not sure the name of the team should be used as  the name of the review, but can live with any name we wish to give it.

What should trigger reviews?

As mentioned above this needs to be edited to include the correct triggers for the Special IRT.

--

Annex F

Overall, responses on behalf of just 28 managers were received (see Appendix B). Such a low level of response was judged to be an insufficient a basis to provide a mandate for the inclusion of an appeal mechanism in the CWG's proposal

Was the fact that the opinions of those who did answer might be ignored announced up front?  Was there a threshold of responses predefined for the survey?  If not seems problematic to ignore the results.

Why is an appeals mechanism that is optional but was favored by 26 active ccTLDs not the right answer?

--

Annex I - Does the CSC charter belong in the Bylaws?

--

Annex N - If the IANA contract provisions that persist post transition are not in a   contract between ICANN and its IANA affiliate, then were are they codified? Bylaws?

--

Annex M

The NTIA has contributed and opened avenues to resources (such as those from NIST - the National Institute of Standards and Technologies, a part of the U.S. Department of Commerce in efforts surrounding DNSSEC). Moreover as the Root Zone Administrator, they have been the entity to ultimately approve the changes going forward.

Who will be responsible for this going forward?

The design team does not fully agree on this recommendation. Although no one suggests any merger at this time,

some do not believe that there are sufficient hard reasons to make it a "principle". Comments are welcome on this issue.

With relation to the issue of the Mutli-party organization, and do we need to have an RZM separate form the IFO:

I assume we are not thinking of Assigning the IFO to the RZM, so really are we just asking if the RZM function will be subsumed into the IFO function?  Or would the two functions remain separate but just both assigned to IANA?

To what purpose?
And isn't this issue out of scope at the moment?

--

Appendix A

*         Security Authorization and Management Policy

... and other sections of the Appendix

Some of the formatting is hard to follow - especially in regard to subordinate clauses.

Also who be responsible for the policy aspects of any possible future changes to this process or to its technical details?

That is about it for now
avri

On 17-Apr-15 17:58, Marika Konings wrote:
Dear All,

Please find attached for your review the latest version of the CWG-Stewardship Transition Proposal. Please note that it is still very much work in progress as some key pieces are still missing such as the information from the legal memo that is forthcoming, outstanding work of the design teams (DT A) as well as final language from 'DT X'. However, we did already want to give you an opportunity to review where we are at and as such we would like to encourage you to instead of editing the document line by line, to focus on whether there is information missing or incorrect, the updated recommendations of some of the design teams (e.g. DT M and N) as well as reviewing some of the changes we have made for style and consistency purposes to the DT recommendations. Note that thanks to Kim Davies a number of clarifications have been made to section I and II.

We are still working on the annexes (focused on consistency and readability) as well as formatting and numbering of the overall document.

As we've moved quite some things around in section III to follow a more logical order, there is a lot of redline in the document which does not necessarily represent new or changed content, but also content that has changed position. As such, you will also find attached a clean version to facilitate your review.

Please share any comments you may have (preferably with a reference to page number and section) with the mailing list by Monday 23.59 UTC at the latest.

Best regards,

Marika

_______________________________________________

CWG-Stewardship mailing list

CWG-Stewardship at icann.org<mailto:CWG-Stewardship at icann.org>https://mm.icann.org/mailman/listinfo/cwg-stewardship

________________________________
[Avast logo]<http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software.
www.avast.com<http://www.avast.com/>

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