Marika: And to everyone in the CWG, this draft seems to be a big step toward the completion of the CWG's work, and I am sure the version that comes out Monday or Tuesday will increase confidence among people following the process that the names community can deliver something in time for the BA meeting. I had some questions and possibly some simple modifications to Section III.A, which is in effect the preamble to the proposal. There you have two bullet points: * ICANN to continue as IANA Functions Operator for the Naming Related Services through the creation of a Post-Transition IANA (PTI) * Establishment of service level agreement between the PTI and the IANA Functions Operator for the Naming Related Services In the first bullet point, would it not be more informative and accurate to say, "...through the creation of a legally separate affiliate Post-Transition IANA?" The second bullet point puzzles me. Wouldn't we be talking about the establishment of a SLA between ICANN and the PTI, not between PTI and itself?

Hi, On this issue the ICANN names solution should presume that ICANN remain the service contractor with the other operational communities in any model. It is only if these other operational communities initiate a request for a change to a direct service contract with IANA that it becomes an issue. As far as I know they have neither done so, nor desire to do so. I do not see an ambiguity in this. While there may be an opportunity for them to think about it, there is no requirement or implication that they do so. avri On 19-Apr-15 00:53, Andrew Sullivan wrote:

Unstated in the above is that, depending on whether we have fundamental bylaws or an affiliate, there are either one or two options for other communities. ICANN can be indifferent to how to proceed on this, but the other communities may need to make a decision:

• Continue the agreement with ICANN, who then undertake to have PTI do the work for those other communities. This is the only option available if PTI is a department of ICANN under some fundamental bylaw(s), but it remains available in case PTI is an affiliate.

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

