June 2015 - CWG-Stewardship

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

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

June 4, 2015

Greg, I do not follow your #2. ICANN will certainly need to budget for these expenses, but why "these will remain within ICANN (the "corporate parent")"? Everything related to IANA should be within PTI, other than services that under contract, it gets from ICANN. If IANA needs work done by external contractors, certainly the funding will ultimately come from ICANN, but it should be channelled through IANA. Alan At 03/06/2015 11:27 PM, Greg Shatan wrote: >David, > >Thanks -- that's very helpful. I'm not >surprised that IANA staff has been directly >involved in development and innovation for the >systems that the IANA staff uses; that makes perfect sense. > >The examples that were given earlier, though, >were DNSSEC and IPv6, where I expressed >skepticism that these were the result of R&D >carried out by the IANA staff (which is not to >say they were completely uninvolved). Perhaps >they were just inapposite examples. More >on-target examples, such as the ones you gave, >might have taken this exchange down a different path (or no path at all). > >In terms of budgeting for the near future, it >sounds like appropriate funds would need to be >allocated for development and innovation by PTI, >due to (1) the plan "to impose a vast array of >new service level requirements for the IANA >functions (and not just naming-related >functions) that will need to be monitored", >since "In order to meet these new requirements, >non-trivial amounts of software development >will" need to "be undertaken directly by IANA >staff" and (2) the replacement of aging systems. > >âMy overall takeaway then is: > >1. PTI, as a separate corporate entity housing >the IANA staff, will need a discrete budget. >2. ICANN will also need to budget for >IANA-related expenses and activities carried out >by employees and resources other than the IANA >staff, since these will remain within ICANN (the "corporate parent"). >3. PTI will need to budget for development and >procurement relating to replacing aging software >systems and to meeting any new requirements put >in place as part of the transition, and for any >other expenses relating to changes to the IANA staff's technical environment. >4. ICANN will also need to budget for R&D >relating to innovations relating to inputs to >the IANA function (along the lines of DNSSEC and >IPv6), which are not developed primarily by IANA staff. > >Greg > > > >On Wed, Jun 3, 2015 at 10:58 PM, David Conrad ><<mailto:david.conrad@icann.org>david.conrad(a)icann.org> wrote: >Greg, > >Apologies for the slow response a bit buried in stuff right now.

1 0

Comment on III.A.ii (131 ff) Re: For your review - CWG-Stewardship Proposal v2
by Andrew Sullivan June 3, 2015

June 3, 2015

Hi, I know I've said this before, so I won't go on, but it seems more than a little strange to be making a "final" proposal that includes a large section that basically says, "We ran out of time to do this." I know why that happened, but it is still awfully hard to swallow such a thing as the "final" document. Why not add here in ¶ 137 the following sentences: ---%<---cut here--- In the interests of changing as few things as possible at the moment of transition, the DT recommends making the SLEs exactly the same as the SLAs under the NTIA contract for a period of six months. At the end of that six months, the new SLEs as currently under development can be adopted. This permits the adoption of new SLEs more in keeping with actual IANA performance, while maintaining the old instrument of measurement across the horizon of the transition. --->%---cut here--- I'm not especially wedded to the 6 months, though I think much shorter would be ill-advised. Best regards, A -- Andrew Sullivan ajs(a)anvilwalrusden.com

1 0

ICANN 53 Overview of Sessions and Schedule
by Grace Abuhamad June 3, 2015

June 3, 2015

Dear all, The ICANN53 meeting schedule is posted at: https://buenosaires53.icann.org/en/schedule-full Below, here is an overview the sessions that relate to the CWG-Stewardship. As I noted on the call Tuesday: we made sure that the CWG-Stewardship sessions do not overlap with the CCWG-Accountability sessions or the ICG sessions. Thursday, June 18th: * ICG Working Session 1 (All Day) Friday, June 19th: * ICG Working Session 2 (All Day) * CCWG-Accountability Working Session 1 (All Day) Sunday, June 21st: * CCWG-Accountability Meeting with the Board (15:00-16:00) * IANA Stewardship Transition and Enhancing ICANN Accountability Information Session (18:30-20:00) Monday, June 22nd: * CWG-Stewardship/CCWG-Accountability Joint Townhall Meeting (10:30-13:00) * CWG-Stewardship Engagement Session (16:45-18:00) Wednesday, June 24th: * CCWG-Accountability Working Session 2 (15:30-17:00) Thursday, June 25th: * CWG-Stewardship Working Session 1 (08:30-10:00) * CCWG-Accountability Working Session 3 (10:30-12:00) * ICG Working Session 3 (09:00-13:00)

2 3

Agenda for Meeting #57 (4 June)
by Grace Abuhamad June 3, 2015

June 3, 2015

Dear all, Here is the agenda for tomorrow¹s call: Proposed Agenda 1. Opening Remarks 2. Update on Public Comments a. Mechanics & process b. Implications for Design Teams/ CWG (whole) c. Finalizing the Review Tool & Responses 3. Update on questions to ICANN Finance & Legal 4. 2nd Reading of Final Proposal 5. CCWG-Accountability a. Phrasing conditionality in the CWG Proposal b. CCWG-Accountability Public Comment close on 3 June 6. Overall Timeline / Milestones a. Communications b. Webinars on 11 June c. Sessions at ICANN 53 7. Client Committee - Instructions to Sidley 8. AOB 9. Closing Remarks Best, Grace

1 0

