<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Alissa and all,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">My detailed responses are inline below.  In general, I disagree with these comments and also find them somewhat troubling.  The &quot;Proposed Principal Terms ​of IANA Intellectual Property Agreements&quot; 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 &quot;Principal Terms&quot; 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 &quot;empty vessel&quot; &quot;subjugated&quot; by the CWG to the will of an &quot;independent power base&quot; for which it is a mere &quot;pass-through.&quot;  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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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&#39;t iterate too many times.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Greg</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 27, 2016 at 11:01 PM, Alissa Cooper <span dir="ltr">&lt;<a href="mailto:alissa@cooperw.in" target="_blank">alissa@cooperw.in</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>Josh, all,</div><div><br></div><div>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.<br><br>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, </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​There is no &quot;original community agreement.&quot;  There is a <i>first draft</i> of the community agreement, from the IETF Trust, sent along with the (entirely appropriate) caveat from Andrew Sullivan that these were &quot;early draft proposals that I have previously mentioned we&#39;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.&quot;</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>the CCG was designed to be an advisory body to the IETF Trust. </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​The CCG was designed in the &quot;Proposed Principal Terms ​of IANA Intellectual Property Agreements,&quot; 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 &quot;The CCG will provide advice <i>and approvals</i> to the Trust on matters pertaining to the IANA IPR, and the representatives of each community will provide advice <i>and approvals </i>to the Trust on matters pertaining uniquely to that community.&quot; (Section 2(b) of the Principal Terms, emphasis added) </div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>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 </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​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 &quot;directing the activities of the IETF Trust&quot; takes place.  Let&#39;s look at the specific examples cited. </div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">2.1 says the CCG &quot;will provide guidance, advice and approvals&quot; to the IETF Trust; this is consistent with the Principal Terms and does not say the CCG will &quot;direct the activities&quot; of the Trust. </div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">3.1 is rather long to summarize, but it covers the IETF Trust&#39;s &quot;stewardship&quot; (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 &quot;the Trust’s commitments, duties and obligations to each Community&quot; (Section B.2) and how each community &quot;would hold the Trust accountable for its performance.&quot; (Section B) </div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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))</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">3.2(d) covers the Trust entering into a License Agreement with a community&#39;s (or communities&#39;) 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&#39;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&#39;s concerns.  Consistent with the community&#39;s right to choose its IANA Operator, the community then has the right to commence a <u>second</u> 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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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&#39;s consistent with the Trust&#39;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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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 &quot;the right but not the obligation&quot; 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)).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>and prevents the IETF Trust from acting without the consent or approval of the CCG.<br></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​As demonstrated above, this is largely not the case, and where it is that&#39;s consistent with what was intended by all the parties in the Principal Terms.​</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br>I do not believe that this reversal of roles </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​There is no &quot;reversal of roles&quot;; this is consistent with the design in the Principal Terms.  ​</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>is in the interest of the IETF community (or of the other operational communities, frankly). </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​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 &quot;neutrality&quot; of the holder of the IANA IPR vis a vis any of the operational communities.​</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>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. </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​I don&#39;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&#39;s important to emphasize there&#39;s no basis for those concerns.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>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&quot; the operational communities could put the Trust into conflict with its existing governing documents and oversight and accountability procedures.<br></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​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&#39;s stewardship role.  We&#39;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.​</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br>More broadly, if it really is the intention of the CWG to subjugate the IETF Trust to the CCG in this way, </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​The use of the term &quot;subjugate&quot; brings us into the realm of overheated rhetoric.  Merriam-Webster defines &quot;subjugate&quot; as:</div><div class="gmail_default" style="font-family:verdana,sans-serif">​<br></div><ol class="gmail-definition-list" style="margin:0px 0px 1.25em;padding:0px;list-style-type:none;width:auto;color:rgb(0,0,0);font-family:lato,helvetica,arial,sans-serif;font-size:medium"><li style="margin:0px 0px 1.1875em;padding:0px;letter-spacing:0.094em;list-style-position:outside;list-style-type:none"><p class="gmail-definition-inner-item gmail-with-sense" style="margin:0px;padding:0px 0px 0px 2.1875em;color:rgb(59,62,65);font-family:&quot;open sans&quot;,helvetica,arial,sans-serif;font-size:1em;clear:both;letter-spacing:0.04em;line-height:1.5em"><span class="gmail-sense" style="margin:0px;padding:0px;font-style:inherit;font-weight:bold">1</span><span class="gmail-intro-colon" style="font-size:1em;letter-spacing:0.04em;line-height:1.5em;margin:0px 5px 0px 0px;padding:0px;display:initial;font-weight:bold">:</span><span style="font-size:1em;letter-spacing:0.04em;line-height:1.5em">  to bring under control and governance as a </span><a href="http://www.merriam-webster.com/dictionary/subject" class="gmail-formulaic" style="font-size:1em;letter-spacing:0.04em;line-height:1.5em;margin:0px;padding:0px;color:rgb(174,0,21);outline:0px;text-decoration:none;background-color:transparent">subject</a><span style="font-size:1em;letter-spacing:0.04em;line-height:1.5em"> </span><span class="gmail-intro-colon" style="font-size:1em;letter-spacing:0.04em;line-height:1.5em;margin:0px 5px 0px 0px;padding:0px;display:initial;font-weight:bold">:</span><span style="font-size:1em;letter-spacing:0.04em;line-height:1.5em">  </span><a href="http://www.merriam-webster.com/dictionary/conquer" class="gmail-sx-link gmail-sc" style="font-size:1em;letter-spacing:0.04em;line-height:1.5em;margin:0px;padding:0px;color:rgb(174,0,21);outline:0px;text-decoration:none;font-variant:small-caps;background-color:transparent">conquer</a></p></li><li style="margin:0px;padding:0px;letter-spacing:0.094em;list-style-position:outside;list-style-type:none"><p class="gmail-definition-inner-item gmail-with-sense" style="margin:0px;padding:0px 0px 0px 2.1875em;color:rgb(59,62,65);font-family:&quot;open sans&quot;,helvetica,arial,sans-serif;font-size:1em;clear:both;letter-spacing:0.04em;line-height:1.5em"><span class="gmail-sense" style="margin:0px;padding:0px;font-style:inherit;font-weight:bold">2</span><span class="gmail-intro-colon" style="font-size:1em;letter-spacing:0.04em;line-height:1.5em;margin:0px 5px 0px 0px;padding:0px;display:initial;font-weight:bold">:</span><span style="font-size:1em;letter-spacing:0.04em;line-height:1.5em">  to make submissive </span><span class="gmail-intro-colon" style="font-size:1em;letter-spacing:0.04em;line-height:1.5em;margin:0px 5px 0px 0px;padding:0px;display:initial;font-weight:bold">:</span><span style="font-size:1em;letter-spacing:0.04em;line-height:1.5em">  </span><a href="http://www.merriam-webster.com/dictionary/subdue" class="gmail-sx-link gmail-sc" style="font-size:1em;letter-spacing:0.04em;line-height:1.5em;margin:0px;padding:0px;color:rgb(174,0,21);outline:0px;text-decoration:none;font-variant:small-caps;background-color:transparent">subdue</a></p></li></ol><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​Conjuring up a vision that the CWG is &quot;conquering&quot; and &quot;subduing&quot; 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 &quot;subjugated&quot; by the CWG or the communities generally.​  There&#39;s nothing untoward or shocking here other than the use of the word &quot;subjugate.&quot;</div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>I don’t see what the justification would be to have the IETF Trust involved with the IANA IPR at all. </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​This statement is based on a false premise (that the Trust is being &quot;subjugated&quot;).  In any event, I don&#39;t see that this is a question of &quot;justification&quot;; 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.  ​</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>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.<br></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​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 &quot;pass-through.&quot; (another rhetorical flourish)</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br>I believe the IETF community fully supports the notion of the CCG as an advisory body to the IETF Trust </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​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.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>and recognizes that it is important for the IETF Trust to act in accordance with all three communities’ wishes. </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​This is inconsistent with the idea that the CCG (which represents the wishes of the communities) would b​e merely advisory.  If it&#39;s important for the IETF Trust to act in accordance with the communities&#39; wishes, there&#39;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&#39; wishes in the ordinary course of their relationship.  However, it is precisely in those instances where the Trust would deviate from the communities&#39; wishes that the structure of these agreements as envisioned in the Principal Terms is so important.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>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. </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​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&#39;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 &quot;control&quot; 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&#39; role is one of oversight and of approvals in certain circumstances.  Again, this is consistent with the Principal Terms.​</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>Contorting the CCG, </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​This is not a &quot;contortion&quot; (another rhetorical flourish).  This is how the CCG was designed.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>a group that exists only by virtue of being defined in the community agreement, </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​I&#39;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.​</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>into an independent power base </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​It is not an &quot;independent power base&quot; (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 <u>dependent</u> on those communities for whatever ​narrowly-defined &quot;powers&quot; it has under the agreeements.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:arial,sans-serif"> </span></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>seems illegitimate from a governance perspective </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​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 &quot;illegitimate&quot; (more rhetoric).​</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>and is not in the interests of the IETF community.</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​You&#39;ve provided no sound reasons this is not in the interests of the IETF community.  This again raises concerns about the &quot;neutrality&quot; 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.​</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div> </div><div><br></div><div>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. </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​This is a reductive oversimplification of the CWG&#39;s concerns.  In any event, &quot;neutrality&quot; 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&#39;s nothing sinister about that relationship, of course; it&#39;s just not consistent with neutrality without the work that&#39;s been done in the Principal Terms as reflected in the current drafts of the Agreements.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>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.</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​I think this is an unfair and incorrect summation of the set-up.  If you&#39;ve read this far, you will have seen it said before, but for completeness (and to counteract the final rhetorical flourish of the &quot;empty vessel&quot;), I&#39;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&#39;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 &quot;empty vessel&quot; 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 &quot;controlled&quot; by the CCG.  The current drafts circulated by the CWG are consistent with Principal Terms (more so than the first draft, but that&#39;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.</div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">Greg ​</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>  <br><br>Alissa</div></div><div><br></div><br><div><blockquote type="cite"><div><div class="gmail-h5"><div>On Jul 26, 2016, at 5:24 PM, Hofheimer, Joshua T. &lt;<a href="mailto:jhofheimer@sidley.com" target="_blank">jhofheimer@sidley.com</a>&gt; wrote:</div><br></div></div><div><div><div class="gmail-h5"><p style="margin:0cm 0cm 0pt;font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></p><div style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif">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.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif">Best regards,<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif">Josh<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><b><span style="font-size:10pt;font-family:arial,sans-serif">JOSHUA T. HOFHEIMER</span></b><span style="font-size:12pt;font-family:&quot;times new roman&quot;,serif"><br></span><span style="font-size:9pt;font-family:arial,sans-serif">Partner<br><br><b>SIDLEY AUSTIN LLP</b><br><a href="tel:%2B1%20650%20565%207561" value="+16505657561" target="_blank">+1 650 565 7561</a> (PA direct)<br><a href="tel:%2B1%20213%20896%206061" value="+12138966061" target="_blank">+1 213 896 6061</a> (LA direct)<br><a href="tel:%2B1%20323%20708%202405" value="+13237082405" target="_blank">+1 323 708 2405</a> (Cell)</span><span style="font-size:12pt;font-family:&quot;times new roman&quot;,serif"><br></span><span style="font-size:9pt;font-family:arial,sans-serif"><a href="mailto:jhofheimer@sidley.com" title="Click to send email to Hofheimer, Joshua T." style="color:purple;text-decoration:underline" target="_blank"><span style="color:blue">jhofheimer@sidley.com</span></a></span><span style="font-size:12pt;font-family:&quot;times new roman&quot;,serif"><br><a href="http://www.sidley.com/" title="www.sidley.com" style="color:purple;text-decoration:underline" target="_blank"><span style="font-size:9pt;font-family:arial,sans-serif;color:blue">www.sidley.com</span></a></span><span style="font-size:9pt;font-family:arial,sans-serif"><u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><b><span style="font-size:10pt;font-family:arial,sans-serif"><img border="0" width="126" height="54" src="http://www2.sidley.com/files/upload/signatures/SIDLEY_150-AUTOSIG.png" alt="SIDLEY"></span></b><span style="font-size:10pt;font-family:&quot;times new roman&quot;,serif"><u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><span style="font-size:10pt"> </span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></div></div><div style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><p style="margin:0cm 0cm 0pt;font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> </p><p style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">****************************************************************************************************<br>This e-mail is sent by a law firm and may contain information that is privileged or confidential.<br>If you are not the intended recipient, please delete the e-mail and any attachments and notify us<br>immediately.<br><br>****************************************************************************************************</p></div></div><span>&lt;Community-Agreement, CWG Comments 7.26.16.docx&gt;</span><span>&lt;License-Agreement-IANA-IPR, CWG Comments 7-26-16.doc&gt;</span><span>&lt;Redline - Community-Agreement, CWG Comments 7.26.16.pdf&gt;</span><span>&lt;Redline - License-Agreement-IANA-IPR, CWG Comments 7-26-16.pdf&gt;</span><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">_______________________________________________</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">Iana-ipr mailing list</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:Iana-ipr@nro.net" style="color:purple;text-decoration:underline;font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Iana-ipr@nro.net</a><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://www.nro.net/mailman/listinfo/iana-ipr" style="color:purple;text-decoration:underline;font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://www.nro.net/mailman/listinfo/iana-ipr</a></div></blockquote></div><br></div><br>_______________________________________________<br>
Iana-ipr mailing list<br>
<a href="mailto:Iana-ipr@nro.net">Iana-ipr@nro.net</a><br>
<a href="https://www.nro.net/mailman/listinfo/iana-ipr" rel="noreferrer" target="_blank">https://www.nro.net/mailman/listinfo/iana-ipr</a><br>
<br></blockquote></div><br></div></div>