[CRISP-TEAM] IPR update and request for feedback: 29th Dec

[Paul Rendek]

Hello Izumi,

I would like provide some feedback to this mail but I ws wondering if I
could request a bit more time. I can provide a reply to this by 4
January and I hope that is still okay.

Given that we are in the holiday period and New Years is around the
corner I wonder if many would have seen this mail and I would also be
interested in the thoughts of our colleagues, if they have any.

Cheers,
Paul



On 24/12/15 17:22, Izumi Okutani wrote:
> Dear CRISP Team,
>
>
> I hope you are enjoying holidays if you celebrate Christmas.
>
> As I have updated at the last CRISP call, the target timeline we have suggested is in two stages.
>
>  Stage one (agree on principles and framework): before the ICG & CCWG proposals submission to the NTIA (around Feb 2016)
>  Stage two (complete implementation on IPR) : before the IANA contract expiry (Sep 2016)
>
> For discussions on stage stage, I would like to share draft of comparison I have made between the CRISP IPR principles, and the principles developed in DT-IPR in CWG, Chaired by Greg Shatan.
>
> DT-IPR: DRAFT OF POTENTIAL PRINCIPLES AND REQUIREMENTS FOR OWNER OF IANA TRADEMARKS AND DOMAIN NAMES
> Google doc: https://docs.google.com/document/d/1ZGSlKj-JSXe4T0wWv-hN6srDVOwhRJvQZzRpkGAAPk8/edit?pref=2&pli=1
>
> I welcome your feed back until 29th Dec on:
>
>  1) Whether you agree with the categorization as a)-e)
>  2) Whether each principle is adequately categorised under a)-e)
>     Especially under a) and b): if you have any objection, please raise it
>  3) Do you agree with an observation that if I.1.a. is set as the minimum requirement, it would cause inconsistency with the CRISP IPR principles (would set a stronger minimum requirement)
>     - I. 1. The Owner must be “neutral.”a. Structural neutrality: the Owner may not have any structural tie to any operational community to the exclusion of any other. (That is, if there is a structural tie to any operational community, there must be an equivalent tie to each of the other operational communities. Alternatively, the Owner could have no structural ties to any operational community.)
>
> After reflecting your feedback, I would then like to share it with the other operational community leaders on 30th Dec.
>
>
> -----
> Suggested way forward on how we coordinate:
>
> I have categorised the principles developed in CWG DT-IPR as below.
>
> a) High level principles consistent with the CRISP IPR principles
> b) High level principles which was not discussed in the CRISP but no concerns observed
> c) High level principles which would/may not be consistent with the CRISP IPR principles
> d) Details which are to be further discussed and to be coordinated
>    - Details relevant for framework
>    - Details relevant for implementation
> e) Intention to be confirmed by other party
>
> Rather than trying to reach an agreement and coordinate everything at once, my suggestion is to target to fix the high level principles categorised as a) and b), coordinate online on c) as a start.
> Then, we can coordinate to agree on framework. Some parallel work can be accommodated as needed.
>
>
> Comparison of of the principles 
>
>
> *a) Principles consistent with the CRISP IPR principles*
>
> I. Principles and Requirements for the Post-Transition Owner of both the IANA Trademarks and Domain Names  
> 1. The Owner must be “neutral.”
> a. Structural neutrality: the Owner may not have any structural tie to any operational community to the exclusion of any other. (That is, if there is a structural tie to any operational community, there must be an equivalent tie to each of the other operational communities. Alternatively, the Owner could have no structural ties to any operational community.); OR
> b. Functional neutrality: the Owner must operate such that effective control over its actions with respect to the IANA IPR is not dominated or steered by any of the operational communities to the exclusion of any other. (That is, each community must have approximately the same functional relationship to the Owner.)
> c. In either case, neutrality also implies that the IFO cannot be the owner of the IANA trademarks and domain names.
>
> Note: For I.1.a., I observe consistency with the CRISP IPR principles, *if* this is the principle to be applied in case we agree to set up a new Trust. I observe possible inconsistency with the CRISP IPR principles if this is set as the minimum requirement (I also categorised I.1.a. under "c) Principles which would/may not be consistent with the CRISP IPR principles" for this reason, in case of based on the latter assumption)
>
>
> 2. The Owner will take the form of a Trust, either:
> a. A newly formed Trust; OR
> b. The IETF Trust.
>
> 5. The Owner must be responsive, responsible and accountable to the three communities.
>
> 7. Owner must be prepared to facilitate separation if requested by any operational community (see Section II below for details).
>
> II. Principles and requirements of the Owner in the event of separation
> 1. Owner must not create risk to continued operations, stability and security of the IANA functions in the event of separation.
> 2. Owner must follow the directions of the community or communities initiating separation to the extent those instructions are compatible with the Owner’s responsibilities and obligations.
>
> IV. Proposed Principles and Requirements Relating to iana.org
> 1. The ongoing stability of iana.org is of paramount importance (because of its direct operational relevance).
>
> V.Proposed Principles and Requirements Relating to IANA trademarks.
> 3. The Owner must have experience in owning and managing trademarks, but also experience with issues relating to the Internet. Employees or advisors may provide such experience.
> a. The Owner must have access to employee(s) with experience and to outside trademark counsel.
>
> *b) Principles which was not discussed in the CRISP but no concerns observed (to be further reviewed by the CRISP Team and the RIRs)*
> III.
> 1. The names community (and the other operational communities) should have a process or mechanism to resolve any disputes with the Owner.
> a. i. These should be simple.
>
> 2. There should also be a process or mechanism to resolve any disputes between the operational communities relating to the IANA IPR.
>
> 3. Potential Remedies
> a. Moving the IANA IPR to a new Owner (“Divestiture”) is a potential ultimate remedy
> i. This should not be an option in disputes among the operational communities, only in disputes between the Owner and the operational communities.
> ii. This is intended to be a stable, long-term relationship. There should be a high bar to divesting the IPR from the Owner.
> iii. Any new Owner of the IANA IPR should be approved by all three operational communities, or at least subject to a veto under certain circumstances.
>
> IV. Proposed Principles and Requirements Relating to iana.org
> 2. The registration must be held by (in DNS registry terms, the registrant must be) the Owner. (This is what it means to “own” a domain name, since they are in fact only registrations.)
>
> 7. Until changes contemplated below are agreed, the operation of the iana.org domain must remain functionally stable.
> a. “Functionally stable” means to provide the same features and URIs as are available from the iana.org site as of the transition. Normal operational adjustments (such as software upgrades, bug fixes, network renumbering and so on) are not to be restricted by this provision.
>
> 9. Any dispute resolution among any of the Owner and the operational communities will follow the same overall dispute resolution mechanism as any other IANA IPR, with two overriding caveats:
> a. the continued operational stability of any registry hosted at iana.org is paramount;
> b. however, no IFO may continue to publish registries at iana.org or anywhere beneath it when the authoritative source for the registry data has instructed that such registries be removed.
>
> V.Proposed Principles and Requirements Relating to IANA trademarks.
> 1. The trademarks must not become invalid, unenforceable, subject to cancellation or subject to claims of abandonment or “genericide” as a result of the transfer of the trademarks or the Owner’s actions or inactions.
>
> 2. As a result of the transition, there will be a license to ICANN (and either a license or sublicense to PTI) as the IANA functions operator(s) for the operational communities.
>
> 6. Being a licensee of the trademarks does not convey a right to publish any particular IANA registry, independent of the relevant operational community’s decision to make that licensee the operator of those registries. If a community is moved its registries from an IFO, the license to that entity should be transferred or terminated simultaneously with such move.
>
> *c) Principles which would/may not be consistent with the CRISP IPR principles*
>
> I. Principles and Requirements for the Post-Transition Owner of both the IANA Trademarks and Domain Names  
> 1. The Owner must be “neutral.”
> a. Structural neutrality: the Owner may not have any structural tie to any operational community to the exclusion of any other. (That is, if there is a structural tie to any operational community, there must be an equivalent tie to each of the other operational communities. Alternatively, the Owner could have no structural ties to any operational community.);
>
> Note: I observe possible inconsistency with the CRISP IPR principles *if* 1.a. is set as the minimum requirement (See also "Note" under "a) Principles consistent with the CRISP IPR principles".)
>
>
> *d) Details which are to be further discussed and to be coordinated (details relevant for framework/implementation)
>
> Details relevant for framework:
>
> I. Principles and Requirements for the Post-Transition Owner of both the IANA Trademarks and Domain Names  
> (If put in the context of the numbers community)
> 3. The relationship of the names community to the Owner will be dictated by the type of “neutrality” the names community requires. In the Trust context this means, as a practical matter :
> a. The names community would join the other operational communities in forming a Trust and each would appoint a Trustee (or Trustees) of the Trust and thereby have its interests directly represented in Trust decisions. Presumably, all three communities would also be named as beneficiaries of the Trust; OR
> b. The names community has a contractual relationship to the Trust, which could include an advisory board to provide advice to the Trust on matters relating to the IANA IPR.
> i. One such sample contractual relationship is described at http://mm.icann.org/pipermail/cwg-stewardship/2015-October/004449.html and the links from that message. It includes a contractual mechanism, with decisions informed by an advisory board.
> ii. In the case of the IETF Trust, the names community would not appoint any Trustees and would not be a beneficiary of the Trust. Instead, the IETF would continue to appoint all Trustees and the IETF would remain the sole beneficiary of the Trust.
> iii. Presumably, the numbers community would have a parallel relationship to the Trust. In the case of the IETF Trust, it is unclear how this would work for the protocols community, taking into account their existing relationship to the IETF Trust.
>
> Note: 3.b would sufficiently meet the needs of the number community proposal
>
> 5.	The Owner must be responsive, responsible and accountable to the three communities.
> a. How responsive does the Owner need to be?
> b. How much influence should the three operational communities have over the actions of the Owner?
> c. How should the Owner be accountable to, and be held accountable by, the names community and the other operational communities?
>
> 6. Owner must have necessary funding to carry out these responsibilities.
> Decision needed: Should the IPR be transferred to the Owner along with sufficient funding to cover some or all of the costs associated with ownership (quality control, policing & enforcement, maintenance of registrations), at least for a set period of time? Alternatively, should the operational communities provide ongoing funding to the Owner (in the form of pre-agreed payments or periodic royalty payments)? Or should the Owner be responsible for all such costs?
>
> 8. Sidley cited several disadvantages (as well as some advantages) in connection with the use of a Trust generally, and the IETF Trust specifically, in its memo of August 4, 2015. The CWG should review these concerns and determine how Sidley’s advice influences any decisions by the CWG to proceed. These concerns include:
> a. Trust must exert control over the quality of services distributed under the IANA IPR, either directly, or by designating a third party to do so on its behalf.
> b. The current beneficiary of the IETF Trust is the IETF itself; the community may want a broader multistakeholder organization or association, or “the community” as the beneficiary.
> c. There would need to be safeguards against transfer of the IANA IPR by the IETF Trust, and specific instructions regarding disposition of the IANA IPR in the event of dissolution of the Trust.
> d. Trust will need to license the IPR to PTI.
> e. Agreements must be entered into reflecting the duties and responsibilities of the trustees with respect to the IANA IPR.
> f. Agreements should provide for the immediate transfer of title away from the trust, if the trustee breaches its duties with respect to the IANA IPR. These will be very important commitments from the trust to the multistakeholder community, and will need to be clear that the trustees will take direction from the community.
>
> Note: The CRISP Team observes 3.b would sufficiently meet the needs of the community, without making 3.a a must.
>
> II.  Principles and requirements of the Owner in the event of separation
> 3. Clear guidelines must be in place so that Owner can comply with orders from operational communities in case of separation and required transfer of licenses (or termination and grant of new licenses).
> a. This could be operationalized through contract and bylaw requirements as well as the Trust document itself.
>
> III. Principles and requirements in the event that disputes arise with the Owner or between operational communities
> 1. a. A fairly straightforward procedure can be adopted to address these disputes, using the Stewardship and Accountability groups’ escalation procedures as inspiration.
> ii. This is not a UDRP/IRP type procedure.
> iii. Emphasis should be on discussion and resolution.
> iv. An Advisory Board composed of all three communities could be a significant part of any DRP.
> v. This can be implemented as part of the transfer of the IPR. Potentially, it could also be implemented later in the process.
>
> V.Proposed Principles and Requirements Relating to IANA trademarks.
> 3. The Owner must be capable of carrying out the responsibilities expected of a trademark owner and licensor, including:
> k. Terminating the license and granting rights to a new IFO (if requested [or approved] by an operational community) is the ultimate form of quality control.
>
> V.Proposed Principles and Requirements Relating to IANA trademarks.
> 4. Quality Control over Licensees
> a. A trademark owner has a legal obligation to exercise control/oversight over the marks and the business conducted under the marks, so this must be a guiding principle/requirement.
> b. However, this should not be the primary priority for the Owner.
> c. Primary focus should be to ensure that trademarks are being used in a manner consistent with the IANA Function.
> d. Quality control needs to be fit for purpose - needs to meet minimum requirements (legal requirements), but should not do more. Quality control has to meet the requirements / needs of all three communities. If any community has a concern about how IANA is performing in relation to trademark, a mechanism needs to be in place to address such concerns.
> f. Is it acceptable to the names community if quality control is delegated to the operational communities (according to each OC’s responsibilities)?
>
>
> Details relevant for Implementation:
> I. Principles and Requirements for the Post-Transition Owner of both the IANA Trademarks and Domain Names 
> 8. Sidley cited several disadvantages (as well as some advantages) in connection with the use of a Trust generally, and the IETF Trust specifically, in its memo of August 4, 2015. The CWG should review these concerns and determine how Sidley’s advice influences any decisions by the CWG to proceed. These concerns include:
> g. Consideration will need to be given as to the tax attributes of the trust.
> h. From the perspective of the USPTO, the IETF Trust is not a separate legal entity and the trustees of the IETF Trust collectively own the IANA IPR. USPTO records need to be updated as Trustees change.
> i. If non-US trademark registrations are required in foreign jurisdictions, the trust may not be recognized as a legal entity.
>
> IV.Proposed Principles and Requirements Relating to iana.org
> 3. At the time of transition, the technical and operational control of the domain (in DNS registry terms, the technical contact) must remain with ICANN.
>
> 4. The registrar to be used must provide controls such that the technical contact cannot be changed by the registrant without the technical contact being aware of that change.
>
> 5. The registrar to be used must provide controls such that technical changes to the domain’s delegation can be made by the technical contact without approval by, but with notice to, the registrant.
>
> 6. ICANN may make any operational arrangements it likes in terms of the operation of the iana.org name. It is to be anticipated that, for practical purposes, ICANN will have its PTI affiliate perform the day-to-day operation of the domain.
>
> 8. In the event of separation, it is not possible for multiple IANA functions operators to operate the same domain at the same time. Therefore, in order to arrange for the future possibility of multiple IANA functions operators, the transfer of iana.org to the new Owner must include a statement of understanding by ICANN that it will co-operate in creating separate (internal) delegations below iana.org to accommodate the different operational communities. (The creation of the separate delegations will not itself be part of the transfer of IANA.ORG to the new owner.) It is expected that the details of new arrangements shall be worked out among the operational communities within no longer than $period (suggestion: one year).
>
> V.Proposed Principles and Requirements Relating to IANA trademarks.
> 3. The Owner must be capable of carrying out the responsibilities expected of a trademark owner and licensor, including:
> j. Quality Control over services offered by licensee(s) under IANA trademarks, with the understanding that the ability to terminate an IFO and license the mark and domain.
> l. Quality Control over how the IANA mark is used and displayed by licensee(s).
> m. Policing & enforcement of uses of the trademarks by unauthorized third parties.
> n. Maintenance of trademark registrations (and potentially filing additional trademark applications).
>
> 2(2nd No.2). Ownership and management of the IANA trademarks is different than it would be for a normal commercial entity, in that the trademarks are being held by the Owner solely to be licensed exclusively to the IFO (or potentially, one or more IFO’s) for the narrow functions of the affected operational communities. Beyond this, the Owner will not exploit the trademark in the traditional sense, i.e., the Owner will not itself provide services under the IANA trademarks, nor will it license the trademarks to third parties other than the IFO (or IFOs) (e.g., there should be no licenses for products (apparel, electronic goods, etc.) or other services).
>
> 4. Quality Control over Licensees
> e. Could quality control also be outsourced/delegated/subcontracted?
> i. Certain amount of operational control could be subcontracted, for example to operational communities, but ultimate control/responsibility is with the trademark owner.
> ii. Brand owner is required to exercise active quality control to meet minimum requirements.
>
> 5. Policing and Enforcement of Unauthorized Uses
> a. Owner should be able to set up and monitor a “policing” process to look out for unauthorized third party uses of the trademarks (e.g., watching services)
> b. Owner should have the capability to evaluate and, where appropriate, pursue and stop unauthorized uses through enforcement of the trademarks
>
> *e) Intention to be confirmed by other party*
>
> I. Principles and Requirements for the Post-Transition Owner of both the IANA Trademarks and Domain Names
> 4. The Owner must meet the requirements of the ICANN Board statement as set forth in its August 15, 2015 statement relating to neutrality: “ICANN is prepared to transfer full ownership of the IANA-related trademarks to a neutral third party mutually agreed among the operational communities.”
> i. We don’t know whether the Board would accept the operational communities’ determination that a proposed new Owner is a “neutral third party,” or would make its own determination.
>
> V.Proposed Principles and Requirements Relating to IANA trademarks.
> 4. Quality Control over Licensees
> g. Question: Has ICANN had to exercise quality control over uses of the IANA in any kind of licensor/licensee relationship? If so, how has this been done?
> i. Question: How has IETF Trust exercised quality control with licensees?
>
>
> -----
>
> Izumi
>
> _______________________________________________
> CRISP mailing list
> CRISP at nro.net
> https://www.nro.net/mailman/listinfo/crisp
>