June 2015 - CWG-Stewardship

Agenda for the CWG-Stewardship working session at ICANN53
by Grace Abuhamad June 24, 2015

June 24, 2015

Dear all, We have a working session at ICANN53. The information for this session is available here: https://buenosaires53.icann.org/en/schedule/thu-cwg-stewardship The agenda is as follows: 1. Opening Remarks 2. Approval from chartering organizations 3. Future work of the CWG-Stewardship > 1. pre-submission to NTIA > 2. post-submission to NTIA 4. Response to letter from ICG (on trademark) 5. Future coordination > 1. ICG > 2. CRISP > 3. IANAPLAN > 4. CCWG-Accountability 6. AOB For remote participants, Brenda will send a reminder with call details and the Adobe Connect room. Best, Grace

1 0

ICG request concerning IANA trademark and iana.org domain name
by Alissa Cooper (alcoop) June 24, 2015

June 24, 2015

Dear CWG, The CWG transition proposal suggests that "ICANN will grants [sic] PTI an exclusive, royalty-free, fully-paid, worldwide license to use the IANA trademark and all related trademarks in connection with PTI's activities under the ICANN-PTI Contract." [1] Our understanding is that this text was not a product of full CWG deliberation and consensus and is flagged as subject to further negotiations. During the ICG face-to-face meeting #5 on June 18 this text was identified as causing an incompatibility between the three operational community proposals. Both the IETF and RIR communities have been using and continue to use the term "IANA." For instance, the term has been cited in 3,353 RFCs over several decades. The CWG’s proposal for ICANN to grant an exclusive license may not be compatible with all three communities making continued use of the term. Second, the RIR community has specified in its proposal that the IANA trademark and domain name [2] should be transferred to an entity independent of any IANA Numbering Services Operator. In February 2015, the ICG asked the RIR and IETF communities to report if their proposals can be made compatible in this regard. After discussion these communities reported back that there was no fundamental discrepancy. [3, 4] The IETF Trust also indicated its willingness to hold intellectual property rights relating to the IANA functions and the IETF community expressed its willingness to support such a decision. [3] Finally, the current text discusses only the trademarks and not the iana.org domain name. Thus it is unclear whether the CWG proposal text is meant to extend to the domain name as well. The ICG has identified this topic as something that requires coordination between the communities. The ICG would like to request that in completing its proposal the CWG review the proposals from the protocol parameters and numbers communities, determine if it can adopt an approach taken by those communities, and if not, work together with the protocol parameters and numbers communities to reconcile the incompatibilities that have been identified. The ICG requests that the CWG communicate back to us a proposed resolution to this issue by July 2 at 23:59 UTC. Thank you, Alissa, Patrik and Mohamed on behalf of the ICG [1] CWG Stewardship proposal, Annex S, page 132 [2] Numbers community proposal, page 10: "With regards to the IANA trademark and the IANA.ORG domain, it is the expectation of the Internet Number Community that both are associated with the IANA Numbering Services and not with a particular IANA Numbering Services Operator. Identifying an organization that is not the IANA Numbering Services Operator and which will permanently hold these assets will facilitate a smooth transition should another operator (or operators) be selected in the future. It is the preference of the Internet Number Community that the IANA trademark and the IANA.ORG domain name be transferred to an entity independent of the IANA Numbering Services Operator, in order to ensure that these assets are used in a non-discriminatory manner for the benefit of the entire community. From the Internet Number Community's perspective, the IETF Trust would be an acceptable candidate for this role. The transfer of the IANA trademark and IANA.ORG domain to the IETF Trust will require additional coordination with the other affected communities of the IANA Services, namely, protocol parameters and names. It is the preference of the Internet Number Community that all relevant parties agree to these expectations as part of the transition." [3] http://mm.icann.org/pipermail/internal-cg/2015-February/003103.html [4] http://mm.icann.org/pipermail/internal-cg/2015-February/003105.html

13 31

Fwd: [DTA - SLE] Questions and Answers - Revised
by Paul M Kane - CWG June 24, 2015

June 24, 2015

