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.

1: to bring under control and governance as a subject http://www.merriam-webster.com/dictionary/subject : conquer http://www.merriam-webster.com/dictionary/conquer 2.

2: to make submissive : subdue http://www.merriam-webster.com/dictionary/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 b​e 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 *[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 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

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 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 mailto: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 http://www.merriam-webster.com/dictionary/subject : conquer http://www.merriam-webster.com/dictionary/conquer 2: to make submissive : subdue http://www.merriam-webster.com/dictionary/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 b​e 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 mailto: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 tel:%2B1%20650%20565%207561 (PA direct) +1 213 896 6061 tel:%2B1%20213%20896%206061 (LA direct) +1 323 708 2405 tel:%2B1%20323%20708%202405 (Cell) jhofheimer@sidley.com mailto:jhofheimer@sidley.com www.sidley.com http://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 mailto:Iana-ipr@nro.net https://www.nro.net/mailman/listinfo/iana-ipr https://www.nro.net/mailman/listinfo/iana-ipr

---

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

Dear all,

The RIRs are currently reviewing CWG comments and intend to send our feedback to the list. In the meantime we would like to highlight that, given the very tight time frame, the IETF trust in its current structure is the only pragmatic solution.

Any other alternative that can not be implemented within this time frame would jeopardize the success of the IANA transition and cannot be considered.

With regards to CCG's role, we strongly support the view that it should have a role that would be in line with IETF Trust's current structure and accountability. We appreciate IETF Trust's inability to amend its structure within the given time frame and we urge all parties to focus their efforts on building upon the existing situation.

Finally we would like to thank all parties for their commitment to the success of the IANA transition.

Kind regards, Athina

On 28/07/16 10:50, Greg Shatan wrote:

Alan,

I have to disagree, for reasons stated at length in my response to Alissa. The Principal Terms clearly state that the CCG has a role that goes beyond mere advice, and I think some of that was lost in the first draft. I also think it's incorrect to characterize the approval rights that the CCG has (and which are expressly contemplated in the Principal Terms) with regard to actions that the Trust wishes to take as a "mechanism for controlling the Trust." As drafted, the Trust initiates all of the actions it will take in connection with the IANA IPR. As long as these actions are consistent with the views of the communities, the Trust's actions will not be constrained at all. In no case is the Trust being "controlled" (except arguably when it is directed to terminate an IANA operator being terminated by an operational community, and I think that is entirely understandable). I am somewhat surprised that you would characterize even that critical action as intended to be "informational." Clearly it has to be more than "informing," which carries with it no element of how one might choose to respond to that "information."

The numbers community made two key points regarding the IPR in the transition proposal: "IPR related to the provision of the IANA services remains with the community" and that these assets must be "used in a nondiscriminatory manner for the benefit of the entire community." In addition to being consistent with the Principal Terms, I believe these drafts are well aligned with these two concepts.

Rather than going on at any more length, I'll refer to my prior email for more detailed thoughts.

Greg

On Thu, Jul 28, 2016 at 3:59 AM, Alan Barrett <alan.barrett@afrinic.net mailto:alan.barrett@afrinic.net> wrote:

> On 27 Jul 2016, at 04:24, Hofheimer, Joshua T. <jhofheimer@sidley.com <mailto: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.

I have read these documents, and I am concerned that they appear to
constrain the actions of the IETF Trust far beyond what was
contemplated in the draft principal terms document which we all
reviewed.

I believe that the CCG was intended to provide advie to the Trust,
and to provide a channel for informing the Trust when an operational
community changes their IANA operator, but not to be a mechanism for
controlling the Trust.

Alan Barrett


_______________________________________________
Iana-ipr mailing list
Iana-ipr@nro.net <mailto: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

Jorge and Russ,

Thank you, it's useful to see the IETF's comments on the CWG draft.

However, what I asked for were the IETF's comments on the IETF Trust's initial draft. Jorge mentioned those comments in a prior email, and I was responding to that.

Greg

On Mon, Aug 1, 2016 at 1:56 PM, Jorge Contreras contreraslegal@att.net wrote:

Russ – thanks for sharing with the list.

Greg – this responds to your request of last night relating to the IETF comments.

All – Russ provided these comments to the Trust on 7/27 and they have already been reflected, along with the CWG and RIR suggestions, in the revised drafts distributed to everyone on 7/30.

From: iana-ipr-bounces@nro.net on behalf of Russ Housley < housley@vigilsec.com> Date: Monday, August 1, 2016 at 11:28 AM To: iana-ipr@nro.net Subject: [Iana-ipr] CWG Comments to IANA IPR License and Community Agreement

