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

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

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

This email has been checked for viruses by Avast antivirus software.
www.avast.com