[client com] [Iana-ipr] CWG Comments to IANA IPR License and Community Agreement
gregshatanipc at gmail.com
Thu Jul 28 08:33:09 UTC 2016
Alissa and all,
My detailed responses are inline below. In general, I disagree with these
comments and also find them somewhat troubling. The "Proposed Principal
Terms of IANA Intellectual Property Agreements" document was worked out
among representatives of all the communities and the IETF Trust over many
months, and these comments seem to ignore or contradict many aspects of
that document, which formed the design and basis for preparing the actual
Community Agreement and License Agreement. The revised drafts circulated
by the CWG try to follow the "Principal Terms" in concept and spirit, as
well as in the specifics. A number of the sections cited as causing
concern are faithful to and in some cases almost verbatim from sections of
the Principal Terms. I think the overall characterization of the
relationship of the CCG and the Trust as one where the Trust in these
comments is incorrect and overheated. The IETF Trust, as steward of the
IANA IPR, has certain duties and obligations to the CCG (as representative
of the communities) and the relationship involves a level of oversight by
and accountability to the CCG; however, under these agreements, it has the
primary right to decide how to carry out its duties, consistent with
certain standards set out in the agreements and subject to advice from and
reasonable approvals by the CCG. Although colorful, it is completely
incorrect to paint a picture of the Trust as an "empty vessel" "subjugated"
by the CWG to the will of an "independent power base" for which it is a
mere "pass-through." Appeals to rhetoric tend to be counterproductive,
because they inflame the emotions without illuminating the issues and often
(as here) mask the lack of substance in the underlying claims. The
detailed analysis below makes this quite clear.
We need to be moving toward the concepts in the Principal Terms, not away
from them, if we are going to meet our deadlines. That is the common basis
we all developed. I encourage a more constructive engagement with the
current drafts of these Agreements, and hope that others will take that
road. This is an iterative process, but we can't iterate too many times.
On Wed, Jul 27, 2016 at 11:01 PM, Alissa Cooper <alissa at cooperw.in> wrote:
> Josh, all,
> As Andrew previously noted, I am here participating on this list as an
> IETF community participant. I make my comments below with that hat on.
> As an IETF community participant, I am concerned with a number of the
> changes proposed by the CWG, the sum of which appear to entirely subjugate
> the IETF Trust to the will of the CCG. As drafted in the original community
There is no "original community agreement." There is a *first draft* of
the community agreement, from the IETF Trust, sent along with the (entirely
appropriate) caveat from Andrew Sullivan that these were "early draft
proposals that I have previously mentioned we'd gotten to work on. These
are intended to be starting points, because someone had to draft
something. Nobody intends to suggest that these are some hard position of
the IETF Trust."
> the CCG was designed to be an advisory body to the IETF Trust.
The CCG was designed in the "Proposed Principal Terms of IANA
Intellectual Property Agreements," which was jointly produced by all
parties. The community agreement needs to implement this design. The CCG
was not designed in the Principal Terms to be merely advisory. The
Principal Terms clearly state "The CCG will provide advice *and approvals*
to the Trust on matters pertaining to the IANA IPR, and the representatives
of each community will provide advice *and approvals *to the Trust on
matters pertaining uniquely to that community." (Section 2(b) of the
Principal Terms, emphasis added)
> A number of changes suggested by the CWG (in 2.1, 3.1, 3.2c, 3.2d, 3.3,
> and 3.4 of the community agreement and 4.3 and 4.4 of the license
> agreement, at a minimum) change the CCG from an advisory body to a
> controlling one that directs the activities of the IETF Trust
This significantly overstates (and unfortunately, misstates) what is in
the agreements. In almost all cases, the IETF Trust acts on its own
initiative, consistent with general principles laid out in the agreements.
There are only a few instances where anything close to "directing the
activities of the IETF Trust" takes place. Let's look at the specific
2.1 says the CCG "will provide guidance, advice and approvals" to the IETF
Trust; this is consistent with the Principal Terms and does not say the CCG
will "direct the activities" of the Trust.
3.1 is rather long to summarize, but it covers the IETF Trust's
"stewardship" (as stated in the first draft agreement) of the IANA IPR and
says that the IETF Trust will be under the oversight of and accountable to
the Operational Communities with regard to the IANA IPR. Again, this is
consistent with the Principal Terms, which says that the Community
Agreement will specify "the Trust’s commitments, duties and obligations to
each Community" (Section B.2) and how each community "would hold the Trust
accountable for its performance." (Section B)
3.2(c) does have one very specific instance where the CCG or a community
directs the activities of the Trust: to terminate the License Agreement
with an IANA Operator. This is entirely consistent with the right of each
community to choose its IANA Operator; any other arrangement would fly in
the face of this right. Furthermore, this is consistent with the Principal
Terms. (Section C.2(d))
3.2(d) covers the Trust entering into a License Agreement with a
community's (or communities') chosen new IANA Operator. It is entirely
logical that the community should be able to request that the Trust enter
into an agreement with new Operator. But the communities do not control
the Trust; the Trust only has an obligation to use good faith efforts to
enter into the Agreement; it cannot be forced to enter into an Agreement.
Since the new IANA Operator has been chosen by the community, presumably
after a thorough vetting process and under agreements negotiated between
that community and the Operator, there is obviously a high degree of
interest in putting the License Agreement in place. The License Agreement
should not be the tail wagging the dog -- standing in the way of a
community's ability to have the IANA Operator of its choice. Nonetheless,
the Trust can choose not to enter into the agreement if it is unacceptable,
but only after an escalation procedure which will hopefully resolve the
IETF's concerns. Consistent with the community's right to choose its IANA
Operator, the community then has the right to commence a *second* escalation
process in Section 3.3; only if that process is unacceptable does the
community have the right to transfer the IANA IPR so that it may use the
IANA Operator of its choice, even though the Trust could not come to an
agreement with that Operator. Again, anything different would have the
tail wagging the dog.
3.3 has already been touched on above. It also has an escalation process
triggered by material breach of the Community Agreement or a License
Agreement which could end with a transfer of the IANA IPR only if the
escalation is unsuccessful and the material breach is unresolved. While
this is obviously a last resort, it's consistent with the Trust's role a
steward of the IANA IPR. There is nothing in the Principal Terms (or in
any other document I can recall) that designates the Trust as the holder in
perpetuity of the IANA IPR. The IPR is being transferred to the Trust due
to decisions of the communities and (under exceptional circumstances) it
must be transferable if decided by those communities.
3.4 covers maintenance of the IPR and new applications for the IPR.
Maintenance is to be consistent with best practices in the IP management
field, while new applications are to be initiated as requested by the
communities. This is almost verbatim from Section C.2.b of the Principal
4.4 of the License Agreement is almost identical to 3.4 of the Community
Agreement (above) and is again consistent with the Principal Terms.
4.3 of the License Agreement covers enforcement of the IPR. The
communities do not have the right to direct the Trust to enforce the IPR --
the Trust specifically has "the right but not the obligation" to do so. It
does say that the CCG or relevant community reps need to approve any
decisions regarding enforcement of the IPR -- but again this is almost
verbatim from the Principal Terms (Section C.3(f)).
> and prevents the IETF Trust from acting without the consent or approval of
> the CCG.
As demonstrated above, this is largely not the case, and where it is
that's consistent with what was intended by all the parties in the
> I do not believe that this reversal of roles
There is no "reversal of roles"; this is consistent with the design in the
> is in the interest of the IETF community (or of the other operational
> communities, frankly).
I see no reason any of this is not in the interest of the operational
communities. To the extent this is not in the interest of the IETF because
of its particular relationship to the IETF Trust, this would be
inconsistent with the core principal of "neutrality" of the holder of the
IANA IPR vis a vis any of the operational communities.
> As we all know, the IETF Trust has a number of responsibilities, and
> protection of the IANA IPR would be one additional responsibility to add to
> its current list. If the CCG is empowered to control the activities of the
> IETF Trust to the extent contemplated by the changes listed above, even if
> only in the context of the IANA IPR, I would be very concerned about its
> ability, time, and resources left available to continue to carry out its
> existing responsibilities.
I don't see any factual basis to make this statement. The power to
initiate maintenance, policing and enforcement of the IANA IPR is entirely
in the hands of the Trust. The CCG or the communities have no power to
direct the Trust to do anything in those fields (unless failure to do so
would be a material breach). This statement might inspire concern in
someone who has not read the current drafts of the agreements, and thus I
think it's important to emphasize there's no basis for those concerns.
> Furthermore, since the same Trustees would be responsible for all of the
> IETF Trust’s work, exercise of the provision in 3.1 that puts the IETF
> Trust under the “oversight” of and “accountable to" the operational
> communities could put the Trust into conflict with its existing governing
> documents and oversight and accountability procedures.
The community oversight and accountability covers only its activities
relating to the IANA IPR, which was contemplated by the Principal Terms and
is consistent with the Trust's stewardship role. We've consulted with
counsel and they so no reason this would conflict with the existing
governing documents. Based on what we have learned about existing
oversight and accountability procedures of the Trust, I see no reason to
predict a conflict with those procedures.
> More broadly, if it really is the intention of the CWG to subjugate the
> IETF Trust to the CCG in this way,
The use of the term "subjugate" brings us into the realm of overheated
rhetoric. Merriam-Webster defines "subjugate" as:
1: to bring under control and governance as a subject
<http://www.merriam-webster.com/dictionary/subject> : conquer
2: to make submissive : subdue
Conjuring up a vision that the CWG is "conquering" and "subduing" the IETF
Trust is both unhelpful and untrue. Oversight and accountability are the
cornerstone of the entire IANA Transition and related accountability
measures. The Principal Terms clearly contemplate that the Trust will have
certain duties and obligations to the communities. Duties and obligations
are found in every agreement. In no way is the Trust being "subjugated" by
the CWG or the communities generally. There's nothing untoward or
shocking here other than the use of the word "subjugate."
> I don’t see what the justification would be to have the IETF Trust
> involved with the IANA IPR at all.
This statement is based on a false premise (that the Trust is being
"subjugated"). In any event, I don't see that this is a question of
"justification"; the IETF Trust volunteered (or perhaps, was volunteered by
the numbers community) to take this on, for the good of the communities and
the Internet generally.
> If all matters concerning the IANA IPR require the consent of the CCG
> (Sec. 3.1), what is the point of using the IETF Trust? It effectively
> becomes a pass-through for CCG decisions.
This is not a logical statement. The decisions are not made by the CCG;
they are made by the Trust, subject to the approval of the CCG (not to be
unreasonably withheld). The CCG has almost no ability to make decisions;
it is reactive to the Trust (except where there is a change in an IANA
Operator or a material breach by the Trust). An approval right absolutely
does not equate to a "pass-through." (another rhetorical flourish)
> I believe the IETF community fully supports the notion of the CCG as an
> advisory body to the IETF Trust
As demonstrated above, this is not what came out of the extensive work of
the IANA IPR collaborative team over many months, in which IETF
representatives took an active role, and which resulted in the Principal
> and recognizes that it is important for the IETF Trust to act in
> accordance with all three communities’ wishes.
This is inconsistent with the idea that the CCG (which represents the
wishes of the communities) would be merely advisory. If it's important
for the IETF Trust to act in accordance with the communities' wishes,
there's no reason to shy away from an obligation to do so. Virtually all
of the time, I would expect the communities and the Trust to be aligned,
and for the Trust to act consistent with the communities' wishes in the
ordinary course of their relationship. However, it is precisely in those
instances where the Trust would deviate from the communities' wishes that
the structure of these agreements as envisioned in the Principal Terms is
> But if what the CWG wanted was for a body independent of the IETF Trust to
> control all decisions about the IANA IPR, it should have proposed the
> proper independent creation of such a body a long time ago.
As co-chair of the ICG, I think you have far more insight into how we got
to where we are than this statement indicates. In any event, I think this
mischaracterizes the CWG's position and the relationship of the CCG and
the Trust, and ignores the work of the IANA collaborative group as
reflected in the Principal Terms. Equating an approval right with
"control" is incorrect and inappropriate. In most instances, the
agreements contemplate a good deal of discretion and initiative by the
Trust. The communities do not control all decisions -- the communities'
role is one of oversight and of approvals in certain circumstances. Again,
this is consistent with the Principal Terms.
> Contorting the CCG,
This is not a "contortion" (another rhetorical flourish). This is how the
CCG was designed.
> a group that exists only by virtue of being defined in the community
I'm not sure why this matters. In any event, this is what was
contemplated by the CWG proposal as embodied in the ICG proposal, and then
by the IANA collaborative group: that no structural changes would be made
in the IETF Trust and that the relationship of the Trust to the communities
would be defined by agreements. Using these decisions to denigrate the CCG
is unfounded and unhelpful.
> into an independent power base
It is not an "independent power base" (more rhetoric), which brings to
mind unaccountability and free-lancing. Nothing could be further from the
truth -- it is a conduit for the the communities, and is thus entirely
*dependent* on those communities for whatever narrowly-defined "powers" it
has under the agreeements.
> seems illegitimate from a governance perspective
We absolutely considered governance issues, and governance experts have
been involved in the process working with the CWG. There do not appear to
be any concerns that this set-up is "illegitimate" (more rhetoric).
> and is not in the interests of the IETF community.
You've provided no sound reasons this is not in the interests of the IETF
community. This again raises concerns about the "neutrality" of the IETF
Trust as relates to the IETF. We have operated with the understanding that
the IETF Trust will be neutral in its relationship to the IETF as it
concerns the IANA IPR. I hope that has not been misplaced.
> When the CWG agreed to the proposal from the numbers community to have the
> IANA IPR transferred to an entity independent of the IANA functions
> operator, CWG members’ concerns were focused on the “neutrality” of the
This is a reductive oversimplification of the CWG's concerns. In any
event, "neutrality" included the concept that the holder of the IPR should
have the same relationship and level of influence with each of the three
communities. Without the safeguards set up here, the IETF Trust will
naturally not be neutral due to its relationship to the IETF (there's
nothing sinister about that relationship, of course; it's just not
consistent with neutrality without the work that's been done in the
Principal Terms as reflected in the current drafts of the Agreements.
> The changes listed above appear to be concerned with something else
> altogether — effectively rendering the IETF Trust an empty vessel to be
> controlled by the CCG.
I think this is an unfair and incorrect summation of the set-up. If
you've read this far, you will have seen it said before, but for
completeness (and to counteract the final rhetorical flourish of the "empty
vessel"), I'll continue (with apologies for redundancy). The IETF Trust
would in no way be an empty vessel. The day-to-day decisions relating to
the IPR rest with the Trust, as do the less day-to-day decisions relating
to enforcement of the IPR. The CCG cannot initiate any actions or
decisions to be undertaken by the CCG (except in the limited case where
there's a change of Operator). As contemplated by the Principal Terms, the
CCG has approval rights over certain aspects of the IPR management, and
this approval does not rest with CCG in their sole discretion; rather, it
cannot be unreasonably withheld. In certain very limited cases, related to
the separation from one IANA operator and the retention of the other, the
CCG has the right to direct the termination of the exiting Operator and can
request (but not direct) that the Trust enter into a License with the new
Operator. The Trust retains the ultimate right to decide whether it can
reach terms with that new Operator acceptable to the Trust. None of this
is consistent with calling the Trust an "empty vessel" and approval rights
(plus a single instance where the Trust can be directed to terminate an
agreement with an exiting Operator) do not in any way translate into a
Trust "controlled" by the CCG. The current drafts circulated by the CWG
are consistent with Principal Terms (more so than the first draft, but
that's only to be expected in this type of drafting process) and we should
be moving forward toward finalizing the agreements rather than moving
backwards to a prior draft of the agreement. While I expect some need for
refinement of the current draft, I think this draft represents considerable
progress and we need to close off issues as quickly as we can.
> On Jul 26, 2016, at 5:24 PM, Hofheimer, Joshua T. <jhofheimer at sidley.com>
> Thank you to all the participants on the IANA-IPR call earlier today.
> Attached please find comments by the CWG to the IANA IPR License and the
> Community Agreement, clean and marked to show changes from the originals
> forwarded to CWG. Please do not hesitate to contact us with any questions
> and we look forward to our discussion next week.
> Best regards,
> *JOSHUA T. HOFHEIMER*
> *SIDLEY AUSTIN LLP*
> +1 650 565 7561 (PA direct)
> +1 213 896 6061 (LA direct)
> +1 323 708 2405 (Cell)
> jhofheimer at sidley.com
> *[image: SIDLEY]*
> 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
> <Community-Agreement, CWG Comments 7.26.16.docx><License-Agreement-IANA-IPR,
> CWG Comments 7-26-16.doc><Redline - Community-Agreement, CWG Comments
> 7.26.16.pdf><Redline - License-Agreement-IANA-IPR, CWG Comments
> Iana-ipr mailing list
> Iana-ipr at nro.net
> Iana-ipr mailing list
> Iana-ipr at nro.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cwg-client