<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">All,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Below are my comments and questions on the "Example Principal Terms."</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">There are over-arching issues raised by the DT-IPR draft principles about the structure of any new owner of the IPR that are not addressed here. Particularly, we need to determine whether an entity controlled by IETF's administrative group with the IETF as its sole beneficiary is an appropriate home for a resource shared among the three operating communities? Should any entity holding the IPR ultimately be controlled by all 3 communities? Would a shared, purpose-built trust be more appropriate in the long run for holding the IPR, rather than using an entity built for another purpose?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">We need to address those issues first.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Once we get past those questions, many of the ideas below are agnostic, i.e., they would be adopted in any scenario. I would include the agreement transferring the IPR to the new owner, and licenses from the new owner to the IFO(s) in that category. I would not include the "community assurance agreements" in that category -- I see those as the weakest possible way of controlling any new owner and holding it accountable.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Greg</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><b><font size="4">Example Principal Terms of Intellectual Property Agreements<br></font></b> <br>This draft relates to a possible use of IETF Trust as an independent entity to hold IANA-related IPR. The IETF Trust is one of the discussed alternative holders of IPR.<br> <br>This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. The IETF Trust has provided this draft as a hopefully helpful initial contribution, but clearly discussion in the various communities and further work is needed. Comments are appreciated.<br><br><b>A. Background<br></b><br><div>The ICG proposal indicates that the IANA trademark and <a href="http://iana.org/" target="_blank">iana.org</a> domain should be transferred to an entity independent of the IANA Numbering Services Operator.</div></div></blockquote><div><br></div></span><div style="font-family:arial,sans-serif;font-size:12.8px"><font color="#0000ff"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">GSS: There are 3 trademarks, each separately registered with the US Patent & Trademark Office: "Internet Assigned Numbers Authority", "IANA" and the IANA logo (which, as registered, includes the phrase "Internet Assigned Numbers Authority"). There are also 3 domains -- <a href="http://iana.org/" target="_blank">iana.org</a>, <a href="http://iana.net/" target="_blank">iana.net</a>, and <a href="http://iana.com/" target="_blank">iana.com</a>. Presumably, all of these would be transferred away from ICANN to the trust. Can you confirm that is the intention?</div></font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><div><font color="#0000ff"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><br></div></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>The IETF Trust would be a potentially acceptable candidate for this role, and the Trust has discussed the implications of assuming this responsibility. The following is some background of the Trust’s position and an overview of how the role and responsibilities may be fulfilled.</div><div><br></div><div>While this fulfillment is a part of implementation rather than the ICG proposal, the IETF Trust wants to ensure progress on determining those implementation steps. The Trust is of course only one of the possible ways to satisfy the requirements from the ICG proposal. Nevertheless, the Trust wanted to start by suggesting an overall framework for one way of satisfying the requirements. </div><div><br></div><div>The IETF Trust is a Virginia USA private trust, the trustees of which are the members of the IETF Administrative Oversight Committee (IAOC), and the beneficiary of which is the IETF community. </div></div></blockquote><div><br></div></span><div style="font-family:arial,sans-serif;font-size:12.8px"><div class="gmail_default"><font color="#0000ff"><font face="verdana, sans-serif">GSS: Are you sure that the IETF Trust is a "private trust" and not a "public trust"? As I understand it, private trust is a trust created to benefit a particular named entity, person or set of persons. In contrast, a public trust (also known as a charitable trust) is created for a charitable purpose. </font> <font face="verdana, sans-serif">This is significant in understanding the nature of the IETF Trust, as well as the relationship between the beneficiary and the trust's assets.</font></font></div><div class="gmail_default" style="font-family:verdana,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:verdana,sans-serif"><font color="#0000ff">According to the IETF Trust Agreement (<a href="http://trustee.ietf.org/trust-agreement-2014.html" target="_blank">http://trustee.ietf.org/trust-agreement-2014.html</a>) the beneficiary of the IETF Trust is the IETF (rather than the IETF community), and the successor Beneficiary is "<span style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12.6667px;text-align:justify">the IETF's successor with respect to the development of technical standards for the Internet." As I understand it, the IETF is an "organized activity" of ISOC, and not a legal entity. Thus, in some sense, ISOC (as the legal entity) is the beneficiary of the IETF Trust. This is also significant in understanding the nature of the IETF Trust, since the beneficiary of a trust has unique rights, including rights with regard to the trust's assets. The beneficiary is also owed unique duties by the Trustees, particularly the duty to act in the interests of the beneficiary. </span></font></div></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">The purpose of the IETF Trust includes acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology.<div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"></div> </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div><b>B. Framework</b></div><div><br></div><div>The Trust believes it would need to enter into three different types of agreements to effect the transfer of the IANA intellectual property (IP) and to enter into licensing arrangements with the IANA service provider(s).</div><div><br></div><div>These agreements include:</div><div><br></div><div>1. An Agreement between ICANN and the IETF Trust transferring the IANA IP to the IETF Trust</div></div></blockquote><div> </div></span><div class="gmail_default" style="font-size:12.8px"><font color="#0000ff">GSS: I agree that an Assignment Agreement will be needed to transfer the IANA IPR to any future owner. (Note that the USPTO disregards trusts as trademark owners, so the owners of record would be the trustees (and would need to be updated when these change -- I note that the IETF Trust has neglected to do this with its own marks).)</font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and</div></div></blockquote><div><br></div></span><div class="gmail_default" style="font-size:12.8px"><font color="#0000ff">GSS: I am not familiar with this type of agreement. Is this a novel agreement, invented for this purpose? If not, it would be helpful to be pointed to information on this type of agreement. If these are novel, they could include almost anything; as such, their terms would be absolutely critical to the success of any set-up.</font></div><div class="gmail_default" style="font-size:12.8px"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-size:12.8px"><font color="#0000ff">More broadly, this is only one of several ways in which the OC's could relate to and control the actions of the trust. Although I appreciate this as one suggestion, it would be appropriate to consider the alternatives (especially since this alternative appears to be novel).</font></div><div class="gmail_default" style="font-size:12.8px"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-size:12.8px"><font color="#0000ff">Finally, the term "Assurance Agreement" is peculiar, and presumably intended to invoke a particular type of relationship. I would be curious to know more about this "assurance" relationship. I would probably call these "Community Control Agreements" -- but that would invoke a different type of relationship. This is not a semantic issue -- it's critical to know how the parties view their relationship to each other.</font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>3. Agreement(s) whereby the IETF Trust provides for the use of the <a href="http://iana.org/" target="_blank">iana.org</a> domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities.</div></div></blockquote><div><br></div></span><div style="font-family:arial,sans-serif;font-size:12.8px"><font color="#0000ff"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">GSS: I agree that a License Agreement (or License and Lease Agreement, or something similar) will be needed for any future owner to grant rights to use trademarks and domain names to the IANA Functions Operator(s) (or, in this email's terms, the "IANA service provider(s)").</div></font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>The Trust understands that each community would need to follow its own internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself.</div><div><br></div><div>The Community Assurance Agreements with the IANA communities would establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the IETF Trust to provide, update, and revoke licenses as needed to support these selections.</div></div></blockquote><div><br></div></span><div class="gmail_default" style="font-size:12.8px"><font color="#0000ff">GSS: The Community Assurance Agreements (and/or any other arrangements put in place) need to do more than this -- they need to establish how the OC's control the actions of the trust and how they hold the trust accountable (up to and including removal of trustees and transferring the IANA trademarks and domain names away from the trust if it is not acting in accordance with its obligations). As noted above, the IETF AOC also act as the Trustees of the IETF Trust. This creates an imbalance that needs to be addressed if the IETF Trust is to be the future owner.</font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>In order to preserve the value and integrity of the IANA trademarks, the IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks.</div></div></blockquote><div><br></div></span><div style="font-family:arial,sans-serif;font-size:12.8px"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><font color="#0000ff">GSS: This overlooks (probably inadvertently) the key obligation of a trademark licensor -- to monitor the quality of the goods and services offered by the licensee. This is a different obligation than monitoring the use of the trademarks. This "Quality Control" obligation is at the heart of any trademark licensor/licensee relationship. That said, to the extent the OC's have (or will have) their own quality control mechanisms, the trust should be able to take advantage of these to a very great extent in satisfying its quality control obligations. This is another topic that would need to be covered in the Community Assurance Agreements (or other mechanisms put in place).</font></div></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><b>C. Terms<br></b> <div>The following contains examples of the principal terms that may need to be included in such agreements should the community desire for the IETF Trust to take on the role of the Independent Entity. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. <br><br></div><div><b>C.1. IP Transfer Agreement (between ICANN and IETF Trust)<br></b> <br>a. When requested by the IETF Trust, ICANN will transfer and assign all of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the “Transfer”). The IETF Trust will not assume any obligations or liabilities of ICANN that arose prior to the Transfer.<br> <br>b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for <a href="http://iana.org/" target="_blank">iana.org</a>(GoDaddy), and will pay all fees associated with such filings. With respect to <a href="http://iana.org/" target="_blank">iana.org</a> and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar.<br> <br>c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party rights, all qualified by the knowledge of ICANN’s in-house legal department.<br> <br>d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity.<br></div></div></blockquote><div><br></div></span><div style="font-family:arial,sans-serif;font-size:12.8px"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><font color="#0000ff">GSS: These terms seem broadly customary and acceptable, but would need significant review by the CWG and its counsel.</font></div><font color="#0000ff"> </font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"> <br><b>C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community)<br></b> <br>a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community. <br> <br>b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the “IANA IP Reps”. <br> <br>c. The IETF Trust will hold, maintain and renew the IANA IP in accordance with good IP management practices and shall seek new territorial registrations based on the IANA IP as instructed by the IANA IP Reps.<br> <br>d. The IETF Trust will license the IANA IP to PTI and any successor provider(s) of the IANA functions identified by the IANA IP Reps. Such license shall include the provisions described in Part III below. The IETF Trust will terminate the license to PTI or any successor upon the instructions of the IANA IP Reps.<br></div></blockquote><div><br></div></span><div style="font-family:arial,sans-serif;font-size:12.8px"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><font color="#0000ff">GSS: Does the IETF contemplate one or three of these agreements? Earlier in the email it seems to be three, but in this discussion it appears to be one. If this is the method chosen for the relationship between the OC's and the trust, there is not enough stated to really define the relationship, and some of the details that are here may not work. The interrelationship between the OC's needs to be clarified. The party or parties representing the names community will also be an issue.</font></div><font color="#0000ff"> </font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"> <br><b>C.3. IANA IP License Agreement (between IETF Trust and PTI)<br></b> <br>a. The IETF Trust will grant PTI a non-exclusive, worldwide, royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions.<br></div></blockquote><div><br></div></span><div style="font-family:arial,sans-serif;font-size:12.8px"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><font color="#0000ff">GSS: Initially, this license should be exclusive, until another entity takes on a role as an IFO for names, numbers or protocols, and thus needs a license as well). The trust should not retain any</font></div><font color="#0000ff"> <div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">right to use the trademarks; it is here only to serve as licensor. Some of the terms here seem to be taken from a copyright license ("display and reproduce"), but that will be taken care of....</div></font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"> <br>b. All use of the IANA marks shall be in accordance with mutually-agreed quality requirements, as well as size, color, placement and similar guidelines to be agreed.<br></div></blockquote><div><br></div></span><div style="font-family:arial,sans-serif;font-size:12.8px"><font color="#0000ff"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">GSS: As noted above, the quality control requirements must apply to the goods and services offered by the licensee. This needs to be absolutely explicit in any summary of this (or any other) trademark license agreement. Without it, we would have a "naked license," which is a major "no-no." A naked license can lead to abandonment of the mark, cancellation of the registrations, and loss of the mark's capacity to be a trademark. The quality of the use of the mark is a separate and much less important obligation between licensor and licensee. </div> </font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"> <br>c. The IETF Trust will authorize PTI to operate via the <a href="http://iana.org/" target="_blank">iana.org</a> domain and any number of sub-domains. IETF Trust shall appoint PTI as the technical contact for the <a href="http://iana.org/" target="_blank">iana.org</a> domain during the term of the agreement. PTI shall use<a href="http://iana.org/" target="_blank">iana.org</a> and all associated subdomains exclusively for purposes of offering the IANA functions.<br> <br>d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service mark, trade name or domain name.<br> <br>e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages received as a result of its enforcement of the IANA marks.<br></div></blockquote><div><br></div></span><div style="font-family:arial,sans-serif;font-size:12.8px"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><font color="#0000ff">GSS: The role of the OC's in relationship to these rights must be clarified, including rights to cause the trust to enforce (or not) against a particular infringer, the course of such enforcement, and the apportionment of damages received, if any)</font></div><font color="#0000ff"> </font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"> <br>f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust’s opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the express instruction of the IANA IP Reps.<br></div></blockquote><div><br></div></span><div class="gmail_default" style="font-size:12.8px"><font color="#0000ff">GSS: This is unacceptable. The trust cannot have a unilateral right to terminate the license, so long as one or more OC's wishes to have PTI continue as its IFO. The trust should only be able to terminate the license upon express instruction from one or more OC's, and unless its from all 3 OC's, the termination would have to be partial (limited to the relevant function) while continuing for the remaining OC's. I should also note that these are particularly "licensor-favorable" (as opposed to neutral) termination rights, based on my experience with trademark licenses.</font></div><span class="im" style="font-family:arial,sans-serif;font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"> <br>g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the <a href="http://iana.org/" target="_blank">iana.org</a> domain to the IETF Trust.<br></div></blockquote><div><br></div></span><div style="font-family:arial,sans-serif;font-size:12.8px"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><font color="#0000ff">GSS: This would have to be limited by any transitional requirements, both by the "losing" licensee and the "gaining" licensee.</font></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 10, 2016 at 11:30 PM, Mueller, Milton L <span dir="ltr"><<a href="mailto:milton@gatech.edu" target="_blank">milton@gatech.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I like what I see here. Clear thinking about what any trust needs to do for us, and in particular the community assurance agreement and the commitment to maintain,
monitor and license the use of the marks addresses the concerns some had about the IETF Trust.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">--MM<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><a name="-756995623__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <a href="mailto:cwg-stewardship-bounces@icann.org" target="_blank">cwg-stewardship-bounces@icann.org</a> [mailto:<a href="mailto:cwg-stewardship-bounces@icann.org" target="_blank">cwg-stewardship-bounces@icann.org</a>]
<b>On Behalf Of </b>Jonathan Robinson<br>
<b>Sent:</b> Friday, January 8, 2016 12:56 PM<br>
<b>To:</b> <a href="mailto:cwg-stewardship@icann.org" target="_blank">cwg-stewardship@icann.org</a><br>
<b>Subject:</b> [CWG-Stewardship] FW: IPR follow up<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="EN-IE" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Please see below for draft principal terms as provided by Jari Arkko.</span><span lang="EN-IE" style="font-size:11.0pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-IE" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-IE" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Note that this draft was provided as an example that “</span><span lang="EN-IE" style="font-size:11.0pt">could apply to other parties as well as
the IETF Trust, are in no way set in stone, but hopefully they give some indication of the kind of arrangements that could be done.</span><span lang="EN-IE" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">”<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-IE" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-IE">——<br>
<br>
</span><b><span lang="EN-IE" style="font-size:13.5pt">Example Principal Terms of Intellectual Property Agreements<br>
</span></b><span lang="EN-IE"> <br>
This draft relates to a possible use of IETF Trust as an independent entity to hold IANA-related IPR. The IETF Trust is one of the discussed alternative holders of IPR.<br>
<br>
This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. The IETF Trust has provided this draft as a hopefully helpful initial contribution, but clearly discussion in
the various communities and further work is needed. Comments are appreciated.<br>
<br>
<b>A. Background</b><u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span lang="EN-IE">The ICG proposal indicates that the IANA trademark and
<a href="http://iana.org" target="_blank">iana.org</a> domain should be transferred to an entity independent of the IANA Numbering Services Operator.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">The IETF Trust would be a potentially acceptable candidate for this role, and the Trust has discussed the implications of assuming this responsibility. The following is some background of the Trust’s position and an overview
of how the role and responsibilities may be fulfilled.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">While this fulfillment is a part of implementation rather than the ICG proposal, the IETF Trust wants to ensure progress on determining those implementation steps. The Trust is of course only one of the possible ways
to satisfy the requirements from the ICG proposal. Nevertheless, the Trust wanted to start by suggesting an overall framework for one way of satisfying the requirements. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">The IETF Trust is a Virginia USA private trust, the trustees of which are the members of the IETF Administrative Oversight Committee (IAOC), and the beneficiary of which is the IETF community. The purpose of the IETF
Trust includes acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology
associated with the Internet and related technology.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><b><span lang="EN-IE">B. Framework</span></b><span lang="EN-IE"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">The Trust believes it would need to enter into three different types of agreements to effect the transfer of the IANA intellectual property (IP) and to enter into licensing arrangements with the IANA service provider(s).<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">These agreements include:<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">1. An Agreement between ICANN and the IETF Trust transferring the IANA IP to the IETF Trust<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">3. Agreement(s) whereby the IETF Trust provides for the use of the
<a href="http://iana.org" target="_blank">iana.org</a> domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">The Trust understands that each community would need to follow its own internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">The Community Assurance Agreements with the IANA communities would establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the
IETF Trust to provide, update, and revoke licenses as needed to support these selections.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-IE">In order to preserve the value and integrity of the IANA trademarks, the IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and
monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks.<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-IE"><br>
<b>C. Terms<br>
</b> <u></u><u></u></span></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-IE">The following contains examples of the principal terms that may need to be included in such agreements should the community desire for the IETF Trust to take on the role of the Independent Entity. This non-binding draft
has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span lang="EN-IE">C.1. IP Transfer Agreement (between ICANN and IETF Trust)<br>
</span></b><span lang="EN-IE"> <br>
a. When requested by the IETF Trust, ICANN will transfer and assign all of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the “Transfer”). The IETF Trust will not assume any obligations or liabilities of ICANN that arose
prior to the Transfer.<br>
<br>
b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for
<a href="http://iana.org" target="_blank">iana.org</a> (GoDaddy), and will pay all fees associated with such filings. With respect to
<a href="http://iana.org" target="_blank">iana.org</a> and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar.<br>
<br>
c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party
rights, all qualified by the knowledge of ICANN’s in-house legal department.<br>
<br>
d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability
associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity.<br>
<br>
<b>C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community)<br>
</b> <br>
a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community. <br>
<br>
b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the “IANA IP Reps”. <br>
<br>
c. The IETF Trust will hold, maintain and renew the IANA IP in accordance with good IP management practices and shall seek new territorial registrations based on the IANA IP as instructed by the IANA IP Reps.<br>
<br>
d. The IETF Trust will license the IANA IP to PTI and any successor provider(s) of the IANA functions identified by the IANA IP Reps. Such license shall include the provisions described in Part III below. The IETF Trust will terminate the license to PTI or
any successor upon the instructions of the IANA IP Reps.<br>
<br>
<b>C.3. IANA IP License Agreement (between IETF Trust and PTI)<br>
</b> <br>
a. The IETF Trust will grant PTI a non-exclusive, worldwide, royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions.<br>
<br>
b. All use of the IANA marks shall be in accordance with mutually-agreed quality requirements, as well as size, color, placement and similar guidelines to be agreed.<br>
<br>
c. The IETF Trust will authorize PTI to operate via the <a href="http://iana.org" target="_blank">
iana.org</a> domain and any number of sub-domains. IETF Trust shall appoint PTI as the technical contact for the
<a href="http://iana.org" target="_blank">iana.org</a> domain during the term of the agreement. PTI shall use
<a href="http://iana.org" target="_blank">iana.org</a> and all associated subdomains exclusively for purposes of offering the IANA functions.<br>
<br>
d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service
mark, trade name or domain name.<br>
<br>
e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages
received as a result of its enforcement of the IANA marks.<br>
<br>
f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers
or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust’s opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the
express instruction of the IANA IP Reps.<br>
<br>
g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the
<a href="http://iana.org" target="_blank">iana.org</a> domain to the IETF Trust.<u></u><u></u></span></p>
</div>
</div>
</div></div></div>
</div>
</div>
<br>_______________________________________________<br>
CWG-Stewardship mailing list<br>
<a href="mailto:CWG-Stewardship@icann.org">CWG-Stewardship@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br>
<br></blockquote></div><br></div>