October 2014 - CWG-Stewardship

Draft of Principles
by Lise Fuhr Nov. 11, 2014

Nov. 11, 2014

Dear All, As per the request from last week's call we have produced a list of the principles from the Charter of the CWG and the ICG (attached). Also as discussed last week Martin Boyle and I have been elaborating a set of principles and/or the criteria against which we would review the proposals the CWG will be developing, in order to ensure that the proposal takes into account the different aspects that need to be covered. The draft of those principles and/or criteria are also attached to this email for your consideration. Given this is not directly in line with the work required to develop proposals I am suggesting that these should only be discussed on the mailing list for time being. We will allocate time at the Face to Face meeting in Germany for us to consider the latest version of these as they will have evolved from discussions on the list. Best regards, Lise

10 14

Re: [CWG-Stewardship] [IANA-issues] Fwd: Names Community vs the other two communities
by Fouad Bajwa Nov. 3, 2014

Nov. 3, 2014

I don't think that IANA should be evolved as a separate entity at all and create new opportunities for bureaucracies for governments and industry control. The technical community proposals are highly reasonable to not make such a big fuss out of it and help IANA transition under a body that is somewhat messed up but can be improved in the long run however, ICANN would need some changes. The technical community has also shown its concern that it doesn't want the IANA technical and policy function to fall into the hands of the whims of governments because it functions to the technical community's needs adequately in its present environment and role. Your challenge and for the ICG is to propose that most transparent and accountable way forward that ensures an open and inclusive relationship with the Internet community treating stakeholders in their respective roles but not giving preference to one group over another another. I don't have to go through the Internet Governance ideals over and over again here. First ICANN Board control as the final word for IANA affairs would have to be reviewed and should be taken into a broader community review process. I do not trust the ICANN Board to be able to manage both ICANN and IANA in a transparent and accountable way, their progress over the years has had its own set of troubles already. The proposals are interesting but not the final word. The final word will remain with NTIA and thats my concern from a developing country member citizen perspective. I am going through a great deal of suggestions and proposals and all show a similar aspect, don't disturb the IANA technical function and the policies for IANA developed by the community have work so far but require more transparency, accountability and functional relationships with the community ensuring open and inclusive participation in its policy development processes. On Thu, Oct 23, 2014 at 7:27 PM, Seun Ojedeji <seun.ojedeji(a)gmail.com> wrote: > +1 Option 2 is preferred from my end also. However i also added Option 4 > as a second preference just incase things get delayed with the > accountability process. > > Cheers! > > On Thu, Oct 23, 2014 at 3:15 PM, Olivier MJ Crepin-Leblond <ocl(a)gih.com> > wrote: > >> Hello all, >> >> you might wish to see an expanded set of "Options", in a Google Doc which >> has been shared. >> >> >> https://docs.google.com/document/d/1B46mlsyZUFF4bZfeWgGCdqIQHCP2BMOy4KZU4Ri… >> >> So far, I note that the majority of our participants on the At-Large IANA >> Issues WG appears to prefer Option 2. >> >> Kind regards, >> >> Olivier >> >> >> >> On 15/10/2014 22:55, Olivier MJ Crepin-Leblond wrote: >> >> FYI >> >> >> -------- Forwarded Message -------- Subject: [CWG-Stewardship] Names >> Community vs the other two communities Date: Thu, 16 Oct 2014 02:40:47 >> +0530 From: Guru Acharya <gurcharya(a)gmail.com> <gurcharya(a)gmail.com> To: >> cwg-stewardship(a)icann.org >> >> How the names community approach will differ from the approach adopted >> by the numbers community and protocols community? >> >> Numbers Community: APNIC has reached consensus on its proposal. >> According to the proposal, IANA will continue to reside in ICANN. It >> proposes to replace NTIA oversight with a Service Level Agreement (SLA) and >> Affirmation of Commitment (AOC) between NRO and ICANN. >> www.slideshare.net/fullscreen/apnic/report-ianatransition/1 >> >> Protocols Community: The IETF draft proposal suggests that no >> structural changes are required as a result of the transition. The MOU >> between ICANN and the IETF community will continue to govern the existing >> relationship. Again, IANA will continue to reside in ICANN. >> http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-00 >> >> Therefore, neither the numbers community, nor the protocol community >> appear to be in the direction of suggesting a new MS Oversight Entity to >> replace NTIA and its oversight. Merely contracts between existing entities >> will be updated to replace NTIA oversight. >> >> Can the names community adopt a similar approach? Can a contractual >> agreement (SLA/AOC/MOU) between ICANN and GNSO/CCNSO be expected to replace >> NTIA oversight? >> >> Clearly NO! This approach can not be adopted by the names community >> because the names community resides within ICANN, which is also the IANA >> operator. Specifically, GNSO and CCNSO are essentially subsets of ICANN, >> and therefore a contractual agreement (SLA/AOC/MOU) between ICANN and >> GNSO/CCNSO can not be expected to replace NTIA oversight. >> >> Therefore, it is essential to either >> >> Option (i): create a new legal entity, which has a contractual >> oversight relationship with ICANN. This would be similar toÂ >> http://www.internetgovernance.org/2014/08/04/students-school-faculty-on-ian… >> >> Option (ii): expect ICANN to self-regulate >> >> Option (iii): make a new legal entity comprising of CCNSO and GNSO that >> is structurally independent of ICANN and require that new entity to enter >> into a contractual oversight agreement (SLA/AOC/MOU) with ICANN. >> >> From the above three options, clearly option (ii) is not acceptable >> because of the lack of trust in the ICANN enhanced accountability process. >> >> I also feel that option (iii) is not feasible because the CCNSO and >> GNSO are heavily integrated with ICANN and structural separation of these >> two communities from ICANN will be in-feasible. >> >> Also, from the Jordan Carter document, the option on page 7 can be >> discarded, which makes ICANN the oversight body, as IANA will continue to >> reside in ICANN, as clearly suggested by the proposals of the protocols and >> numbers community. >> >> Therefore, option (i) is clearly the only option available with the >> names community. >> >> Regards, >> Acharya >> >> >> >> >> >> _______________________________________________ >> Iana-issues mailing listIana-issues@atlarge-lists.icann.orghttps://mm.icann.org/mailman/listinfo/iana-issues >> >> >> -- >> Olivier MJ Crépin-Leblond, PhDhttp://www.gih.com/ocl.html >> >> >> _______________________________________________ >> Iana-issues mailing list >> Iana-issues(a)atlarge-lists.icann.org >> https://mm.icann.org/mailman/listinfo/iana-issues >> >> > > > -- > ------------------------------------------------------------------------ > > > > > > *Seun Ojedeji,Federal University Oye-Ekitiweb: > http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt > email: <http://goog_1872880453>seun.ojedeji(a)fuoye.edu.ng > <seun.ojedeji(a)fuoye.edu.ng>* > > The key to understanding is humility - my view ! > > > > _______________________________________________ > Iana-issues mailing list > Iana-issues(a)atlarge-lists.icann.org > https://mm.icann.org/mailman/listinfo/iana-issues > > -- Regards. -------------------------- Fouad Bajwa ICT4D and Internet Governance Advisor My Blog: Internet's Governance: http://internetsgovernance.blogspot.com/ Follow my Tweets: http://twitter.com/fouadbajwa