Andrew, Thanks for the very detailed review and analysis. Here are my reactions to two of your comments/suggestions. Regarding your discussion about fundamental bylaws vs. contractual terms (III.A p 17ff), my understanding is that what we are proposing for public comment will be the legal separation approach, which will involve a contract so I don't think the functional separation approach is an option in what we are proposing even though it could be revived based on public comment. Also, I believe that fundamental bylaws may be proposed by the CCWG even if there is a contract so I don't think it is a matter of ' fundamental bylaws vs. contractual terms '. Regarding your comments about expression of interest statements on page 66, I get your point but I admit to having concerns if someone serving on the review team was unwilling to submit a statement of interest. I am not opposed to people with conflicts of interest being involved as long as it is publicly known what those interests are. It seems problematic to me if any member of the review team did not declare his/her interests. Chuck -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Sunday, April 19, 2015 12:54 AM To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - Draft Transition Plan V3.2 Dear colleagues, I've read the plan v 3.2 through. I here include my comments. Page numbers are from the redlined version. I hope these remarks are helpful. They are offered in the same spirit of frank collaboration that I've valued so far in the CWG Stewardship. Thanks to all of you for the hard work so far. GENERAL REMARKS To begin with, it's really very difficult to comment coherently on this document with the rather large gaps, particularly in section III. I know we ran out of time. It's nevertheless more than a little worrisome that we're looking at a document with some of its most central elements missing only a couple days before the document is supposed to be largely done. I think therefore we should be prepared for participants in this group to do additional heavy-duty reviews during public comment, and some of those reviews may reveal some pretty big issues. I make this remark not to cast blame, but to be explicit that we're rather shy of our goal and we're going to have to make up the deficiency somewhere. Various places in the text have questions that are, I think, unresolved parts of CWG or DT deliberations. If these are to remain in the text for public comment, I suggest setting them off in a box (or something -- marginal note? whatever) as stuff left explicitly open for the review process. Some of the more important annexes only really came available quite recently, and I barely had a chance to glance at some of them before our calls this week. Therefore in some cases this is my first serious look at them, so some of the annexes come in for more detailed comments than others in what follows. My silence on text should be taken to mean that I didn't see anything to comment on in this reading; I read it all pretty carefully (but I've doubtless missed things). As a small but important issue, several of the section numbers in the document are wrong. I am pretty sure, given the way it shows up, that this is due to the vagaries of contemporary word-processor (yes, "Word") section numbering. This is merely irritating to those already familiar with the developing text; but it's going to be awful during public comment, so it needs to get sorted before posting. On a personal note, I'll have really limited time to devote to more iterations of the draft (and probably many of the CWG meetings) for roughly a month, due to other commitments. I'll work to keep up with things via the list. BIG ISSUES 1. Section III.A has a serious ambiguity that has persisted through our discussions. I offer in the detailed remarks some ways to fix this, but not text, because it still seems to me conceptually troublesome. 2. Some places reach beyond the names community and implicate other communities. I make some suggestions in the detailed remarks about how to avoid these cases when I catch them (and it's appropriate). 3. Annex M item 2 actually appears to me to be a repudiation of NTIA's offer. See the detailed remarks. Every one of these strikes me as a fatal flaw to the text as it stands, though I think each can be repaired. I do not believe the proposal should go out for comment at all with any of them unresolved. DETAILED REMARKS I.D, p. 6: I think "extensions, could designate parts…" would be better here. That is, if the IETF did this, it would be a failure. If the IETF did this in name space already delegated by IANA, it would be a mistake by IETF. Similarly, if ICANN delegated something that was marked as special by the IETF, that would be a mistake by ICANN. Co-ordination is of course important and we should call this out, but "may" suggests that normal operation could make this happen, and my point is that it had better never happen. II.A.ii, p7 : Why the change to the description of Jon Postel's role? This reads like rewritten history — I’ve never heard him called “the then head” or anything of the kind. This reads as though there was a well-defined IANA function that was apart from the individuals carrying it out. I've never read anywhere else people saying that. I don't think we should try to sanitize the early history to make it seem more orderly than it was. II.A.ii, p7: "This document was not meant to be a policy document" This language, previously fixed, has returned. It’s flat out false. RFC 1591 was a policy document, it reads as one, and we should not claim it wasn’t (much less should impute intentions to someone who isn't alive any more to be asked about them). Indeed, Annex A (item c) lists 1591 as one of the policy documents! Also, to my knowledge there was never an attempt to revise 1591 (which would involve publishing a new RFC). Perhaps "supersede"? II.B.i, p13 (probably broken numbering). "Root Zone file or database are affected". I don't know why adding the word "file" here helps -- it just serves to obscure meaning. I urge whoever has the pen at this point to resist the temptation to add detailed clarifications of this sort at such a late stage. In this particular case, it serves to confuse, because it suggests that there is some in-principle difference between the root zone database and the STD 13 presentation-format zone file. If there _is_ such a difference, we have an enormous problem. If there's not, then this sort of clarification adds nothing, and it should be reverted. III.A p 17: "ICANN to continue as IANA Functions Operator for the Naming Related Services through the creation of a Post-Transition IANA (PTI)" cWe seem unable to decide clearly whether we're talking about a different organization or an internal department, but the current formulation is plainly wrong. • The first recommendation should be that ICANN hive off its IANA operations to the PTI. That's _all_ IANA functions, for everything that ICANN currently does as IANA operator (names, number resources, protocol parameters). Either this is an internal department with rules around it from the fundamental bylaws, or else it's an affiliate of some kind; but all the IANA functions ICANN is doing move together. • The second is the agreement between PTI and ICANN for the service-level rules for IANA names functions. Either the rules are a contract or else they're fundamental bylaws. (In the second case, it's funny to call this an "agreement".) Unstated in the above is that, depending on whether we have fundamental bylaws or an affiliate, there are either one or two options for other communities. ICANN can be indifferent to how to proceed on this, but the other communities may need to make a decision: • Continue the agreement with ICANN, who then undertake to have PTI do the work for those other communities. This is the only option available if PTI is a department of ICANN under some fundamental bylaw(s), but it remains available in case PTI is an affiliate. • Undertake a new agreement with PTI, if PTI is a separate organisation. III.A.vii nr. 4 p 23 (note: numbering is wrong. More magic section renumbering, I suspect) Couldn't this recommendation be that, at least at the time of transition, the principle holds? AFAIK nobody is suggesting changing this separation of roles now, and it could get changed in the future anyway by some policy change, so we don't have to pretend we're writing in concrete. (This remark also applies to the related bit in Annex M.) Annex A.a, p31. I am unaware of any mechanism by which the IETF standardisation process would today result in an actual entry in the root zone. If it did, I think that would be _prima facie_ evidence that the special names entry was not a special name at all, but rather an entry in the root zone that should be processed through usual channels. In fact, were such an entry to occur I think there would be more than 20 of us lined up to try out elements of the IETF recall process. What _is_ true is that the IETF can standardise a name (or in principle, even, a label in every domain) such that it is excluded from the root namespace and therefore prohibited from appearing in any version of the root zone. How about this: Policy for entries in the root zone are determined by ICANN policy setting mechanisms (e.g. for ccTLDs and gTLDs). The IETF standardisation process can create reservations from the global name space so that certain names that otherwise would be valid in the DNS root are disallowed. Annex A.c and A.d, p32. There is no provision in RFC 6761 to alter the whois for names added to the special names registry. I don't believe there is any overlap at all here. Annex A.e, p33. I think the overlap description here is wrong. I'd state it this way: Historically, some policy for INT (that of international databases for infrastructure use) was determined by the IETF. RFC 3172 recommended that such uses move under ARPA, and the only then-extant use of INT for such infrastructure (the IPv6 reverse mapping tree) was in fact moved under ARPA; all subsequent IETF infrastructure uses have been under ARPA. It is possible for an international treaty organization to put infrastructure entries under INT, but such entries would be in keeping with INT being used by international treaty organizations. IETF maintains a registry of special-use domain names according to rules in RFC 6761, and it could in principle create a conflict with .INT eligibility policy. Annex A.f, p33. Isn't a dependency here the IETF's creation of algorithm numbers for key types? (I don't care, but elsewhere there are overlaps that note the dependency on protocols or number resources, so this would be another such case.) Annex D, p41. There's a question at the bottom of this page. If it's to remain in the final document, maybe it should be boxed off as a particular question for the community during public comment? Otherwise, it looks like hangover from the drafting, or else a needless rhetorical question for what follows. (BTW, earlier on p41, "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:" should either be turned into a single sentence, or the "While" at the beginning should go.) In Annex D, p42, there's this: • The relative performance of the IANA Functions pre- and post-transition according to established service levels Surely that's a one-time consideration? That is, I'd expect to see that in year 2 but not in year 7. I anyway don't see why it's not subsumed under bullet 1. I observe that the review team composition is volunteering the IETF and RIRs to provide free work on this review team. Has anyone asked them whether they'd be willing to participate? Maybe these could be noted as "pending agreement" or something in the table? I'm particularly uneasy about it given the detailed appointment rules that follow. Historically, the IETF at least has been pretty sensitive to not appointing people to anything according to the receiving organisation's rules, and if these criteria persist then I suspect the IETF would bridle. (It occurs to me that other groups might react similarly. If they're making appointments as representatives, then the central procedure doesn't get to specify criteria, I suspect.) On p 46, there is both the claim that the cross-community working group approach was "used successfully" in preparing this document, and that the PRT is going to take six months including the two 40 day public comments. Assuming a 30 day month, that leaves 100 days (including weekends) for the PRT to do its work, including whatever integration of public comment materials needs to be done, all the reading of the voluminous materials outlined elsewhere in the annex, and so on. I apologise for saying something perhaps indelicate; but, while I can perhaps believe nine months, I cannot believe six, given what I've seen of this CWG and other ICANN groups working on things. That's not a criticism -- working in public takes time (IETF working groups are appallingly bad at meeting their milestones too. And have you ever seen a software development schedule? Please). At the same time, I note that the very next section in the annex actually lists three public comment periods, though I guess the first one can happen in parallel to appointment of the PRT. In the dependencies section p47 there are some questions. Are these questions for the pubic? See the "box" suggestion earlier. It's kind of strange that there's a list of periodic reviews on pp47-8 that doesn't name the PRT itself. Annex E appears to be an attempt to specify the succession of an operator for all IANA functions, and not the names ones. That's probably unwise. I'd remove at least the stuff in step 2 on page 50 about non-names stuff, and replace it all with a sentence, "Other data held by IANA may also need to transition, and other communities will be affected. The details of those transitions are beyond the scope of this proposal, which relates to names only." Or something like that. At the end (p 52) there are some outstanding questions. See earlier about boxing off. Note that there's considerably more than just "the website" involved in control over the domain name. In Annex I (p 66) there is a requirement for an expression of interest statement from everyone including appointed liaisons. See a similar discussion in annex D: I think that the liaison-sending organization gets to send its own choice, and there's nothing the target organization can do. Put this another way: suppose that the IAB was asked to send such a liaison, and the appointed candidate refused to supply the requisite form. What would the CSC be able to do? Refuse the appointment? There are additional elements to the selection process that seem similarly problematic. Annex J makes changes to an existing resolution process for all IANA users. I think this is _way_ beyond the remit of this CWG. I can say with a great deal of certainty that the protocol parameters community has an escalation procedure that is already working for it just fine. I suggest _very strongly_ that phase 2 of this section be revised to limit it clearly to names issues only. In Annex M, item 1.a: why is the "act as approver" approach a "very short term" solution? It seems like this is over-specifying. Item 2.a, p78, put more frankly, says, "The access that the NTIA used to provide to expertise actually can -- 'surely'! -- be provided by other means, but anyway we think that someone needs to be Boss of Big Changes, but we don't know who and we don't really have a reason why." I hope it is clear why I think that's a lousy recommendation. The NTIA says that it wants to move this function to the multi-stakeholder community because it believes that the multi-stakeholder community is grown up enough now to do this itself. This item says, in effect, that we disagree. Do we really want to say that? Item 3.a, p79, suggests earlier publication of decisions. I'm not opposed to this, but I don't see what difference it makes either. If the decision is already made, earlier public knowledge makes no difference. If the decision is _not_ already made, then this sounds like the thin end of a wedge to make these kinds of changes -- whether they be renumbering a name server or redelegation of a domain -- subject to some sort of public comment or review period. These activities are mostly operational and involve two or three actors (today, plus NTIA, but they're officially not doing anything but stamping the change). I'm quite uncomfortable with the implications here, and I think the section should make it clear that this is a sunlight provision but not an opportunity for wider consultation. I think ii is considerably less problematic than i in this regard. -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship

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@acm.org<mailto:avri@acm.org>> Organization: Technicalities Reply-To: Avri Doria <avri@acm.org<mailto:avri@acm.org>> Date: Monday 20 April 2015 00:23 To: "cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org<mailto:cwg-stewardship@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 1. 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 1. 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<mailto:CWG-Stewardship@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/>