idnits 2.17.1 draft-arkko-iasa2-trust-rationale-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.arkko-iasa2-trust-update]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2018) is 2130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7437' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC5378' is defined on line 224, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) ** Obsolete normative reference: RFC 4371 (Obsoleted by RFC 8714) ** Obsolete normative reference: RFC 7437 (Obsoleted by RFC 8713) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational June 27, 2018 5 Expires: December 29, 2018 7 Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust 8 draft-arkko-iasa2-trust-rationale-00 10 Abstract 12 The IASA 2.0 changes will have an impact in the IETF Trust as well, 13 because members of the IET Administrative Oversight Committee (IAOC) 14 IAOC have also served as trustees of the IETF Trust. A proposal for 15 a minimal change regarding this has been provided separately in 16 [I-D.arkko-iasa2-trust-update]. 18 This companion memo provides some background on the details of the 19 current IETF Trust arrangements, explains the effect of the rules in 20 the founding documents during a transition to a new arrangement, and 21 provides a rationale for the update. 23 This memo is provided only for discussion. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 29, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. General Approach . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Changing the Way Trustees Are Selected . . . . . . . . . . . 3 63 5. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 7.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 The IASA 2.0 changes will have an impact in the IETF Trust as well 73 [RFC4071] [RFC4371] [I-D.hall-iasa2-struct]. This is because members 74 of the IET Administrative Oversight Committee (IAOC) IAOC have also 75 served as trustees of the IETF Trust. A proposal for a minimal 76 change regarding this has been provided separately in draft-arkko- 77 iasa2-trust-update. 79 This companion memo provides some background on the details of the 80 current IETF Trust arrangements, explains the effect of the rules in 81 the founding documents during a transition to a new arrangement, and 82 provides a rationale for the update. 84 This memo is provided only for discussion. There is no intention to 85 publish this memo as an RFC. 87 2. Background 89 The purpose of the IETF Trust is to acquire, hold, maintain, and 90 license certain existing and future intellectual property and other 91 property used in connection with the administration of the IETF 92 [RFC4371]. The intellectual property is, for instance, rights that 93 the IETF contributors grant for text in RFCs and Internet Drafts. 94 The IETF Trust also manages trademarks and domains such as "IETF" and 95 ietf.org. The IETF Trust is also serving the broader Internet 96 community by holding domains and trademarks associated with IANA 97 [RFC7979]. 99 The IETF Trust is a legal entity, registered in the Commonwealth of 100 Virginia [Trust-FD]. 102 Currently, the members of the IAOC are also serving as trustees of 103 the IETF Trust. The founding documents specify persons eligible to 104 become trustees as having to be then-current members of the IAOC 105 [Trust-FD]. The documents also specify that if for any reason there 106 are fewer than three individuals serving as trustees, then the IESG, 107 or the IESG's successor as the leadership of the IETF, shall appoint 108 one or more individuals to serve in a temporary capacity as 109 Trustee(s) until eligible persons can be found. 111 In the current system there are eight IAOC members. They are named 112 by the IETF Nominations Committee or NomCom (two members), IESG (one 113 member), IAB (one member), Internet Society Board of Trustees (one 114 member), along with three ex-officio members via their roles as IETF 115 Chair, Internet Society CEO, or IAB Chair. In addition, the IETF 116 Administrative Director (IAD) serves also as one of the trustees. 118 3. General Approach 120 There are two basic approaches to resolving the issue with the 121 trustees, if the IAOC ceases to exist. One could imagine merging all 122 IETF Trust functions in the new IASA structure and under the planned 123 new legal entity. This memo advocates a second approach where the 124 IETF Trust is kept independent. 126 The rationale for advocating the second approach is in part to avoid 127 causing too much change for the IETF Trust at a time when the IETF 128 administrative structure is ongoing major change. And, perhaps more 129 importantly, the IETF Trust and other administrative IETF process are 130 quite different. While very important, the IETF Trust is a very low 131 activity entity where changes, if any, are minimal and gradual. 132 There are no pressing issues, and the organisation serves the broader 133 Internet community than perhaps the day-to-day and more IETF 134 meetings-focused other parts of IASA. 136 4. Changing the Way Trustees Are Selected 138 At the time the trustees served both the IETF Trust and the IAOC, 139 many of the requirements for naming a particular group of people were 140 driven by the IAOC's requirements. For the IETF Trust in the new 141 model, some of those arrangements can be rethought, both in terms of 142 the number and source of the trustees, as well as the desired 143 qualifications and length of terms. 145 Several options are possible, of course. A newly designed naming 146 process could be devised. This memo argues for relatively limited 147 change, however, largely on the basis of the IETF Trust arrangements 148 generally working well, and on the relatively modest expected time 149 commitments combined with the need for very careful management of the 150 assets. 152 As a result, a smaller group of trustees appears sufficient. 154 In addition, the terms for the trustees selected from the IETF 155 community could be set to longer than the two year period typical of 156 other IETF bodies. 158 One could continue the practice of having the chairs and CEOs from 159 IETF, IAB, and Internet Society be trustees as well, but this may not 160 be necessary. In general, the tasks of the IETF Trust are well 161 defined, and while there is a need for coordination, it does not need 162 to be at the level of chairs or CEOs. 164 Given all this, one approach to the appointments is to have trustees 165 appointed by the Nominations Committee, IESG, and Internet Society 166 Board of Trustees (or the new legal entity, but the Internet Society 167 is perhaps more focused on the broad use of the IETF Trust assets and 168 not merely administrative aspects). 170 If the same principles continue to be used as are used in today's 171 appointments, then appointments performed by the Nominations 172 Committee need to be confirmed by another entity, which could be, for 173 instance, either the IESG or the IAB. 175 5. Transition 177 When new entity for IETF administration is set up, at some point the 178 IAOC will be discontinued. Fortunately, there's no pressing need to 179 change all the components at the same time. As discussed above 180 (Section 2), the IESG holds the ability to continue to name trustees. 181 Once the changes suggested in Section 4 are in place, the IETF Trust 182 will have management nominated in the usual manner, and the 183 exceptional IESG process is no longer needed. 185 6. Acknowledgements 187 The author would like to thank members of the earlier IASA 2.0 design 188 team, as well as Alissa Cooper, Ted Hardie, Andrew Sullivan, Brian 189 Carpenter, Lucy Lynch, and John Levine for interesting discussions in 190 this problem space. 192 7. References 194 7.1. Normative References 196 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 197 IETF Administrative Support Activity (IASA)", BCP 101, 198 RFC 4071, DOI 10.17487/RFC4071, April 2005, 199 . 201 [RFC4371] Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for 202 IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371, 203 January 2006, . 205 [RFC7437] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, 206 Confirmation, and Recall Process: Operation of the 207 Nominating and Recall Committees", BCP 10, RFC 7437, 208 DOI 10.17487/RFC7437, January 2015, . 211 7.2. Informative References 213 [I-D.arkko-iasa2-trust-update] 214 Arkko, J. and T. Hardie, "Update to the Selection of 215 Trustees for the IETF Trust", draft-arkko-iasa2-trust- 216 update-00 (work in progress), June 2018. 218 [I-D.hall-iasa2-struct] 219 Haberman, B., Hall, J., and J. Livingood, "Proposed 220 Structure of the IETF Administrative Support Activity 221 (IASA), Version 2.0 (for Discussion)", draft-hall- 222 iasa2-struct-04 (work in progress), June 2018. 224 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 225 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 226 DOI 10.17487/RFC5378, November 2008, . 229 [RFC7979] Lear, E., Ed. and R. Housley, Ed., "Response to the IANA 230 Stewardship Transition Coordination Group (ICG) Request 231 for Proposals on the IANA Protocol Parameters Registries", 232 RFC 7979, DOI 10.17487/RFC7979, August 2016, 233 . 235 [Trust-FD] 236 IETF Trust, , "Founding Documents", February 2014 237 (https://trustee.ietf.org/founding-documents.html). 239 Author's Address 241 Jari Arkko 242 Ericsson 243 Kauniainen 02700 244 Finland 246 Email: jari.arkko@piuha.net