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

German Valdez german at nro.net
Mon Jan 4 16:02:25 CET 2016 

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 

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

More information about the CRISP mailing list