Dear CWG members, Jay Daley (.NZ) has prepared some excellent Q&A to update the community on the work of the SLE Working Group which may be of interest. Rest assured we are trying to progress the drafting of the SLE which should be concluded in the next few weeks so ICANN / IANA has a framework for monitoring their systems as part of the Implementation Phase. Kind regards Paul ----- Forwarded message from Jay Daley <jay(a)nzrs.net.nz> ----- Date: Mon, 22 Jun 2015 15:29:26 -0300 From: Jay Daley <jay(a)nzrs.net.nz> Reply-To: Jay Daley <jay(a)nzrs.net.nz> Subject: [DTA - SLE] Questions and Answers - Revised To: dt1(a)icann.org I had some feedback on my initial Q&As so Iâve updated them below. The changes are about a) The IANA system development; b) The plan for more data capture to inform the performance targets; c) the next steps. Now that Iâve had some feedback, I was planning to share these later today with a few people who are involved in CWG-Stewardship and who are concerned about our progress - please let me know if this is an issue. Jay Q: Why has there been so little open discussion by DT-A on the mailing list? It all looks very secretive? A: We began work some time before a DT-A mailing list was established and by the time it was, a lot of work on drafting had already taken place. Soon after the list was established the issue of how IANA would be involved was resolved with the full engagement from the IANA staff, and it was felt that direct conversations with IANA were the best way to take advantage of that rather than slow conversations on the list. In order to engage fully IANA had to get assemble a series of documents that detail their internal processes and then get permission from the NTIA to release them. Altogether this process took a long time. Q: What involvement has ICANN/IANA had and how committed are they to this? A: Initially it appeared to us that ICANN was only going to engage at a senior executive level to insist that the SLA stays unchanged from that in place currently. This was not acceptable to the DT-A team as we regard the current NTIA approved SLA as well below the minimum SLA required for a service of such global importance. Fortunately IANA staff are now involved and they are fully committed to a proper SLA that serves the need of customers and drives internal improvements. It is useful to note that an SLE (Service Level Expectation) is generally set by customers alone, whereas with this full engagement from IANA it is possible for us to agree an SLA (Service Level Agreement) which is equally supported by both customers and the providers. Q: Does the DT-A team have an agenda here, such as forcing through the automation of IANA? A: No. The team has taken the view from the outset that it is not our role to change the processes in any way. IANA have already started a process of automation of some elements of their service, as presented at various ICANN meetings, and we are trying to keep up with that but we are not introducing any agenda of our own. Q: What is the general plan for the SLA? A: Conceptually it breaks down into three parts: 1. A full service definition with each service broken down into constituent processes and stages within those processes that require individual measurement. 2. An initial set of performance targets. 3. An initial set of breach thresholds - a percentage of requests that must meet the performance target or IANA is in breach of the SLA. A set of principles has been developed to guide the work on these three parts. Q: What is being measured? A: Both time to complete a request (broken down by stage) and the accuracy of the work completed. For some processes, such as nameserver changes, the accuracy needs to be 100% but for others a lower standard is acceptable. Q: Is all that measurement necessary? A: It is the clear consensus view of DT-A that without this level of measurement it is not possible to define an SLA nor is it possible to ensure that an SLA meets the needs of the customer. The breakdown into stages of processes has been chosen to reflect the different responsibilities for those stages and the different nature of those stages. For example, if IANA ask for more information about a root change then the clock needs to stop and the responsibility for progressing that request transfers from IANA to the requestor. This level of measurement is vital to resolve, once and for all, two different perceptions that people have of IANA performance: - that IANA operates a two-tier SLA with contracted TLDs receiving a faster service than non-contracted TLDs while both are still within the overall SLA. - that IANA is the primary cause of delays. By specifying stages where the clock stops when responsibility transfers, this ensures an accurate measurement of IANA performance. Q: How were the initial performance targets set? A: It is important to note that no targets have yet been set. Some targets were initially proposed based on analysis of previous IANA performance (the full data set used for the analysis is available) but we have agreed with IANA that we need more data and are hoping for 2-3 months of data capture from IANA. The key takeaway is that the performance targets in current NTIA SLA are far looser than we as customers believe they should be and IANA as the operator clearly recognises this because it is over-performing by so much. Q: Has work been done to ensure that these targets match the importance of the processes and are not arbitrary? Isnât there a problem that if we use current performance then IANA needs to establish a base line even higher to ensure that they never breach those targets? A: The answers are yes the work has been done and no there isnât a problem. These issues are addressed by the use of breach levels, which work in conjunction with the performance targets. For example a performance target might be set for a specific type of customers request at 5 days based on evidential analysis, but the breach threshold might be set at 90%, which means that only 90% of requests of this type need to meet the 5 day target. This breach threshold serves a dual purpose: - It provides headroom for IANA above the target by allowing them to ignore the worst performing requests. - This level of headroom given reflects the customer priority of this type of request. Q: Once these targets are set are they fixed in stone? A: No, these are an initial set of targets and it is expected that they will develop over time in two ways: - ongoing process improvement by IANA leading to improvements in performance - better consultation with customers to understand our priorities better, leading to adjustments in targets to reflect that Q: How important is it that these elements are in place before transition? A: The view of the DT-A team is that a full SLE/SLA needs to be in place by the start of the transition however IANA have noted that there are some pre-requisites that must be met before they can implement it. These are: 1. The current IT system needs to have features added to extract the required measurements. This development can only begin once there is certainty that this transition is going ahead on this basis and IANA can only turn those changes on after transition given the nature of their agreement with the NTIA. It should also be remembered that IANA will need to make a case for development resources to the ICANN executive team as IANA has no development resources of its own. 2. IANA staff will need time to adapt to the changes in their working practices to implement this measurement. Q: When will the DT-A be finished? A: We are close to completing the SLA except the actual performance targets. These will be added later after a data collection period and discussion with IANA. -- Jay Daley Chief Executive NZRS Ltd desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley _______________________________________________ dt1 mailing list dt1(a)icann.org https://mm.icann.org/mailman/listinfo/dt1 ----- End forwarded message -----

