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

[Sweeting, John]

Hi Izumi,

If you meant 1300 UTC then I can definitely make a call on Jan 5th.

I have read through your work below and fully support it.

Happy 2016

-john

On 12/31/15, 3:01 AM, "crisp-bounces at nro.net on behalf of Izumi Okutani"
<crisp-bounces at nro.net on behalf of izumi at nic.ad.jp> wrote:

>Hello Paul and all,
>
>
>It would be great to hear your feedback and I can wait until 4th Jan.
>
>To share a little more background -
>We are currently coordinating to have a call among the operational
>community leaders on the week of 4th Jan (7th Jan is a strong candidate).
>
>I would like to target to fix the feedback from the CRISP Team before the
>next call among the three operational communities, and share it online
>before the call, to start discussions among the OC leaders.
>That was the thinking behind the suggested date and I agree it would be
>good to have proper feedback from the CRISP Team members before we share
>our comment with other OCs, as you suggested.
>
>It may also be worth considering an irregular CRISP call before this IPR
>call among the three OCs, say on 5th Jan at the regular time, after we
>receive feedback from the CRISP Team members.
>
>
>To CRISP Team,
>To explore this option, I would like to see how many CRISP Team members
>can join a call, if we organise it on 5th Jan UTC2200, to discuss IPR
>issue, in preparation for the call with other OC leaders.
>If you can join and think having a call to discuss it helps, please
>express it on this list by 4th Jan.
>
>If there are less than 5 members who supports the idea and can join
>(including myself), I suggest we do this online without organising an
>irregular CRISP call on 5th Jan.
>
>
>...and wish you call a wondeful 2016 to come!
>
>
>Izumi
>PS: Sorry I'm a little slower in my responses as I'm in a remote area in
>Japan now. I still read CRISP and ianaxfer mails and will be back to
>routine from 4th.
>
>
>On 2015/12/30 4:21, Paul Rendek wrote:
>> 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-hN6srDVOwhRJvQZzRp
>>>kGAAPk8/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
>>>
>>
>>
>> _______________________________________________
>> CRISP mailing list
>> CRISP at nro.net
>> https://www.nro.net/mailman/listinfo/crisp
>>
>
>
>_______________________________________________
>CRISP mailing list
>CRISP at nro.net
>https://www.nro.net/mailman/listinfo/crisp


________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.