[CWG-Stewardship] FW: IPR follow up

[Seun Ojedeji]

Hello Greg,

I think we need to be clear on what the goal is and I believe the main goal
is that the IPR and domain be transferred to an entity independent of the
IANA function operator. Does the IETF meet that requirement? Yes. The other
requirement is that the OCs are able to access the IPR and domain in a
manner they currently do. This is where I think the text of the agreement
comes into play and we should check the text against that requirement. I
believe that is what you are attempting with your comments in blue.

I think your initial concern about who the beneficiary is may be considered
mute considering that the agreement would give each OC ample option to
access the resource entrusted to the IETF trust.

FWIW, it's not helpful to spin up a whole new trust just for this purpose.
It makes a lot of sense both economically and resource wish to utilise
existing platforms. As it's been said many times, IETF's is not just one of
the 3 OCs it's more than that and its operating approach remove any fears
of capture or any form of coup that you may be thinking could occur.

That said, (if possible) we could perhaps include a requirement that allows
transfer of the resource to another trust if all the 3OCs agree to do so in
future. Maybe that would put to rest the mind of Greg and any other person
concerned about this.

Regards
On 11 Jan 2016 5:02 PM, "Greg Shatan" <gregshatanipc at gmail.com> wrote:

> All,
>
> Below are my comments and questions on the "Example Principal Terms."
>
> 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?
>
> We need to address those issues first.
>
> 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.
>
> Greg
>
>
>> *Example Principal Terms of Intellectual Property Agreements*
>> 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.
>>
>> 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.
>>
>>
>> *A. Background*
>> The ICG proposal indicates that the IANA trademark and iana.org domain
>> should be transferred to an entity independent of the IANA Numbering
>> Services Operator.
>>
>
> ​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 -- iana.org,
> iana.net, and iana.com.  Presumably, all of these would be transferred
> away from ICANN to the trust.  Can you confirm that is the intention?
>
>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>
> 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.  This is significant in understanding the nature of
> the IETF Trust, as well as the relationship between the beneficiary and the
> trust's assets.
>
> According to the IETF Trust Agreement (
> http://trustee.ietf.org/trust-agreement-2014.html) the beneficiary of the
> IETF​ Trust is the IETF (rather than the IETF community), and the successor
> Beneficiary is "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.
>
>
>> 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.
>> ​
>>
>>
>
>> *B. Framework*
>>
>> 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).
>>
>> These agreements include:
>>
>> 1.  An Agreement between ICANN and the IETF Trust transferring the IANA
>> IP to the IETF Trust
>>
>
> ​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).)
>
>>
>> 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
>>
>
> ​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.
>
> 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).
>
> 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.
>
>>
>> 3.  Agreement(s) whereby the IETF Trust provides for the use of the
>> iana.org domain, or a subdomain, and licenses the use of the IANA
>> trademarks to the IANA service provider(s) selected by the IANA communities.
>>
>
> ​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)")​.
>
>>
>> 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.
>>
>> 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.
>>
>
> ​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.
>
>>
>> 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.
>>
>
> ​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 licen​sor/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).
>
>>
>>
>> *C. Terms*
>> 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.
>>
>>
>> *C.1.  IP Transfer Agreement (between ICANN and IETF Trust)*
>> 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.
>>
>> 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 iana.org(GoDaddy), and will pay
>> all fees associated with such filings.  With respect to iana.org and any
>> other domain names within the IANA IP, the IETF Trust will be designated as
>> the administrative contact with the registrar.
>>
>> 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.
>>
>> 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.
>>
>
> ​GSS: These terms seem broadly customary and acceptable, but would need
> significant review by the CWG and its counsel.​
>
>
>>
>>
>> *C.2.  Community Assurance Agreement (between IETF Trust, IETF, RIRs, and
>> the names community)*
>> 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.
>>
>> 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”.
>>
>> 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.
>>
>> 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.
>>
>
> ​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.​
>
>
>>
>>
>> *C.3.  IANA IP License Agreement (between IETF Trust and PTI)*
>> 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.
>>
>
> ​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
>
> ​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....
>
>>
>> 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.
>>
>
> ​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. ​
>
>
>>
>> c.  The IETF Trust will authorize PTI to operate via the iana.org domain
>> and any number of sub-domains.  IETF Trust shall appoint PTI as
>> the technical contact for the iana.org domain during the term of the
>> agreement.  PTI shall useiana.org and all associated subdomains
>> exclusively for purposes of offering the IANA functions.
>>
>> 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.
>>
>> 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.
>>
>
> ​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)
>
>
>>
>> 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.
>>
>
> ​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.
>
>>
>> g.  Upon termination of the agreement, PTI will immediately cease all use
>> of the IANA IP and shall transfer technical control of the iana.org domain
>> to the IETF Trust.
>>
>
> ​GSS: This would have to be limited by any transitional requirements,
> both by the "losing" licensee and the "gaining" licensee.
>
> On Sun, Jan 10, 2016 at 11:30 PM, Mueller, Milton L <milton at gatech.edu>
> wrote:
>
>> 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.
>>
>>
>>
>> --MM
>>
>>
>>
>> *From:* cwg-stewardship-bounces at icann.org [mailto:
>> cwg-stewardship-bounces at icann.org] *On Behalf Of *Jonathan Robinson
>> *Sent:* Friday, January 8, 2016 12:56 PM
>> *To:* cwg-stewardship at icann.org
>> *Subject:* [CWG-Stewardship] FW: IPR follow up
>>
>>
>>
>> Please see below for draft principal terms as provided by Jari Arkko.
>>
>>
>>
>> Note that this draft was provided as an example that “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.”
>>
>>
>>
>> ——
>>
>>
>> *Example Principal Terms of Intellectual Property Agreements *
>> 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.
>>
>> 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.
>>
>> *A. Background*
>>
>> The ICG proposal indicates that the IANA trademark and iana.org domain
>> should be transferred to an entity independent of the IANA Numbering
>> Services Operator.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> *B. Framework*
>>
>>
>>
>> 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).
>>
>>
>>
>> These agreements include:
>>
>>
>>
>> 1.  An Agreement between ICANN and the IETF Trust transferring the IANA
>> IP to the IETF Trust
>>
>>
>>
>> 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
>>
>>
>>
>> 3.  Agreement(s) whereby the IETF Trust provides for the use of the
>> iana.org domain, or a subdomain, and licenses the use of the IANA
>> trademarks to the IANA service provider(s) selected by the IANA communities.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> *C. Terms *
>>
>> 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.
>>
>>
>> *C.1.  IP Transfer Agreement (between ICANN and IETF Trust) *
>> 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.
>>
>> 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 iana.org (GoDaddy), and will pay
>> all fees associated with such filings.  With respect to iana.org and any
>> other domain names within the IANA IP, the IETF Trust will be designated as
>> the administrative contact with the registrar.
>>
>> 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.
>>
>> 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.
>>
>>
>> *C.2.  Community Assurance Agreement (between IETF Trust, IETF, RIRs, and
>> the names community) *
>> 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.
>>
>> 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”.
>>
>> 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.
>>
>> 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.
>>
>>
>> *C.3.  IANA IP License Agreement (between IETF Trust and PTI) *
>> 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.
>>
>> 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.
>>
>> c.  The IETF Trust will authorize PTI to operate via the iana.org domain
>> and any number of sub-domains.  IETF Trust shall appoint PTI as
>> the technical contact for the iana.org domain during the term of the
>> agreement.  PTI shall use iana.org and all associated subdomains
>> exclusively for purposes of offering the IANA functions.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> g.  Upon termination of the agreement, PTI will immediately cease all use
>> of the IANA IP and shall transfer technical control of the iana.org domain
>> to the IETF Trust.
>>
>> _______________________________________________
>> CWG-Stewardship mailing list
>> CWG-Stewardship at icann.org
>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>
>>
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20160111/aca8960b/attachment-0001.html>