3 2

Charter interpretation
by Seun Ojedeji June 23, 2015

June 23, 2015

Dear Co-Chairs, all Re-reading the CWG charter, I like to get some clarification/correction on my interpretation of the CWG charter. Sections below: *Final Transition Proposal * > After receiving the notifications from all chartering organizations as > described above, the co-chairs of the WG shall, within ten working days > after receiving the last notification, submit the Final Transition Proposal > to the Chairs of all the chartering organizations..............In the event > one or more of the chartering organizations do(es) not support (parts of) > the Final Proposal, the Final Proposal should clearly indicate which parts > are fully supported and which parts that are not, and which chartering > organization dissents from the CWG view. > In the event that no consensus is reached by the CWG, the Final Report will document the process that was > followed and will be submitted to the chartering > organizations to request possible suggestions for mitigating the issues > that are preventing consensus...... Based on the section above, i like to get response/confirmation on the following assumption: - That the current proposal is final "draft" of the CWG - That the CWG would reconvene to update the curent draft based on response from the chartering organisation. - That another consensus call will still be made by the CWG to produce a final proposal to be submited Regards -- ------------------------------------------------------------------------ *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 !

3 5

Fwd: Re: [Ianaplan] ICG request concerning IANA trademark and iana.org domain name
by Seun Ojedeji June 22, 2015

June 22, 2015

