Hi Greg,

Thanks for taking the time to respond.

My understanding is that the objective of the principal terms was to establish a direction for the agreements, but not that any party had agreed to incorporate specific words from the terms into the agreements themselves. Indeed, if the objective of the principal terms had been to establish contractual language, we could have skipped the development of the terms altogether and jumped right into the development of the contractual language, which is what we are doing now.

Relatedly, if someone could point out the public posting of the final terms document, that would be helpful to ensure we’re all referencing the same version. I have been referencing <https://www.ietf.org/proceedings/95/slides/slides-95-ianaplan-0.pdf> as I can’t seem to find any reference point where all of the parties agreed that the terms document was settled. To my eye, both the first draft of the community agreement as circulated by the Trust and the edited version as circulated by the CWG are aligned with the spirit of the terms. So the space in which we need further discussion is actually not about discrepancies between the agreements and the terms, but between different ideas about how the terms can be fulfilled.

Now, as to the relationship between the CCG and the Trust, the CWG proposed the following language in 3.1:

"Accordingly, the IETF Trust agrees, as set forth below, to seek the advice and consent of the CCG with respect to all matters concerning the IANA Intellectual Property.”

So, this requires the Trust to seek the consent of the CCG about every matter relating to the IANA IPR. Interpreted strictly, this puts the CCG in control of the Trust’s actions related to the IANA IPR, because the Trust cannot take any action, no matter how trivial, without obtaining the consent of the CCG. Can the Trust send email to the IFO about the IPR without the CCG’s consent? Can the Trustees email each other about the IANA IPR without the CCG’s consent? Can the Trust renew the IANA domain registrations without CCG consent? If people wanted to interpret the edited provision in 3.1 strictly, I think they would have a basis to say no to all of these questions. And if that were the case, I imagine that the effectiveness of the Trust would be hamstrung, since it would essentially need to await the consensus of the CCG at every turn. This is why I wonder, if the intent is for the Trust to await the consent of the CCG on every matter, what the point of using the Trust is. The other sections I listed provide examples where approvals are required, but there is no limitation listed anywhere that I could find to draw a boundary around this consent provision in 3.1.

As to the notion of directing the Trust’s activities, I think it’s important to understand the nature of how the Trust operates. Trustees are volunteers who agree to commit their time to this task in service of the Internet. The work of the Trust is a part-time activity for which the nomcom every year works hard to find willing volunteers (via appointments to the IAOC and the IAB). Adding the IANA IPR responsibilities may increase that workload, although there is no practical reason why that increase should be substantial. However, under a scenario where the CCG requests volumes of new registrations in multiple different jurisdictions (3.4), together with the requirement for proactive politicing across all of those jurisdictions (3.5), the IANA-related work of the Trust could conceivably morph into a much more heavyweight set of duties. This could impact the Trust’s other responsibilities and the ability for the nomcom to find willing volunteers, and therefore the viability of the Trust itself. If the Trust was left with more discretion over its own activities than what the edited 3.4 allows, I think this would be less of a concern for the IETF community.

Regarding oversight and accountability, the CWG proposed the following language in 3.1:

"However, the IETF Trust recognizes that, solely with respect to its stewarship of the IANA Intellectual Property, it acts under the oversight of the Operational Communities and is accountable to those Operational Communities.”

In the scenarios that I can imagine, it is not really feasible to hold a Trustee accountable and have that act effect only the IANA IPR-related duties for that Trustee. For example, if the names community were to seek the removal of a nomcom-appointed Trustee, clearly that would have an effect on all of that Trustee’s duties, not just the ones related to IANA IPR. Furthermore, any mechanisms the CWG suggests to exercise oversight over the Trust and to hold it accountable would have to be consistent with existing nominations and recall procedures for the IAOC. Removing a nomcom-appointed Trustee, for example, would need to use the RFC 7437 procedures. As a result, I don’t know how to square the implications of this text with existing agreement in this group that the Trust will not be modified. Alternative or additional oversight and accountability procedures would necessarily need to obtain IETF consensus since they would affect the IETF Trustees.

Regards,

Alissa

On Jul 28, 2016, at 1:33 AM, Greg Shatan <gregshatanipc@gmail.com> wrote:

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.

Greg

On Wed, Jul 27, 2016 at 11:01 PM, Alissa Cooper <alissa@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 agreement,

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 examples cited.

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 Terms.

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 Principal Terms.

I do not believe that this reversal of roles

There is no "reversal of roles"; this is consistent with the design in the Principal Terms.

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 : 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 Terms agreement.

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 so important.

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 agreement,

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 entity.

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.

Greg

Alissa

On Jul 26, 2016, at 5:24 PM, Hofheimer, Joshua T. <jhofheimer@sidley.com> wrote:

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,
Josh

JOSHUA T. HOFHEIMER
Partner

SIDLEY AUSTIN LLP
+1 650 565 7561 (PA direct)
+1 213 896 6061 (LA direct)
+1 323 708 2405 (Cell)
jhofheimer@sidley.com
www.sidley.com

****************************************************************************************************
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.

****************************************************************************************************
<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 7-26-16.pdf>_______________________________________________
Iana-ipr mailing list
Iana-ipr@nro.net
https://www.nro.net/mailman/listinfo/iana-ipr

_______________________________________________
Iana-ipr mailing list
Iana-ipr@nro.net
https://www.nro.net/mailman/listinfo/iana-ipr