- CWG-Stewardship - lists.icann.org

Escalation Process
by Olivier MJ Crepin-Leblond June 5, 2015

June 5, 2015

Hello all, I was unfortunately unable to attend the last CWG call due to commitments at EuroDIG but have reviewed the transcript of the call and have a question regarding the escalation. As Alan voiced it clearly on the call, the ALAC has concerns about the multistakeholder component of the escalation, has doubts that the GNSO and ccNSO are balanced multistakeholder groups - and has concerns that with the IANA Function's main goals being to operate a stable Internet, the very Advisory Group that is concerned with Stability of the Domain Name System is not explicitly included in the escalation process. In order to clear any misunderstanding and in order to avoid us all driving in the wrong direction and potentially committing a faux-pas that could cast doubt over the multistakeholder element of the escalation process, could someone please clearly summarise the escalation, from the point a problem takes place, through its escalation from the CSC all the way to when it reaches the SCWG, and please identify the make-up of each of the groups along the way? In order to evaluate the multistakeholder element, we need to look at the overall picture, not each of the small groups or committees in isolation. As far as the GNSO engaging in more than policy work, we may have stumbled on an anomaly. Agreed, the GNSO has and indeed should comment on matters that affect it directly, such as the Budget. That said reading Article X of the ICANN Bylaws, it is very clear indeed that the GNSO is a policy-development body. Its voting thresholds are quite carefully fleshed out and all relate to a PDP except in the creationg of an Issues Report. It is therefore clear that if the GNSO was to assume a responsibility in the IANA escalation process, this would require Bylaw Changes. As far as the GNSO being multistakeholder, it needs to be recognised that the multistakeholder aspect of the GNSO is highly imbalanced, with two thirds of its Council being composed of Private Sector and with no specific Technical Community nor Governments being represented. Furthermore, there are absolutely no checks and balances for Geographical balance and the GNSO Council is therefore highly biased in its composition towards North America and Western Europe. So if we need a multistakeholder committee in the critical path of the escalation, this is not it. I also do not agree with the notion that a multistakeholder consultation (an open public comment period), but the critical path on the escalation not including a full multistakeholder Committee, is actually a multistakeholder process. This is akin to saying the ITU - which makes all its decisions in a multilateral fashion, is multistakeholder because it includes an open comment period where stakeholders other than Governments are allowed to speak. Whenever a complete stakeholder category can be completely ignored at will by other stakeholders, this is not a multistakeholder model. Balance means having the right to vote, not just comment. I look forward to your responses. Kindest regards, Olivier

5 7

Updates to circulate (including WEBINAR)
by Grace Abuhamad June 5, 2015

June 5, 2015

Dear all, Our Webinar announcement is published (and edited per the meeting yesterday) here: https://www.icann.org/news/announcement-2015-06-03-en. * IMPORTANT: Live interpretation services are available in Arabic, Chinese, French, Spanish, and Russian. Interpretation services will be provided by advance request only, so please be sure to request language services when submitting an RSVP. Language requests must be received by 9 June in order to adequately resource the webinars. Also, attached is an updated participation stats graphic for the IANA Stewardship Transition and Enhancing ICANN Accountability discussions through the end of May. Finally, ICANN has launched the new stewardship-accountability page on icann.org! (https://www.icann.org/stewardship-accountability) There is now a drop down menu from the main website that links directly to the ICG microsite and CCWG-Accountability wiki pages. On the main stewardship-accountability page you will be able to find links to every working group webpage as well. Best, Grace

1 0

Comment from co-chairs of the cross community working group on IANA Stewardship (CWG-Stewardship)
by Jonathan Robinson June 4, 2015

June 4, 2015

As submitted to the current public comment forum for the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) regarding input needed on its Proposed Accountability Enhancements (Work Stream 1). Jonathan & Lise

2 1

Re: [CWG-Stewardship] DT-O recommendations/responses for Public Comment Review Tool
by Alan Greenberg June 4, 2015

June 4, 2015