Hi, I think this is a good summary on IANA trademark that could be interest. Please pay attention to the last paragraph. Regards sent from Google nexus 4 kindly excuse brevity and typos. ---------- Forwarded message ---------- From: "John C Klensin" <john-ietf(a)jck.com> Date: 22 Jun 2015 19:21 Subject: Re: [Ianaplan] [CWG-Stewardship] ICG request concerning IANA trademark and iana.org domain name To: "Mwendwa Kivuva" <Kivuva(a)transworldafrica.com> Cc: <ianaplan(a)ietf.org> --On Monday, June 22, 2015 16:54 -0300 Mwendwa Kivuva <Kivuva(a)transworldafrica.com> wrote: >... > Today I asked to Greg Shetan, Chair Intellectual Property > Community at ICANN on what he thought on the request to > transfer the Intellectual Propert out of ICANN. His view was > we should look at trademark law and take the direction that > works well for all parties. His Personal view was the IANA > Function Operator should hold these trademarks. I hope I have > not misquoted him. Hi. I think this illustrates the principle that the answer to questions often depends on exactly what question one asks. Let's review how we got here and please pass this note onto Mr. Shatan. Today, the IANA Function Operator is ICANN so, by the advice above, the right party has the trademarks. However, various parts of the community have gotten concerned that ICANN might use the ownership of the trademarks to prevent, or set conditions on, all or part of the IANA Function from being turned over to some separate operator. As I understand it, the NTIA, under the current contract, would not allow the trademark or domain name the IANA Function to be transferred to a separate operator without the trademarks, domain names, and, incidentally, the contents of various registries going along with it. So, unless other arrangements can be found that make sure that any transfer of the IANA function occur with the full support of the outgoing incumbent and take any IPR, including the trademark and domain name with it as part of the deal (and assuming the trademark, etc., really are important), "the name should be held by the IANA Function Operator" could turn out to be a guarantee that an incumbent IANA Function Operator could hold onto that role as long as it liked, dictating whatever conditions it liked. The following summary is crude, but, AFAICT, the position of the communities so far is: IETF: At least for us, the trademark and domain name are not nearly as important as some parties believe. Beyond that, ICANN has been well-behaved in this particular area, we really don't believe that is likely to change (implying that, should there need to be a change in the IANA Functions Operator, ICANN would cooperate in transferring the names rather than trying to dig in and hold onto them as a negotiating point even though that would cause significant inconvenience and perhaps damage to Internet security and stability), and putting a lot of energy into this issue isn't worth it. The IETF does, however, have a handy structure that holds various intellectual property assets in trust for the broad Internet community. That structure has a very good track record and, if the other communities involved see a need to transfer the trademarks and domain names out of ICANN (presumably because of lack of trust in ICANN future good behavior), we would be willing to hold those assets too. RIRs: apparently see somewhat more risk than the IETF does (perhaps because the IETF believes it is in a better position to just walk away if things got really bad) and would prefer to see the trademark and domain names transferred to the IETF Trust to administer on behalf of the broader community. CWG: Sees creating PTI, transferring the domain name and trademarks to it, for exclusive use, and setting up a detailed set of licensing arrangements that best solution to the problem. If that mischaracterizes the position, please explain. Otherwise (personal option only, but one informed by working with IANA and on IANA policies long before anyone dreamed of ICANN and having been somewhat involved with the IANA transition to ICANN and the first few rounds of this discussion): PTI is an interesting idea. It it were the IANA Function Operator, the above answer to your question suggests that it should hold the trademarks, etc. However, as long as it is ICANN-controlled, its holding the trademarks does not, by itself, provide any protection against the trademarks being used as leverage to prevent moving the function away from ICANN (and its subsidiaries and affiliates) entirely. So, ignoring any other issues associated with PTI, if the concern is that the trademarks not be used to restrict either the reasonable behavior of the IANA "customers" or the ability to remove the IANA function entirely from ICANN's scope and assign it, intact and without a great deal of strife, to some other entity, the PTI model just doesn't help. Two additional comments: One of the things I understood Larry Strickling to say yesterday afternoon is that the focus of the transition effort should be on transition requirements and that it would probably be good if various parts of the community avoiding using "transition" as an excuse to engage in overall ICANN reform and reorganization. I can see several motivations for PTI if we were trying, again, to reform and reorganize ICANN, but, if that it not the goal, then the odds of success in getting a transition plan completed and approved seem to me to be much higher if we keep this simple rather than trying to create new organization elements and then trying to sort of the relationships between them and everyone/ everything else. Again, just my opinion, but.... Also, with no disrespect to anyone involved, if you came to people who were spending a very large fraction of their lives on IETF protocol work and asked "is Internet protocol work important?", it is unlikely that you would get many negative answers. Asking someone involved as staff or a Board or Advisory Committee member whether a well-managed and fairly allocated Internet address space is important would also be unlikely to get a negative answer. Similarly, if I asked an actively practicing Intellectual Property lawyer if trademarks are important, I would certainly expect a "yes" answer and be surprised if I got anything else. That doesn't make any of those "yes, it is important" answers wrong -- they are probably correct -- it just makes the answers sufficiently close to obvious to make the questions barely worth asking. best, john _______________________________________________ Ianaplan mailing list Ianaplan(a)ietf.org https://www.ietf.org/mailman/listinfo/ianaplan

1 0

FW: [Ianaplan] ICG request concerning IANA trademark and iana.org domain name
by Milton L Mueller June 22, 2015

June 22, 2015