34 129

Proposed Agenda for Tuesday, 4 November Meeting (14:00-16:00 UTC)
by Grace Abuhamad Oct. 31, 2014

Oct. 31, 2014

Hi all, Please see below the proposed agenda for our 5th meeting: 1. Welcome & Roll Call 2. Notes from last meeting & Review of action items 3. Second reading of Principles 4. Third reading for Proposal on how to structure the work 5. Summary of discussions to date in relation to sub-group 3 to serve as a starting point 6. Status on work subgroups 7. Any other business 8. Summary of action items and agreed item

2 1

Rapporteur and or coordinator for the sub-groups
by Lise Fuhr Oct. 31, 2014

Oct. 31, 2014

Dear All, I am sorry to trouble you once more. But as discussed today during the call the sub-groups can decide whatever administrative mechanisms they feel serves them best. Sub-groups 1, 2A, 2B, 2C,3A, 3B have to report who their rapporteurs and/or coordinators are by the end of this week - Friday, October 31. Each group can report their rapporteurs and coordinators to Grace. Best regards, Lise

2 1

Schedule for Upcoming Calls
by Grace Abuhamad Oct. 31, 2014

Oct. 31, 2014

Hi all, I have been asked to post a schedule of upcoming calls so that the CWG members/participants can plan ahead with their scheduling. Here is a draft list of upcoming meetings through the end of 2014: * Tuesday, 4 November at 14:00 16:00 UTC (meeting 5) * Thursday, 13 November at 14:00 16:00 UTC (meeting 6) * F2F 2 full days 19 20 November (meeting 7) * TENTATIVE: Thursday, 27 November 11:00 13:00 UTC (meeting 8) * TENTATIVE: Thursday, 4 December 14:00 16:00 UTC (meeting 9) * TENTATIVE: Thursday, 11 December 11:00 13:00 UTC (meeting 10) * TENTATIVE: Thursday, 18 December 14:00 16:00 UTC (meeting 11) You will note that I have modified the UTC alternating times by an hour this is to accommodate the US-based members/participants who have Daylight Savings Time starting in November. Have a good weekend and talk to you on Tuesday, Grace

