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

Mon Jan 4 17:41:28 CET 2016

Hey Izumi,

Thanks, yes I will also join the call.

Paul

On 04/01/16 19:36, Izumi Okutani wrote:
> Thank you very much German for the details of the Webex call.
>
> So far, John, Andrei and I can join the call.
> If we hear from two more members who can join the call, we will have the call tomorrow.
>
> Please express it if you can confirm you can join the CRISP call to discuss the IRP principles and draft categorisation on how we coordinate with the other operational communities tomorrow, on Tue 5th Jan UTC13:00.
>
>
>
> Izumi
>
>
> On 2016/01/05 0:24, Andrei Robachevsky wrote:
>> 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
>>>
>> _______________________________________________
>> 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