A few of us on on this list to represent the IETF community. Here are my thoughts, wearing that hat, on the CWG proposed changes to the two agreement documents.

IANA COMMUNITY AGREEMENT

I like the add red definitions to Section 1, but I think they made 1.9 too hard. Instead, they should do the following, which provides a definition for IANA Domain Name, which is otherwise not defined:

IANA Trademark: The trademarks set forth on Exhibit A, together with the registrations therefor, all common law and other rights in such trademarks, and all goodwill accruing from the use thereof, throughout the world; the list in Exhibit A may be amended from time to time by mutual agreement of the IETF Trust and the Operational Communities.

IANA Domain Name: The Internet domain names set forth on Exhibit A, collectively or individually as the context may require; the list in Exhibit A may be amended from time to time by mutual agreement of the IETF Trust and the Operational Communities.

IANA Intellectual Property: The IANA Trademark and the IANA Domain Name.

In 3.1, I am very concerned about: "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. Further, the IETF Trust recognizes that the IANA Intellectual Property is held by the IETF Trust solely for the purpose of being licensed to the IANA Operator(s) selected by, under the oversight of and accountable to the Operational Communities.” As I have already stated on this list, the CCG is not an oversight body.

Also in 3.1, I suggest adding a few words to a sentence that the CWG did not change much: "Finally, the IETF Trust recognizes the interest of the Operational Communities in ensuring a reliable and robust Internet names, Internet numbers, and Internet protocol parameters functions.

I like the change that was proposed for 3.2a and 3.2b.

In 3.2c, please change “Protocol Service” to “Protocol Parameter Service”.

In 3.2d(i), additional words are needed to appropriately constrain the "shall act in a manner consistent with the advice of the CCG”. At a minimum, it needs to be constrained to advice in IANA Intellectual Property, and nothing else.

Also in 3.2d(i), requiring written approval of potential license agreements goes too far. As written, if ICANN wanted to host and IETF meeting again, the IETF Trust could not authorize the IETF Logo to be put on a t-shirt without CCG written approval.

Also in 3.2d(i), I do not think this clause should say anything about mediation. And, if we do, the cost should be paid by the Operational Communities and the IANA Operator.

Also in 3.2d(i), in the last sentence, change “reasonable discretion” back to “sole discretion”.

Drop 3.2d(ii). I think that this test will be divisive among the operational communities.

I like the change to 3.2d(iii).

In 3.2e, what does “shall coordinate communicating” mean? It seems really vague to me.

I think that 3.2g is in conflict with 3.2d. I read 3.2g to mean that the IETF Trust cannot dispose of these assets, ever. I read 3.2d to mean that the Operational Communities can direct the IETF Trust to transfer them to a new home.

I think 3.3 has the same conflict with 3.2g.

I think 5.2 has the same conflict with 3.2g.

I do not think it is acceptable that 3.4 requires the IETF Trust to “seek new registrations” based on CCG instructions. The old language was much better.

I think that 3.5 goes too far, but I have no problem with the addition of: "IETF Trust shall at all times act consistently with its obligations to the Operational Communities as steward of the IANA Intellectual Property.” Also, this seems like an odd place in the document to make such a commitment.

Also in 3.5, do we really want to talk about how the damages and recoveries will be divided? I think it should be deleted. At any rate, it seems to conflict with 6.2.

I do not understand the phrase added to the end of 4(d). It seems to mean that the Operational Community cannot be held liable for the actions of the IANA Operator that they select. Is that right? If so, why does it belong in this document?

I have no problem with the removal of the section on Publicity. It seems that someone is going to have to make some noise whenever these agreements are signed.

LICENSE AGREEMENT

I think the definitions should align with my suggestions regarding the Community Agreement.

In 3.1, I think we need to remove exclusive. Each operational community can pick a different operator, so there could be three operators that need access to iana.org. If we leave this as it is, then a new agreement will be needed if any of the operational communities makes a change.

in 3.4, it seems like ICANN wants to sublicense to PTI. Based on the text in the Community Agreement, I expected the IETF Trust to give PTI a license directly. It seems too easy to lose control if both are possible.

In 4.3, do we really need to talk about how the damages and recoveries will be divided?

Also in 4.3, I have the same concerns about this text as in the Community Agreement.

In 4.4, I have the same concerns about the Operational Communities being able to expand the scope without limit.

In 6.3, I have the same concerns regarding arbitration as I do with the Community Agreement.

In 6.4, we should remove the sublicense stuff. Let’s have all licenses be given by the IETF Trust directly.

In 8.1, we should stick to Virginia, that is where the IETF Trust lives.

I have no problem with the removal of the section on Publicity.

Russ

On Jul 26, 2016, at 8: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

_______________________________________________ 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