1 0

Re: [CWG-Stewardship] TIME TO GET GOING RPC GROUP III
by Grace Abuhamad Oct. 31, 2014

Oct. 31, 2014

Hi Allan, I'm no Marika, but I can provide the answer to your first point. We have checked with our web team internally and the Wiki was the suggested tool. We created sub-team sections in the Wiki for that purpose, and could of course adjust them to what best suits the group for collaborative work. The other option would be something like Google Docs, which I could support you in, but is not a platform supported by the ICANN web team. From: Allan MacGillivray <allan.macgillivray(a)cira.ca> Date: Thursday, October 30, 2014 2:37 PM To: "cwg-stewardship(a)icann.org" <cwg-stewardship(a)icann.org> Subject: [CWG-Stewardship] TIME TO GET GOING RPC GROUP III Colleagues we are quickly running out of time, Group III has to get its act together, and quickly. This is what I think we need right away: 1. A platform for collaboration We need a place specific proposals can be uploaded which has the capability of capturing the comments of the community all in one place. Marika can you suggest something. My fear is that a lot of what is being said on the list will have to be repeated Marika can you suggest something? 2. A common understanding of what we are trying to achieve. Many of the ideas that are being floated may be based on differing assumptions as to the objective. This has to be a priority for putting up in our collaboration space¹ 3. Specific Proposals from Group III participants We need fleshed out proposals that can be reviewed and commented on in a structured manner. I propose that we use a simple pro and con¹ approach. 4. Someone to call the first meeting Whoever you are, you will likely end up as the rapporteur/coordinator unless you can convince someone else to do it but unless someone volunteers, we will not accomplish anything

7 7

Notes and action items from today's meeting
by Marika Konings Oct. 31, 2014

Oct. 31, 2014

Dear All, Please find attached the notes and action items of today¹s meeting. As a reminder, the action items are: * #1 - Each sub-group should appoint a rapporteur for purposes of bringing output back to full CWG as well as a co-ordinator who will be responsible for moving the work of the sub-group forward. Each sub-group should discuss whether the role of rapporteur and co-ordinator should be filled by one and the same person or whether these roles should be split between two people. * #2 - All encouraged to review the revised principles that were circulated on the mailing list and provide input. * #3 - Staff to capture discussions to date in relation to sub-group 3 to serve as a starting point * #4 - Staff to create a new mailing list for sub-group 3 but with all WG members and participants subscribed to this list The recording, transcript and materials from today¹s meeting will be available here shortly: https://community.icann.org/x/qSrxAg. The next meeting has been scheduled for Tuesday 4 November from 14.00 16.00 UTC. Best regards, Marika

5 6

Work break down RFPIII
by Lise Fuhr Oct. 30, 2014

Oct. 30, 2014

Dear All, The objective is to finalize the work breakdown structure at our next meeting. An issue arose at our meeting today: · Breaking up CWG-RFP3 into 3A and 3B as presented: A. Contract Manager for the IANA Functions contractor B. Root Zone Management. Although there were some objections on the list prior to the call there were none voiced during the call and I concluded that we should keep this separation at least until our next meeting. The main reason for this is that the SSAC68 report identifies two very distinct functions performed by the NTIA in IANA Functions oversight and accountability and this group is in charge of identifying how to best transition both. If you have any comments please post these to the list prior to our next meeting on November 4. Thank You Best regards. Lise

2 2

TIME TO GET GOING RPC GROUP III
by Allan MacGillivray Oct. 30, 2014

Oct. 30, 2014