DT-O recommendations/responses for Public Comment Review Tool
by Grace Abuhamad June 3, 2015

June 3, 2015

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 <cgomes(a)verisign.com> Date: Sunday, May 31, 2015 at 9:54 PM To: "DT-O Mailing List (dto(a)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: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: 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

3 3

GNSO-ccNSO engagement in the Multi-stakeholder model
by Martin Boyle June 3, 2015

June 3, 2015

Jonathan, In one of Friday's calls I noted the imbalance between GNSO and ccNSO (and wider ccTLD) engagement in the various entities the model is putting in place. You responded that the GNSO is not an homogenous organisation. I let the discussion drop, not because I was happy with the response, but because I was getting no traction in the discussion and did not want to delay it any further. However, I would like to at least put on the record why I think the current imbalance is wrong and gives too much say to a GNSO-skewed view of the IANA. I'm sure that the traditional balance in favour of the gTLD-centric view of the universe works fine in an ICANN setting, given that most of this is about policy-making and relatively little of this implicates ccTLDs. This is the main reason for the disproportionate funding of ICANN's costs between the GNSO and ccNSO: simply put, ccTLDs use considerably less of ICANN's resources. However, for the IANA, without exact figures to hand, I would expect the balance in use between ccTLDs and gTLDs of the IANA services to be much more equal and most ccTLDs recognise the need for fair funding of the IANA functions operation. Certainly I'd say we - gs and cs - have at least equal interest in the provision of a well-run IANA functions operator. But a serious alarm went up for me a few weeks ago when I had an extended exchange on list with Chuck and Milton about ICANN instructions to IANA. (For many of you, this must have seemed like an esoteric discussion. I'd say it was symptomatic of a fundamental issue that we are failing to address.) The gTLD view of life (in this case) was all about ICANN giving instructions to the IANA functions operator. That is certainly not the case for ccTLDs, but I got a lot of abuse for pointing this out. It only was resolved when the ICANN (ccNSO-focussed) secretariat was asked to clarify. In a post transition world, I'm not sure how easy it we will be able to draw on this experience and knowledge to back up a point. That is my fundamental concern about the imbalance between the ccNSO and GNSO. Especially a concern as the constituent parts of the GNSO are heavily policy focussed. It will be so easy for the GNSO representatives in various discussions to focus on gTLD issues (ignoring that ccTLD delegations and redelegations are actually usually well outside an ICANNic framework) and misshape the discussion accordingly. I'm not sure that the current proposed imbalance will be sustainable in the long term unless it is very clear that different needs are respected. (In the same way, in the ccTLD world, we need to be very cautious about not applying inappropriate blanket rules.) Simply ignoring the significant number of ccTLD comments about the imbalance might be an easy solution, but it is not a good compromise. I hope that this helps colleagues understand my very real concerns about our direction of travel. Martin

6 14

For your review - DT M responses (escalation mechanisms)
by Marika Konings June 3, 2015

June 3, 2015

Dear All, Please find below the proposed responses to some of the comments related to escalation mechanisms that have been developed by DT M. Note that DT M is still considering, with input from DT C, its response to a comment from AFRALO which suggested that the PTI Board should be able to ask for an SIFR. As soon as the DT M / DT C have come to agreement on that issue the proposed response will be shared with the mailing list. Best regards, Marika * Escalation by CSC to GNSO and ccNSO is adding a layer of escalation that may not be necessary. CSC could call for SIFR instead. (Centre for Democracy & Technology) - DT M Proposed CWG Response: The CSC charter was largely done prior to the discussions on the PTI Board, as such escalation to the GNSO and ccNSO was the chosen escalation path at the time. Escalation to IFR was considered beyond the scope of the CSC, instead as any issues raised would relate directly to the technical performance of IANA, ccNSO and GNSO were considered to have direct access to broader community input on this issue and would be in a position to make an assessment on appropriate next steps. The GNSO and ccNSO step is an approval step with multi-stakeholder involvement, not an escalation mechanism as such. Having only the CSC initiate an SIFR may not be appropriate considering its limited remit and size. * Question from intensive working sessions: Should CWG consider whether GNSO should be changed to RySG - ccNSO and RySG would consider whether it should be escalated to a multi-stakeholder process to determine next steps? Proposed CWG Response: DT M proposes to keep escalation to ccNSO and GNSO instead of RySG noting that the equivalence between RySg and the ccNSO is a false equivalence. Both name supporting organizations are multistakeholder organizations. In the GNSO there is a global organization of the stakeholders into separate SGs and Constituencies. The ccNSO is a local stakeholder organization so that according to RFC 1591, each of the ccTLD is a self contained multistakeholder entity. * Inconsistencies between CSC and its responsibilities and the IFR (NCSG) - DT M Proposed CWG Response: The CSC charter was largely done prior to the discussions on the PTI Board, as such escalation to the GNSO and ccNSO was the chosen escalation path at the time. As a result, there may be inconsistencies between CSC and IFR escalation mechanisms. We believe these have been addressed in the next iteration of the proposal. * All deliberations and output should be transparent. CSC should not escalate to ccNSO or GNSO as these are policy bodies. (ALAC) - DT C Proposed CWG Response: DT M understands the concern but practical considerations of using existing structures have enough advantages to support going this direction. Furthermore, DT M notes that GNSO has explored the relationship between implementation of adopted GNSO policies, and as such can raise alarms and request a SIFR. Also, DT M observes that the GNSO is about more than only policy and has views of all things ICANN, such as strategy and budget.

1 0