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

Andrei Robachevsky robachevsky at isoc.org
Mon Jan 4 16:24:03 CET 2016 

German Valdez wrote on 04/01/16 16:02:
> Hi
> 
> Before all, happy new 2016 for all of you ! :)
> 
> In case Izumi decides to move ahead with the call this is the webex details 
>

FWIW, I can make it

Andrei

> Regards
> 
> German
> 
> 
> CRISP January 2016
> Tuesday, January 5, 2016
> 1:00 pm  |  UTC |  1 hr
>  
> Join WebEx meeting
> https://ripencc.webex.com/ripencc/j.php?MTID=m47ae35d7b1cd76bdf6d470ed1a1092f6
> Meeting number:	706 556 087
> Meeting password:	crisp
>  
> Join by phone
> 0800-051-3810 Call-in toll-free number (UK)
> +44-203-478-5289 Call-in toll number (UK)
> Access code: 706 556 087
> Global call-in numbers  |  Toll-free calling restrictions
> 
>  
> 
> 
>> On 3 Jan 2016, at 12:34 AM, Izumi_Okutani <izumiokutani at yahoo.co.jp> wrote:
>>
>> Hi John and all,
>>
>>
>> Happy New Year to everyone in the CRISP Team!
>>
>> Thank you John for explicitly expressing your availability, and support on having a CRISP call on 5th Jan. This is helpful to know. The regular time of UTC 1300 was indeed what I meant (2200 was in JST). 
>>
>> I suspect many of you may still be on holidays, and I continue to welcome  feedback on whether you support and can join the CRISP call on IPR on 5th Jan. 
>>
>> We organize the call if we can confirm three more members can join the call.
>>
>> It would also be good to know if there are members who cannot join the suggested call. 
>>
>>
>>
>> Thanks,
>> Izumi
>>
>>
>> Sent from iPhone 
>>
>> 2016/01/01 3:06、Sweeting, John <john.sweeting at twcable.com> のメッセージ:
>>
>>> 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.
>>>
>>> _______________________________________________
>>> 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
>

More information about the CRISP mailing list