Colleagues - we are quickly running out of time, Group III has to get its act together, and quickly. This is what I think we need right away: 1. A platform for collaboration We need a place specific proposals can be uploaded which has the capability of capturing the comments of the community all in one place. Marika - can you suggest something. My fear is that a lot of what is being said on the list will have to be repeated Marika - can you suggest something? 2. A common understanding of what we are trying to achieve. Many of the ideas that are being floated may be based on differing assumptions as to the objective. This has to be a priority for putting up in our 'collaboration space' 3. Specific Proposals from Group III participants We need fleshed out proposals that can be reviewed and commented on in a structured manner. I propose that we use a simple 'pro and con' approach. 4. Someone to call the first meeting Whoever you are, you will likely end up as the rapporteur/coordinator unless you can convince someone else to do it but unless someone volunteers, we will not accomplish anything

1 0

FW: Responding to Olivier
by Grace Abuhamad Oct. 30, 2014

Oct. 30, 2014

Forwarding Becky's message below since it was sent to the "bounce" address by mistake. From: "Burr, Becky" <Becky.Burr(a)neustar.biz> Date: Wednesday, October 29, 2014 1:38 PM To: "cwg-stewardship-bounces(a)icann.org" <cwg-stewardship-bounces(a)icann.org> Subject: Responding to Olivier Olivier, Thanks for this input. I¹d like to take a step back so that we are all on the same page. I hope everyone with take the time to review this post. I think we are making this work unnecessarily complicated. Under the straw man I¹ve suggested the ³Council² or ³Body² or whatever it is called is responsible for negotiating and interacting with IANA on technical issues. As defined by the IANA functions contract, IANA¹s naming-related tasks include the following: Root ZoneFile Change Request ManagementThe Contractor shall receive and process root zone filechange requests for TLDs as expeditiously as possible. This does not include a policy role at all. A new TLD is entered into the root only after the ICANN Board directs IANA to do that. Policy remains in ICANN, not the IANA function. Root Zone ³WHOIS² Change Request and Database Management The Contractor shall maintain, update, and make publicly accessible a Root Zone ³WHOIS² database with current and verified contact information for all TLD registry operators. Again, this involves no policy role. ICANN makes policy on WHOIS, not IANA. IANA just follows ICANN¹s orders. Delegation and Redelegation of Generic TLDs and Country Code TLDs. Again, the role is administrative and not policy making. IANA adds or removes a TLD from the root only at the direction of the ICANN Board. It is responsible for documenting that the action was consistent with established ICANN policy, but has no role in formulating that policy. Root ZoneAutomation--The Contractor shall work with NTIAand the Root Zone Maintainer, and collaborate with all interested and affected parties to deploy afully automated root zone managements system. This is an administrative/operations task, not a policy task. Root Domain Name System Security Extensions (DNSSEC) KeyManagementThe Contractor shall beresponsible forthe management ofthe root zone KeySigning Key (KSK), including generation, publication, and use for signing the Root Key set. Again, DNSSEC policy is set by ICANN, informed by all stakeholders, the SSAC, etc. IANA simply administers the ICANN policy. Customer Service Complaint Resolution Process (CSCRP)The Contractor shall work with NTIA and collaborate with all interested and affected parties to establish and implement a process for IANA function customers to submit complaints for timely resolution that follows industry best practice a and includes a reasonable time frame for resolution. This relates to complaints about IANA doing its technical job in a timely and competent fashion, not policy, which remains with ICANN. Perform Administrative Functions Associated WithRoot Zone Management. Facilitate andcoordinate the root zoneof the domain name system, andmaintain24hour-a-day/7days-a-weekoperationalcoverage. I would agree with you that a conflict of interest could emerge if IANA was developing policies for the registries, but that is not what¹s being proposed. Rather, all policy work would remain with ICANN subject to multi-stakeholder processes just as it is now. What conflict of interest arises in this situation? Registries will be in the best position to know whether or not IANA is processing name server changes in a timely fashion. Registries are harmed if it takes forever to do that. To the limited extent this kind of thing might impact end users, registries have all of the necessary incentives to get it fixed. In the early years of ICANN, when IANA was performing very poorly, registries were unhappy, but most of the rest of the ICANN community was not impacted in any way. Today, the ICANN board - NOT IANA - promises stakeholders that IANA will do its work in accordance with ICANN policy. If it doesn't, I am going to look to the ICANN Board and not the IANA staff for redress. I don¹t see a conflict of interest in registries performing an oversight role with respect to IANA¹s purely technical and operational functions. Remember, the IANA function contract specifies that IANA¹s role is technical and operational, not policy development. If IANA does something that is inconsistent with ICANN policy, I want the ICANN Board to be accountable. Again, to be clear, I am not unalterably opposed to having other parts of the community participate, but I don¹t understand why they would want to. Becky J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr(a)neustar.biz / www.neustar.biz

13 14