I have no specifics. David Conrad is the only person regularly contributing that may have some insight. I don't know to what extent he pays attention to every CWG e-mail! My gut feeling is this item is probably not huge, but also that it could vary heavily from year to year. It would be correct that this work is not done entirely within IANA, but I am quite sure that some will be and at times there will need to be budgets for consulting, external contract work and such. I find it fascinating that we are spending our time on conjecture when we could simply ask the people involved. Alan At 03/06/2015 01:14 PM, Greg Shatan wrote: >I think Item 3 needs to be clarified: > >3Â· Need for a budget to support R&D should be included (ALAC) DT O / DDT F > >DT-O recommendation: The CWG-Stewardship >recommends that there needs to be flexibility to >allow for spending related to R&D for other >special project (e.g. DNSSEC, IPv6) which would >need to be covered as part of PTI operations (as >also recommended by DT F). These would be >included in the draft budget which is expected >to be presented 9 months in advance as part of >the presentation of the proposed budget. > >Perhaps someone within ICANN and/or IANA can >provide information on how much "R&D" or >innovation development goes on within the IANA >Functions group (which I envision as Elise >Gerich and her reports), and how much of that >goes on elsewhere within ICANN or outside ICANN >(e.g., IETF). Perhaps this could be answered >with regard to the examples given (DNSSEC and >IPv6); I would assume the IANA Functions group >was consulted at points in development and >particularly with regard to deployment, but it >was not my impression that these were >"researched and developed" within the IANA team. > >Unless there are good reasons to change, we >should follow and fund the current model for >division of labor on development/innovation vs. >implementation. It would help to clarify this, >and perhaps tighten up the language a bit, to >avoid the impression that IANA is going to become a big-time R&D shop. > >Greg > >On Wed, Jun 3, 2015 at 11:13 AM, Grace Abuhamad ><<mailto:grace.abuhamad@icann.org>grace.abuhamad(a)icann.org> wrote: >Dear all, >Here below are the DT-O responses and >recommendations for the Public Comment Review Tool > >1Â· Consider InternetNZ experience with regards >to budget development (InternetNZ) DT O > >DT-O recommendation: PTI will submit a budget to >ICANN 9 months in advance, and that ICANN would >approve it at least 3 months in advance of the >fiscal year. And, CWG-Stewardship supports budget transparency. > > > >2Â· CWG will need to develop a proposed process >for the IANA-specific budget review (CCWG) DT O > >DT-O recommendation: CWG-Stewardship agrees with >the comment of the CCWG-Accountability chairs >for the first year's budget and notes that a >process should be developed possibly as part of >the implementation of the proposal. > > > >3Â· Need for a budget to support R&D should be included (ALAC) â DT O / DT F > >DT-O recommendation: The CWG-Stewardship >recommends that there needs to be flexibility to >allow for spending related to R&D for other >special project (e.g. DNSSEC, IPv6) which would >need to be covered as part of PTI operations (as >also recommended by DT F). These would be >included in the draft budget which is expected >to be presented 9 months in advance as part of >the presentation of the proposed budget. > > > >4Â· PTI should be adequately funded and need to >ensure that expenditures are appropriate should be clarified ((IPC) CWG > >DT-O Recommendation: Budget process referred to >previously (PTI will submit a budget to ICANN 9 >months in advance, and that ICANN would approve >it at least 3 months in advance of the fiscal >year). 1 year of operating expenses updated on >annual basis in escrow for use by PTI, and an >additional year kept open to low-risk >investments. Both years of funds would be for >use of funding PTI in case ICANN is unable (for >some future reason) to fund PTI. Appropriateness >of expenses will be handled through CCWG Accountability process. > > > >5Â· Separation Costs: Some comments dealt with >concerns about how IANA expenses would be >covered following a separation process. DT-N >supports this recommendation. We look to the >full CWG for a determination on where this issue >is best resolved (DT N, DT L, DT O or full CWG). > >DT-O Recommendation: Separation costs are not >required at the point of transition, but this >information could be requested to be developed >within the first year of implementation. In >first year, increase by 10% each of the >following until such estimates can be provided: > > - 1 year of operating expenses updated > on annual basis in escrow for use by PTI, and > > - an additional year earmarked open to low-risk investments.. > > > >Best, >Grace > >From: <Gomes>, Chuck <<mailto:cgomes@verisign.com>cgomes(a)verisign.com> >Date: Sunday, May 31, 2015 at 9:54 PM >To: "DT-O Mailing List >(<mailto:dto@icann.org>dto(a)icann.org)" <<mailto:dto@icann.org>dto(a)icann.org> >Subject: [DT-O] FW: Updated public comment action items summary > >Here are the action items from this summary that >relate to DT-O that I think require more >discussion on our part. Please review them and comment on this list. > > > >Chuck > > > >Â· Consider InternetNZ experience with >regards to budget development (InternetNZ) DT O > >CWG response: CWG appreciates the input provided >and suggests that those steps be customized for >how PTI is expected to develop its budget (as a >best practice). Note that the ATRT2 also had >recommendations concerning budget that might be applicable here. > >Â· CWG will need to develop a proposed >process for the IANA-specific budget review (CCWG) DT O > >CWG response: CWG agrees with the comment of the >CCWG-Accountability chairs and notes that a >process should be developed possibly as part of >the implementation of the proposal. The CWG >should consider whether there are any elements >that should be developed as part of the final proposal. > >Â· Need for a budget to support R&D >should be included (ALAC) DT O / DT F > >CWG response: The CWG recommends that there >needs to be flexibility to allow for spending >related to R&D which would need to be covered as >part of PTI operations (as also recommended by >DT F). It is the expectation that these would be >included in the draft budget which is expected >to be presented 9 months in advance as part of >the presentation of the proposed budget. > >Â· PTI should be adequately funded and >need to ensure that expenditures are appropriate > should be clarified (IPC) CWG > >CWG response: See previous response concerning >adequate funding. Setting of budget between PTI >and ICANN should happen in a transparent way, >but no additional say for the community unless >there are indications that there is not >sufficient funding or âgold platingâ, noting >that there are also other mechanisms available >to provide input on the budget, including the CCWG mechanisms. > >Â· Separation Costs: > >Some comments dealt with concerns about how IANA >expenses would be covered following a separation >process. DT-N supports this recommendation. We >look to the full CWG for a determination on >where this issue is best resolved (DT N, DT L, DT O or full CWG). > >CWG response: Regarding operation costs, the CWG >notes the RySG suggestion to have a sufficient >portion of registry fees dedicated to the IANA >services. The CWG also recognizes that there >would be transition costs and ongoing operation >costs related to the possible selection of a new >operator, which are expected to be covered by >ICANN. The CWG will review the proposal and clarify accordingly. > > > > > > > >From:<mailto:cwg-stewardship-bounces@icann.org>cwg-stewardship-bounces(a)icann.org >[<mailto:cwg-stewardship-bounces@icann.org>mailto:cwg-stewardship-bounces@icann.org] >On Behalf Of Marika Konings >Sent: Friday, May 29, 2015 11:10 AM >To: <mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org >Subject: [CWG-Stewardship] Updated public comment action items summary > > > >Dear all, > > > >Please find attached the updated summary of >public comment action items as updated with the >CWG responses as discussed during the calls over >the last two days. Staff will be incorporating >these responses in the public comment review >tool (complete version). Design Teams are >requested to provide any additional responses >that need to be included in the public comment >review tool by Monday 1 June at the latest. > > > >Thanks, > > > >Marika > >_______________________________________________ >CWG-Stewardship mailing list ><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-stewardship > > >_______________________________________________ >CWG-Stewardship mailing list >CWG-Stewardship(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-stewardship

6 21

FW: [client com] CWG Proposal - Sidley Comments
by Jonathan Robinson June 4, 2015

June 4, 2015

All. FYI. Please see attached from Sidley on review by them of the draft final proposal and in response to the CWG’s instructions managed by the CWG Client Committee. Jonathan From: Flanagan, Sharon [mailto:sflanagan@sidley.com] Sent: 04 June 2015 06:16 To: Client Committee; (cwg-stewardship(a)icann.org) Subject: [client com] CWG Proposal - Sidley Comments Dear All, Attached are Sidley’s comments on the revised CWG proposal. Our comments are reflected in tracked changes to the marked version circulated on June 3 (word document titled Final Transition Proposal). We have also attached a redline showing only our incremental changed pages (pdf document titled Sidley Comments…). In addition, attached is a draft of language expressing the conditionality of the CWG proposal on the requisite CCWG accountability mechanisms. This is marked against current paragraph 105 in the CWG proposal. SHARON FLANAGAN Partner Sidley Austin LLP 555 California Street Suite 2000 San Francisco, CA 94104 +1.415.772.1271 <mailto:sflanagan@sidley.com> sflanagan(a)sidley.com <http://www.sidley.com> www.sidley.com <http://www.sidley.com/> http://www.sidley.com/files/upload/signatures/SA-autosig.png SIDLEY AUSTIN LLP **************************************************************************************************** This e-mail is sent by a law firm and may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. ****************************************************************************************************

2 1

Notes, Recordings, Transcript CWG IANA Meeting #57 4 June 2015
by Brenda Brewer June 4, 2015

June 4, 2015

Dear all, The notes, recordings and transcripts for the CWG IANA Meeting # 57 on 4 June 2015 are available here: https://community.icann.org/pages/viewpage.action?pageId=53777828 Kind regards, Brenda Action Items Action: Staff will send a stable document version by end of day Thursday. Action (Grace): edit Webinar announcement to make clear that, at the time of the webinars, we will have provided the final version Notes 1. Opening Remarks * Majority of meeting will be focused on item 4 (recent edits, changes, etc) * Be sure that the essence is captured (staff can assist with wording) 2. Update on Public Comments * Mechanics & process: broke down by sections of the document. * Finalizing the Review Tool & Responses: basing the document as of June 1st before the first draft final version was sent out. * Lengthy 250-page document, but we will make sure everyone will have time to review 4. 2nd Reading of Final Proposal * This version includes Avri, Greg and most of Sidley * Edit footnote 3 (related to paragraph 105): The CSC is not a legal entity. (second sentence: switch "or" to "and") * In IFR section (and Annex F), "Periodic reviews should occur at no more than five-year intervals." * If a Special review occurs within a short period, allow for some flexibility * Para 123: needs to be internally consistent and checked for relevant position in the document (ref: that CSC is further defined later in document, for example) * Question of escalation to GNSO * SLEs will be updated and submitted along with proposal( but perhaps not as extensive as was presented in Istanbul) * Paragraph 141: "or equivalent community mechanism derived from the CCWG-Accountability process" (possible to bracket/footnote different points in the text) * Paragraph 167: staff assets and coherence of PTI is important, but not sure that the last sentence adds clarity yet. * Paragraph 170: Not accurate that CSC is multistakeholder (remove the word and use 'customer-based instead) * Add footnote to paragraph 169 about .INT (footnote is currently in Annex to section II, so duplication here would be helpful) * Paragraph 275: composition of IFRT does not have extra RySG member (only the SCWG does) * Annex S: Term sheet would be the subject of negotiation between PTI and ICANN (with PTI having independent advice). This term sheet is an example/draft and precursor to the ICANN-PTI Contract. ---> use the word "sample" instead of "draft" Further reading of the document on Tuesday but there is a deadline cut-off on Sunday 7 June for comments/edits. Action: Staff will send a stable document version by end of day Thursday. Action (Grace): edit Webinar announcement to make clear that, at the time of the webinars, we will have provided the final version

1 0

For your review - CWG-Stewardship Proposal v2
by Marika Konings June 4, 2015

June 4, 2015

Dear All, Please find attached version 2 of the proposal for your review which includes amongst others: * Jonathan¹s edits * Paragraph 102 CWG edits * Paragraph 106 Martin addition * Paragraph 111 Martin addition * Paragraph 150 CWG edits * Paragraph 226 (Annex F) Martin addition * Paragraph 233 table Martin addition * Updated Section VI * Updates from DT F concerning root zone maintainer and root zone environment * Suggested changes to address Andrew¹s comments in paragraph 96 and 107 * Updates to Annex F * Updates to Annex J per DT M¹s feedback Please note that there are still some outstanding items that we expect to update as soon as input is received, for example from DT C concerning the CSC Charter, paragraph 123 (note action item for Avri), outstanding issue in Annex J under discussion by DT M and C, DT A input concerning Annex H, but we already wanted to give you an opportunity to review these latests updates. Furthermore, we will continue working on proofreading and formatting of the document and annexes. Please share any comments and/or edits you have with the mailing list. Best regards, Marika

6 10

An update on the work of the SLE group
by Paul M Kane - CWG June 4, 2015

June 4, 2015

Apologies for the silence, at a personal level it has been a traumatic three weeks and I am only now (slowly) re-surfacing. Firstly, I would like to thank Kim Davies from IANA, Bernie Turcotte from ICANN and Adam Smith from my staff for the constructive manner in which progress is being made on the SLE document. Adam stepped in with the agreement of DT-A members to keep the momentum during my period of absence as we are all keen to conclude the SLE document. Rest assured that members of DT-A all share a similar vision and are working well together, recognize that the SLE is a keystone document and on the 8th June members of DT-A and IANA/ICANN will have another telephone conference to identify where additional work is needed. Secondly, I'd like to confirm that DTA is _not_ suggesting *any* process "improvements" or "changes". We are capturing the current process, documenting it as best we can and determining the performance matrix for the process. Our focus has been on those Registries that interact with IANA electronically via the RZM service. We hope to be able to provide an SLE document for those Registries that do not use the RZM preferring to send letters or faxes or phone calls to request/authorise changes, and more time will be needed to address this minority IANA user community. We are trying to avoid discriminatory practice but obviously inefficient interactions with IANA does add delay to the process which is not IANA's fault. Third, it is vital that IANA services are delivered to all Registries whether gTLDs or ccTLDs, contracted or non-contracted, on a equal, impartial and efficient basis. To avoid IANA being the subject of claims of expediting the changes of one registry operator in preference to another, DT-A and IANA share the view there should be a distinction between metrics that should be collected to support general analysis, versus those which are the critical metrics that are considered important to set specific thresholds for judging breaches in ICANNs ability to provide an appropriate non-discriminatory level of service. Fourth, there may be those in the community that want a vague SLE that does not follow professional standards for efficient operation. IANA specifically don't want that and have committed to provide attributable metrics for the party responsible for that particular process. DT-A support IANA in this and in post-transition world, without the (perceived) liability protection of the US Government "validating" change requests - there may be parties who seek redress from ICANN/IANA (alleging) non-performance when the problem is outside of IANA's control. Consequently, the SLE seeks to define the process and specific measures against which specific thresholds should be set, with an expectation that the IANA Functions Operator will normally perform within the threshold. Where there is an inability to meet the threshold, it will be identified, resulting in follow-up with the Customer Standing Committee to identify the cause, and whether the issues is within IANA's control. Regular unexplained inability to meet the thresholds may result in remedial action and it is anticipated the thresholds will be modified over time as part of periodic reviews of the service level expectation. For those registries wanting DT-A to define the process for end-to-end automation - an API for interacting with IANA - that is outside the scope of this Design Team and may be addressed post transition. Our goal is to work with IANA to capture a workable SLE that reassures all parties there is no room for discriminatory practice and the broader community can be confident that IANA will continue to deliver exemplary service post transition. I am optimistic there will be a draft released following our next call and DT-A will continue to work with IANA after the 8th June to refine the SLE and incorporate as much of IANA's sub-processes as possible. I hope to be on today's call but I will not have Internet access between the end of the call and our call with IANA on Monday so please do not expect email replies in the intervening period. Best Paul

1 0

Comments on v2
by Greg Shatan June 4, 2015

June 4, 2015

I have attached suggested changes and comments to Section III of the latest draft of the Proposal. These are marked in track changes, on top of the track changes already in the document. Most of the sections read quite well; most of my changes were in some of the more recently worked sections, which were "medium rare" as of our prior call. Greg Shatan

1 0

Some comments on CWG v2
by Avri Doria June 4, 2015

June 4, 2015

Hi, Some comments. Overall reads fairly well, though the font changes can be distracting. - Last sentence of para 96 - seems to just end. At the very least it needs punctuation, but I think perhaps a bit more. - Why is 96 all italics? - in Para 102, it might be worth explaining what the public comment tools does. - in Para 104, bullet 3, do we still have an issue on whether the CSC is part of ICANN or independent? I notice that the footnote referring to CSC still says 'could' - In Para 107, does everyone know what "ring fence" means? While it may have become a bingo word in this crowd, I am not sure that everyone will understand it. - in 108, > an “affiliate” of ICANN if PTI is a California public benefit > corporation without owners. is the 'if PTI', superfluous at this point? - in 117, I had requested that words 'or evaluations' be removed since evaluation of the implementation of policies should be in order for the IFR. - in 118 it discusses 'every 5 years'. I thought we had developed a wording earlier to the effect of 'no less that every 5 years' so that the periodicity could be changed if warranted. This also give some response to those who asked for it more frequently. I believe one of the CCWG issues is the need for flexibility to arrange a reasonable schedule for the multiplicity of reviews. If changed this would need to be reflected in 119 and appendix F as well. - in 119 should probably also mention that the IFR clock restarts after a SIFR. One thought, would we want to require the same two stage cycle after an SIFR we have at transition (and especially after a SCWG) of first a 2 year review and then back to the 5 year cycle? - in 123 how about something like: Following the triggers defined above, the naming Support Organizations would be responsible for reviewing the outcome of the CSC process (as defined in annex G), and the IANA Problem Resolution Process (as defined in Annex J) and for determining whether an Special IFR was necessary. After consideration, including a comment period, the Special IFR could be triggered by a supermajority vote of each of the ccNSO and GNSO Councils according to their normal procedures for determining supermajority. The Special IFR would follow the same multistakeholder cross community composition and process structure as the periodic IANA Function Review. .... (note, I only did this because the action item said "paragraph 123 (note action item for Avri)" Being of weak memory I looked at 123 trying to figure out what I was supposed to change. It was only after making a change and reading on that I realized it was 125 I was supposed to work on. Having reworked this text, I am submitting it for consideration. We did talk about this and there was concern that the gNSO and ccNSO did not include enough of the multistakeholder community among their membership. While I argue that this may or may not be the case, it seemed reasonable to require a comment period.) - in 125 (my action item) how about something like: An IFR may determine that Separation process is necessary. In making this determination, the IFR is not responsible for recommending a type of separation. If the IFR determines that a Separation Process is necessary, it will recommend the creation of the Separation Cross-Community Working Group (SCWG). This recommendation would need to be approved by a supermajority of each of the GNSO and the ccNSO Councils, according to their normal procedures for determining supermajority, and would need to be approved by the ICANN Board after a public comment period. A determination by the ICANN Board to not approve a SCWG that had been supported by a supermajority of the ccNSO and GNSO Councils would need to follow the same supermajority thresholds and consultation procedures as ICANN Board rejection of a PDP recommendation that is supported by a GNSO supermajority. And then change 144 to deal with the issue, something like: There would be no prescribed action for the Separation Process. It would be empowered to make a recommendation ranging from “no action required” to the initiation of an RFP and the recommendation for a new IFO. It could also determine that a different form of reorganization of the IANA function was necessary, such as divestiture of the PTI. In the case of a recommendation for any action, ICANN is expected to cover all costs related to the costs of transition and ongoing operation costs related to the possible selection of a new operator or other change. Moreover, in bearing such costs, it is to be required of ICANN that it does not raise costs for operators (and indirectly for registrants) in order to do so. this would also require a modification to L, which is discussed below. - going back to 143 last sentence: in order to disambiguate, how about something like: Both the recommendation to initiate the Separation Process and the outcomes of a Separation Process would need to be approved by the ICANN Board and would be subject to all escalations and appeals mechanisms. - on Page 128 point ii) Includes a representative of the IETF on a standing committee. Have they given permission for this inclusion considering the work it might take to carry out this obligation? - in para 169 , have we decided to just leave .int status quo in perpetuity? This is also reflect ina later appendix. - 173 describes the CSC as multistakeholder. Seems inappropriate. - page 33 table. In the first row, do only 53 % support legal separation? only 53 support creating a PTI? or only 53% support PTI being an public benefit affiliate? these table are repeated in an appendix with the same ambiguity about what the number mean. - page 35 indicates the PTI budget is ready for implementation. Is this actually the case? I had not gathered that from our meetings. - page 36 - the following sentence is confusing. What are we leaving to the ICG? > At this stage, considering possible interest and modifications > pending from the other operational communities, > the CWG-Stewardship leaves it to the ICG to determine establishing PTI. - page 37 again indicates that the CSC is a multistakeholder entity. I think this is inappropriate. If we are going to be bold enough to create something that is intentionally not multistakeholder we should be straightforward about it and our reasons for ignoring the mandate for a fully multistakeholder solution. - page 42 indicates that a list of members and particpants can be found on the wiki page. Might be worth listing the url. - 44 meting should be meeting - 43/44 While it is a very good description of the design team process it does not include the process by which we moved from the Contract Co. to the PTI. Does not include the discussion in Istanbul of multiple configurations being whittled down to two and then later to one. Might be worth including something on this since the first recommendation made such a hit with the world. And it might be worth descriing that journey. I know this section is incomplete. But with one day left, I figure I would mention it. - page 47 Should 3a mention the pending Framework of Interpretation. - page 48. re 5. should the possiblity of post transition work on .int be mentioned? - 253 says "a Special Review may be also be initiated by community action." should it be a Special IANA function Review may also be ... - page 62, table. Why did we change 1 RySG and 1 gTLD Registry to 3 RySG? the extra seat in for the RySG was only for the SCWG and not for the IFR. The decision in the IFR was to give the ccNSO an extra seat, not the RySG. Also I thought we want to allow for a non GNSO Registry to have a possible seat. If this is added, then we do need a paragraph similar to 273 saying that the RySG gets to do the picking after consultation with existing gTLD groupings from outside the RySG. - 275 should mention the acronym IFRT after the use of IANA Function Review Team so that the first instance of IFRT in 277 is understood. - 285 last sentence should be changed to: Subsequent reviews will be scheduled to commence at five year intervals from the date of the previous IANA Function Review. - 332 If the CSC is part of the ICANN, why is the IFO providing the secretariat? I thought that when this was discussed we had moved away from a IFO secretariat. Perhaps I misunderstood. - 369. I thought this was where the rySG got its 3rd seat based on the compromise concerning geographic distribution. - 372 Contains bracketed text. While a compromise concerning geo distribution was agreed in the CWG plenary meeting, it was rejected in the DT. This needs to be resolved. - 374 similar to changes in 125/144 we should add a first bullet to 374 that says: Decide on the remedy needed to resolve the issue(s) which caused initiation of the SCWG. The other bullets should then be condition on decing to do an RFP. For example, something like: * Decide on the remedy needed to resolve the issue(s) which caused initiation of the SCWG. * If the decison is to do an RPF o Developing RFP Guidelines and Requirements for the performance of the IANA Naming Functions; o Soliciting participation in the RFP Process; o Reviewing responses to the RFP o Selecting the entity that will perform the IANA Naming Functions; and o Managing any other Separation Process. * If a different process such as PTI divestiture is to be recommended, develop recommendations for that process. - 378 First sentence: Replace 'Special IFR could be triggered' with 'SCWG could be initiated' - 378 Remove Bullet one, it is redundant of the last bullet : - 378 in last bullet: Replace 'Creation of' with 'Approval by' - page 87 Appendix M - Does this need a mention of the escrow fund being proposed for IANA continuity? Will review terms sheet at some other point. I did notice that it has a lot of unresolved comments. That is about it for this pass. avri --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0