[client com] FW: IANA IPR Community Agreement and License Agreement drafts

Greg Shatan gregshatanipc at gmail.com
Sun Jul 31 21:18:28 UTC 2016 

​Two issues, a placeholder and an aside:

​1.  *Should we have a call prior to the all-hands call with the other
communities?*  We really need to consider how to respond to these changes
(and the rejection/deletion of many of our changes), so that we have an
approach going into the call.

2.  *We need to consider how to respond to the points raised in the IETF
Trust's email texts (paraphrased below, with some very preliminary thoughts
below each)*.


   - *We do not believe we can accept any arrangement in which the Trust is
   subject to "approvals" by the CCG.  Such acceptance would be contrary
   to the Trust's anticipated fiduciary responsibility as the holder of the
   Marks.  We believe that any independent trust would face this problem.*
      - Approvals and consents are mentioned a number of times in the
      Principal Terms.  This document was presented to the IETF Trust's counsel
      for comment and (after waiting weeks) we were told counsel had
no comment.
      It's disappointing that this issue is coming to a head now, as opposed to
      months ago when counsel had the opportunity to raise it and did not.
      - If the "advice" of the communities (or any community) can have the
      same weight as "GAC Advice" or GNSO policy recommendations,
"advice" rather
      than "approvals" may be acceptable.
      - It should be noted that (as I understand it) the Trust's
      "anticipated fiduciary responsibility" is to the IETF Trust and to the
      Beneficiary of that Trust (the "IETF as a whole"), not to the other
      communities.
      - I'm not sure what the reference to an "independent Trust" alludes
      to.  I assume it alludes to a Trust independent of the
communities (but of
      course, the IETF Trust is not independent of all the
communities, given its
      structure and where its fiduciary responsibilities lie).
   - *We do not think that, given the terms of our Trust Agreement, the
   Trust is capable of acting as a "steward" for other operational
   communities.*
      - Interesting that the IETF Trust itself chose to head Section 3 of
      the Community Agreement "Stewardship of the IANA Intellectual Property,"
      but now claims it can't act as a "steward."
      - This term isn't mentioned in the ICG Proposal or in the Principal
      Terms, but it is meaningful as a concept aligned to accountability, which
      the Trust also seems to resist.  The ICANN community has spent nearly two
      years making ICANN more accountable. Is it ironic (or worse) to give the
      IANA IPR to an entity that is not willing to be accountable (at least not
      "with teeth") to the communities (other than the IETF)?
   - *The existing Trust Agreement also does not permit the Trust to
   transfer away any asset once it is owned by the Trust, so we cannot accept
   any term that anticipates such a transfer.*
      - How do we feel about this being a perpetual transfer to the IETF
      Trust, regardless of circumstances?  Note that the communities
were able to
      cause ICANN to give up the IANA IPR.  Is it ironic (or worse) to
give it to
      an organization where we have no such ability?
      - Technically, Jorge may be correct, so long as one assumes the IANA
      IPR will become "Trust Assets" under the Trust Agreement (which
states "except
      as otherwise expressly permitted hereunder, the Trustees shall not, and
      shall not have the right or power to, (i) exchange, distribute, assign,
      sell, transfer, renounce, or convey, the Trust Assets").  But, could they
      take on the IANA IPR as owner without making them "Trust Assets"?
   - *We realize that some people would prefer to amend some terms of the
   IETF Trust Agreement.  That may be possible in the future in order to
   accommodate some of the above worries.  But all changes have to go through
   the IETF consensus process, and there simply isn't time to do that this
   year.  Hence our agreement must work with the Trust as it currently exists.*
      - I'm not sure why this is being said.  We've been trying to work
      within the terms of the Trust Agreement for many months, so I'm not sure
      who "some people" are.
      - However, if this is an opening to make some future changes to the
      Trust Agreement, that would be worth exploring.

3.  *The Placeholder: We need the chart that Sidley is preparing so we can
analyze the issues in the most efficient manner*.

4.  *The (Important) Aside*.  I was tempted to ask whether we can expect
comments from the IETF (as distinguished from the IETF Trust) on these
documents -- or are the IETF and the Trust working as one here?  How does
the fit with the CWG's stated goal of "neutrality" (namely, no community
having any more influence over the holder of the IANA IPR than any other
community).  How do the agreements as envisioned by the IETF Trust fit with
the idea that we would solve "neutrality" issues "functionally" (through
the agreements) rather than "structurally" (through changing the IETF Trust
or establishing a new Trust)?

Greg






On Sun, Jul 31, 2016 at 3:08 PM, Greg Shatan <gregshatanipc at gmail.com>
wrote:

> All,
>
> I thought it would be helpful to prepare the attached redline comparisons
> of the IETF Trust's new version vs the CWG version.
>
> The IETF Trust only provided redlines against their own first draft.
> Typically, the redline provided with the latest draft shows changes to the
> immediate prior draft.  Presumably, the IETF Trust did not do this because
> they were responding to both the CWG and the RIR drafts.
>
> In any event, the attached comparisons show which changes in our drafts
> were deleted by the IETF Trust and which were retained by the IETF Trust.
> This cannot be ascertained from the redlines circulated by the IETF Trust.
>
> We should consider whether to circulate these redlines on the iana-ipr
> list. We may wish to do so if we are going to refer back to the changes
> that we made which were then deleted by the IETF Trust.
>
> Greg
>
> On Sat, Jul 30, 2016 at 4:43 PM, Hofheimer, Joshua T. <
> jhofheimer at sidley.com> wrote:
>
>> Jonathan, Lise and the Client Committee,
>>
>>
>>
>> See attached.  Sidley will prepare a table for your review that
>> highlights the key departures from our proposed drafts.
>>
>>
>>
>> Best regards,
>>
>> Josh
>>
>>
>>
>> *Joshua Hofheimer*
>>
>> *Sidley Austin LLP*
>>
>> *jhofheimer at sidley.com <jhofheimer at sidley.com>*
>>
>> *(213) 896-6061 <%28213%29%20896-6061> (LA direct)*
>>
>> *(650) 565-7561 <%28650%29%20565-7561> (Palo Alto direct)*
>>
>> *(323) 708-2405 <%28323%29%20708-2405> (cell)*
>>
>>
>>
>> *From:* iana-ipr-bounces at nro.net [mailto:iana-ipr-bounces at nro.net] *On
>> Behalf Of *Jorge Contreras
>> *Sent:* Saturday, July 30, 2016 10:03 AM
>> *To:* iana-ipr at nro.net
>> *Subject:* [Iana-ipr] IANA IPR Community Agreement and License Agreement
>> drafts
>>
>>
>>
>> Dear colleagues,
>>
>>
>>
>> We have attached for your review clean and redlined versions of the
>> Community Agreement and License Agreement, which have been marked against
>> the versions distributed on July 5.  We have inserted numerous
>>
>> comments in the marked version using the MS Word comment feature. These
>> comments are intended to address specific text or suggestions made by CWG,
>> RIR or IETF during the last round.
>>
>>
>>
>> In these candidate agreements, we have accepted a number of suggestions
>> both the operational communities. We know that everyone is anxious to get
>> these done, and many of the changes seem to us to be reasonable and in
>> keeping with the Trust’s responsibilities.
>>
>>
>>
>> What we have not accepted, and what we do not believe we can accept, is
>> any arrangement in which the Trust is subject to "approvals" by the
>> CCG.  We remain convinced that such acceptance would be contrary to
>>
>> the Trust's anticipated fiduciary responsibility as the holder of the
>> Marks, and the Trustees cannot responsibly expose the Trust to such a
>> threat.  We believe that any independent trust would face this problem.
>>
>>
>>
>> In addition, we do not think that, given the terms of our Trust
>> Agreement, the Trust is capable of acting as a "steward" for other
>> operational communities.  The existing Trust Agreement also does not permit
>> the Trust to transfer away any asset once it is owned by the Trust, so we
>> cannot accept any term that anticipates such a transfer.
>>
>>
>>
>> We realize that some people would prefer to amend some terms of the IETF
>> Trust Agreement.  That may be possible in the future in order to
>> accommodate some of the above worries.  But all changes have to go through
>> the IETF consensus process, and there simply isn't time to do that this
>> year.  Hence our agreement must work with the Trust as it currently exists.
>>
>>
>>
>> We hope that you will agree that we are making substantive and collegial
>> process here, and we hope you understand that the existing terms of the
>> Trust Agreement are a hard limit on what we may possibly
>>
>> do.  We look forward to additional comments and to a fruitful discussion
>> on our next call.
>>
>>
>>
>>
>>
>> Jorge L. Contreras
>>
>> Contreras Legal Strategy LLC
>>
>> 1711 Massachusetts Ave. NW, No. 710
>>
>> Washington, DC 20036
>>
>> contreraslegal at att.net
>>
>>
>>
>> The contents of this message may be attorney-client privileged and
>> confidential.  If you are not the intended recipient, please delete this
>> message immediately.
>>
>>
>>
>>
>>
>>
>> ****************************************************************************************************
>> This e-mail is sent by a law firm and may contain information that is
>> privileged or confidential.
>> If you are not the intended recipient, please delete the e-mail and any
>> attachments and notify us
>> immediately.
>>
>>
>> ****************************************************************************************************
>>
>> _______________________________________________
>> Cwg-client mailing list
>> Cwg-client at icann.org
>> https://mm.icann.org/mailman/listinfo/cwg-client
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-client/attachments/20160731/1ea105bc/attachment-0001.html>

More information about the Cwg-client mailing list