[CWG-Stewardship] FW: IPR follow up

Mon Jan 11 18:56:41 UTC 2016

Seun,

My answers are in-line below.

On Mon, Jan 11, 2016 at 12:40 PM, Seun Ojedeji <seun.ojedeji at gmail.com>
wrote:

> 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.
>
The goals are what we need to decide in the CWG.  There is a shared minimum
requirement that the new owner is independent of the IFO.  While that is a
shared minimum requirement, it is very much an open question here whether
*any* entity independent of the IFO is acceptable or whether the CWG (and
ultimately the names community) has additional principles and
requirements.  Another goal that has been stated is that the entity be
"neutral" but the definition of neutral is not yet settled.  I believe that
at a minimum, an entity controlled by one operational community does not
meet that criterion as well as one that is controlled by all three or none
at all.  I understand that the NRO/RIRs appear to be comfortable with the
result you support.  That doesn't mean that the names community should
follow along.  We need to make our own minds up about this, and that is
what the DT-IPR draft principles and requirements need to reflect.  Those
principles and requirements really where our conversation needs to start,
so that we can agree to principles that then guide our review of any
specific proposal, including this one.

> 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'm not sure what you mean when you say that the "OCs are able to access
the IPR and domain in a manner they currently do."  The domain is currently
"accessed" by providing data to the IFO.  The new owner, whoever it is,
needs to provide the IFO operational control of the domain so that the IFO
can continue to provide services to the OCs. As for "access" to the
trademarks, unless you are referring to access by the IFO so that it can
hold itself out as the "Internet Assigned Numbers Authority" or the "IANA,"
I'm really at a loss.  I don't see a circumstance where the OCs "access"
the trademarks in any other way. 

> 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.
>
There's absolutely nothing moot here.  You need to take into account what
a beneficiary is in the context of a trust.  The beneficiary is the entity
for whose benefit the trust was set up.  As such it's perfectly logical
that the IETF is the sole beneficiary of the IETF Trust, since it was set
up solely to hold IETF IPR.  There is also a fiduciary relationship between
the trustees and the beneficiary, which means that the trustees have a duty
to act solely in the best interests of the beneficiary when with dealing
with trust assets.  The trustees do not owe this duty to any other person
or entity.  These are not just empty words or concepts; these are core
principles of governance of a trust, and the trustees can get in big
trouble if they violate them. (It's similar to the fiduciary duty of ICANN
Board members to act in the best interests of the corporation -- except
here it's the beneficiary and not the trust that is owed that duty.)  If we
want to use a trust as the owner, we need to understand its governance,
just as we have spent so much time (particularly in the CCWG) understanding
the governance of a non-profit corporation.  (It's notable, by the way,
that many "charitable trusts" are set up without a beneficiary, which means
that the trustees duty is to manage the trust solely for the purposes of
the trust and not for the beneficiary.  This avoids confusion about the
purposes of the trust and the duties of the trustees.) I'm far from certain
that any agreement proposed in these terms gives any OC (other than the
IETF) "ample option to access the resource entrusted to the IETF Trust" and
I'm not sure which of several agreements you are referring to.  But I am
concerned that the IETF Trust could have the ability to cut off access even
over the objections of any particular OC.  I'm not saying that there is no
way for the IETF Trust to be a workable owner of the IPR assets; something
could be put together.  But to my mind, it is expedient rather than
preferable.

> 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.
>
Actually, I think it would be quite helpful.  Furthermore, I don't think
that there are significant economic or resource differences between working
up an arrangement with the IETF and working up an arrangement for a new
trust.  The transfer agreements (assigning IPR to the new owner) and
license agreements (granting rights to the IPR to the IFO) will largely be
the same under any owner (the license may actually be somewhat simpler
under a shared trust).  Creating and setting up the governance of a new
trust vs. setting up the relationships between the IETF Trust and the OCs
(presumably, including the IETF even though its on both sides) are
similarly challenging.  There is no such thing as a "community assurance
agreement," so whatever we and our counsel invent to fill that agreement
will be novel as well.  Trust governance documents, by contrast, are more
established, so we will at least have a basis for whatever unique
arrangements are required in this particular circumstances.

> 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.
>
Can you explain what you mean when you say the IETF is "more than" "just
one of the 3 OCs"?  I don't see that its role setting protocol parameters
elevates it above the other two OCs.  Frankly, if there is a belief that
the IETF is "more equal" than names or numbers, that increases my concerns
about putting a shared resource into the hands of a Trust controlled by and
established for the benefit of the IETF.  Please also explain what you mean
by its "operating approach."  I'm not aware of anything in its operating
approach that removes "any fears of capture or

any form of coup."  This statement also shows how easily the line can be
blurred between the IETF Trust and the IETF itself, which again raises
concerns rather than resolving them.  None of this is intended to cast any
aspersions against the IETF or any of the administrators serving as
Trustees of the IETF Trust.  The IETF is set up for a particular purpose
and as far as I can tell they do it very well.  I have a great deal of
respect for them (and for the IETF) across the board.  But neither do I see
a reason to cast the IETF as some sort of neutral and benevolent "holy
spirit" that has no viewpoints or opinions other than those that are always
best for everybody.

> 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.
>
I believe this is a minimum requirement in connection with any new owner.
But it really puts nothing to rest.  At best it offers the possibility of
moving the assets if the new owner

is not performing as it should.  But this is a very slim possibility if
the IETF essentially has a veto over moving the assets out of the IETF
Trust -- yet another issue to be overcome in that scenario.

Greg

> 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 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).
>>
>>>
>>>
>>> *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/6c6cfa1f/attachment-0001.html>