Here is another relevant fact From: Ianaplan [mailto:ianaplan-bounces@ietf.org] On Behalf Of John Curran Sent: Monday, June 22, 2015 11:41 AM Subject: Re: [Ianaplan] [CWG-Stewardship] ICG request concerning IANA trademark and iana.org domain name On Jun 22, 2015, at 10:03 AM, John Curran <jcurran(a)istaff.org<mailto:jcurran@istaff.org>> wrote: The marks are with ICANN simply because it was more appropriate that ICANN (as the IANA contractor upon formation) take on responsibility for any effort and costs associated with maintenance or enforcement of the intellectual property… USG explicitly recognized the transfer from USC-ISI to ICANN in order to facilitate this maintenance, given that ICANN was being formed to take on in a more formal manner the duties that Jon (et al) had been doing previously. I was asked by folks for the reference for this event, so here it is: ICANN’s "Proposal to the U.S. Government to Perform the IANA Function" <https://archive.icann.org/en/general/iana-proposal-02feb00.htm#IA2b>, page 4 "Governmental Approval of USC-ISI's Transfer of Intellectual Property to ICANN” - Effectively states that while not necessary for performance of the duties, it is more appropriate that the new operator ICANN take responsibility for any effort or costs associated with maintenance or enforcement of the intellectual property, hence the transfer. FYI, /John

1 0

FW: [Ianaplan] Fwd: ICG request concerning IANA trademark and iana.org domain name
by Milton L Mueller June 22, 2015

June 22, 2015

Here's a good message from the IANAPLAN list of the IETF related to the trademark and domain issue: -----Original Message----- From: Ianaplan [mailto:ianaplan-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Monday, June 22, 2015 10:07 AM Subject: Re: [Ianaplan] Fwd: [CWG-Stewardship] ICG request concerning IANA trademark and iana.org domain name The current model is to have ICANN be viewed as a contractor for IANA services. Remarkably, this view seems to be held by more than one of the affected communities. I say remarkably because getting alignment on strategic issues, between entities like the IETF and the RIRs seems unusual to me. In any event, contractors should not 'own' resources that properly belong to the those contracting with them. More generally, an arrangement with a contractor should be devised so as to facilitate possible transfer of the contracting relationship to a different provider. Any arrangement which 'defers' basic matters of control until the termination phase is inviting transfer problems. By 'inviting' I mean that it is guaranteeing there will be serious problems. My plan is that we do the normal and reasonable and responsible work of anticipating the transfer now, rather than taking an escapist stance that what we arrange now doesn't matter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ianaplan mailing list Ianaplan(a)ietf.org https://www.ietf.org/mailman/listinfo/ianaplan

1 0

New blogs on ICANN website
by Grace Abuhamad June 21, 2015

June 21, 2015

Dear all, Here are some blogs released in the past week that may be of interest to you: * 16 June Continuing alignment: working together towards a new stewardship and enhanced accountability: https://www.icann.org/news/blog/continuing-alignment-working-together-toward s-a-new-stewardship-and-enhanced-accountability * 19 June Your guide to IANA Stewardship/Accountability at ICANN53: https://www.icann.org/news/blog/your-guide-to-iana-stewardship-accountabilit y-at-icann-53. * 20 June New IANA Functions Resource Published: https://www.icann.org/news/blog/new-iana-functions-resource-published Best, Grace

2 1

Feedback on First Webinar
by Olivier MJ Crepin-Leblond June 17, 2015

June 17, 2015

Hello all, First, thanks to Lise for taking us through the slide deck and making a complex proposal a lot more understandable. Now for my comments: - We have spent again around 30 minutes on the process reaching this point and a much smaller time on the contents of the proposal itself. I think that by this stage we should have a lot more detail in the actual explanation of the contents of the proposal, describing CSC, IFR, the PTI Board, SCWG, the escalation process (there is no slide showing all of the various levels of escalation and remedials) from the time a complaint starts and the various levels at which the complaint can be addressed. IMHO *this* should be the meat of the presentation. - Questions like "what happens to PTI if another IANA Functions Operator is selected after separation?" are bound to come up recurrently and we completely forgot to mention that this is just the Names and the Protocols & Numbers will likely remain with PTI through their contract with ICANN. This is not made clear at all that an IFR is only to do with Names. - We did not emphasize the technical nature of the whole ecosystem and it therefore feels like a lot of these processes are political - and this is not inspiring confidence. Emphasis on Service Level Expectations; emphasis on Operational Continuity; emphasis on Stability of the DNS. How are all of the processes and groups proposed contributing to this emphasis? I hope this helps. Kind regards, Olivier

9 11

A blog from NTIA
by Avri Doria June 17, 2015

June 17, 2015

http://www.ntia.doc.gov/blog/2015/stakeholder-proposals-come-together-icann… --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0