idnits 2.17.1 draft-ietf-iasa2-trust-rationale-01.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 abstract seems to contain references ([I-D.ietf-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 (October 5, 2018) is 2027 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7437' is defined on line 221, but no explicit reference was found in the text == Unused Reference: 'RFC5378' is defined on line 240, 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) == Outdated reference: A later version (-03) exists of draft-ietf-iasa2-trust-update-00 Summary: 4 errors (**), 0 flaws (~~), 4 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 October 5, 2018 5 Expires: April 8, 2019 7 Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust 8 draft-ietf-iasa2-trust-rationale-01 10 Abstract 12 This document is published to capture the rationale for the changes 13 introduced in RFC NNNN (RFC Editor: please replace NNNN with the RFC 14 number of [I-D.ietf-iasa2-trust-update]), Update to the Process for 15 Selection of Trustees for the IETF Trust. 17 At the time RFC NNNN was published, IETF administrative structure 18 changes ("IASA 2.0") had an impact on the IETF Trust because members 19 of the IETF Administrative Oversight Committee (IAOC) IAOC, which was 20 being phased out, had served as Trustees of the IETF Trust. This 21 document provides background on the past IETF Trust arrangements, 22 explains the effect of the rules in the founding documents during the 23 transition to the new arrangement, and provides a rationale for the 24 update. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 8, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. General Approach . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Changing the Way Trustees Are Selected . . . . . . . . . . . 4 64 5. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 9.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Appendix A. Changes from Previous Versions . . . . . . . . . . . 6 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 This document is published to capture the rationale for the changes 77 introduced in [I-D.ietf-iasa2-trust-update]. 79 At the time [I-D.ietf-iasa2-trust-update] was published, IETF 80 administrative structure changes ("IASA 2.0") had an impact on the 81 IETF Trust [RFC4071] [RFC4371] [I-D.ietf-iasa2-struct]. This is 82 because members of the IETF's Internet Administrative Oversight 83 Committee (IAOC), which was being phased out, had served as Trustees 84 of the IETF Trust. A minimal change regarding the selection of the 85 trustees is implemented by [I-D.ietf-iasa2-trust-update]. 87 This companion memo provides some background on the details of the 88 past IETF Trust arrangements, explains the effect of the rules in the 89 founding documents during the transition to the new arrangement, and 90 provides a rationale for the update. 92 2. Background 94 The purpose of the Internet Engineering Task Force (IETF) Trust is to 95 acquire, hold, maintain, and license certain existing and future 96 intellectual property and other property used in connection with the 97 administration of the IETF [RFC4371]. The intellectual property is, 98 for instance, rights that the IETF contributors grant for text in 99 RFCs and Internet-Drafts. The IETF Trust also manages trademarks 100 such as "IETF" and domain names such as "ietf.org". The IETF Trust 101 is also serving the broader Internet community by holding domains and 102 trademarks associated with Internet Assigned Numbers Authority (IANA) 103 [RFC7979]. 105 The IETF Trust is a legal entity, registered in the Commonwealth of 106 Virginia [Trust-FD]. 108 Previously, the members of the IAOC also serve as ex officio Trustees 109 of the IETF Trust. The founding documents specify persons eligible 110 to become trustees as having to be then-current members of the IAOC 111 [Trust-FD]. The documents also specify that if for any reason there 112 are fewer than three individuals serving as Trustees, then the 113 Internet Engineering Steering Group (IESG), or the IESG's successor 114 as the leadership of the IETF, shall appoint one or more individuals 115 to serve in a temporary capacity as Trustee(s) until eligible persons 116 can be found. 118 In the previous system there were eight IAOC members. Two were named 119 by the IETF Nominating Committee (NomCom), one by the IESG, one by 120 the Internet Architecture Board (IAB), and one by the Internet 121 Society (ISOC) Board of Trustees. In addition, there were three ex- 122 officio members via their roles as IETF Chair, ISOC CEO, and IAB 123 Chair. In addition, the IETF Administrative Director (IAD) served 124 also as one of the trustees. 126 3. General Approach 128 There were two basic approaches to resolving the issue with the 129 trustees, when the IAOC ceased to exist. One could imagine merging 130 all IETF Trust functions in the new IASA structure and under the new 131 legal entity. This memo advocated a second approach where the IETF 132 Trust is kept independent. 134 The rationale for advocating the second approach is in part to 135 minimize changes to the IETF Trust while the IETF's administrative 136 structure is undergoing major change. In addition, the IETF Trust 137 and other administrative IETF process are quite different. While 138 very important, the IETF Trust is a low activity entity where changes 139 are minimal and gradual, and there are no pressing issues. 141 4. Changing the Way Trustees Are Selected 143 At the time when the trustees served on both the IETF Trust and the 144 IAOC, many of the requirements for naming a particular group of 145 people were driven by the IAOC's requirements. For the IETF Trust in 146 the new model, some of those arrangements were able to be rethought, 147 both in terms of the number and source of the trustees, as well as 148 the desired qualifications and length of terms. 150 Several options were possible, of course. A newly designed naming 151 process could have been devised. The argument here is for a 152 relatively limited change, however, largely on the basis of the IETF 153 Trust arrangements generally working well, and on the relatively 154 modest expected time commitments combined with the need for very 155 careful management of the assets. 157 As a result, a smaller group of trustees appeared sufficient. 159 In addition, the terms for the trustees selected from the IETF 160 community could be set to longer than the two year period typical of 161 other IETF bodies. 163 One could have continued the practice of having the chairs and CEOs 164 from IETF, IAB, and Internet Society be trustees as well, but this 165 may not be necessary. In general, the tasks of the IETF Trust are 166 well defined, and while there is a need for coordination, it does not 167 need to be at the level of chairs or CEOs. 169 Given all this, one approach was to have trustees appointed by the 170 NomCom, IESG, and ISOC Board of Trustees, or even the new IETF 171 Administration LLC legal entity (but the Internet Society is perhaps 172 more focused on the broad use of the IETF Trust assets and not merely 173 administrative aspects). 175 If the same principles would continue to be used as were used in 176 previous appointments, then appointments performed by the NomCom 177 would need to be confirmed by another entity, which could be, for 178 instance, either the IESG or the IAB. 180 5. Transition 182 When the new entity for IETF Administration LLC was set up, the IAOC 183 was expected to be discontinued soon thereafter. Fortunately, there 184 was no pressing need to change all the components at the same time. 185 As discussed above (Section 2), the IESG holds the ability to 186 continue to name trustees. And once the updated procedures were in 187 place, the IETF Trust has its management nominated in the usual 188 manner, and the exceptional IESG process is no longer needed. 190 6. Security Considerations 192 This memo has no security implications for the Internet. 194 7. IANA Considerations 196 This memo requests no action from IANA. 198 8. Acknowledgements 200 The author would like to thank other members of the earlier IASA 2.0 201 design team who were Brian Haberman, Eric Rescorla, Jason Livingood, 202 Joe Hall, and Leslie Daigle. The authors would also like to thank 203 Alissa Cooper, Ted Hardie, Andrew Sullivan, Brian Carpenter, Lucy 204 Lynch, and John Levine for interesting discussions in this problem 205 space, and Tero Kivinen, Russ Housley, and Meral Shirazipour for 206 careful review. 208 9. References 210 9.1. Normative References 212 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 213 IETF Administrative Support Activity (IASA)", BCP 101, 214 RFC 4071, DOI 10.17487/RFC4071, April 2005, 215 . 217 [RFC4371] Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for 218 IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371, 219 January 2006, . 221 [RFC7437] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, 222 Confirmation, and Recall Process: Operation of the 223 Nominating and Recall Committees", BCP 10, RFC 7437, 224 DOI 10.17487/RFC7437, January 2015, . 227 9.2. Informative References 229 [I-D.ietf-iasa2-struct] 230 Haberman, B., Hall, J., and J. Livingood, "Record of 231 Proposed Structure of the IETF Administrative Support 232 Activity (IASA), Version 2.0", draft-ietf-iasa2-struct-06 233 (work in progress), September 2018. 235 [I-D.ietf-iasa2-trust-update] 236 Arkko, J. and T. Hardie, "Update to the Selection of 237 Trustees for the IETF Trust", draft-ietf-iasa2-trust- 238 update-00 (work in progress), September 2018. 240 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 241 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 242 DOI 10.17487/RFC5378, November 2008, . 245 [RFC7979] Lear, E., Ed. and R. Housley, Ed., "Response to the IANA 246 Stewardship Transition Coordination Group (ICG) Request 247 for Proposals on the IANA Protocol Parameters Registries", 248 RFC 7979, DOI 10.17487/RFC7979, August 2016, 249 . 251 [Trust-FD] 252 IETF Trust, , "Founding Documents", February 2014 253 (https://trustee.ietf.org/founding-documents.html). 255 Appendix A. Changes from Previous Versions 257 RFC Editor: Please remove this section upon publication. 259 The version draft-ietf-iasa2-trust-rationale-01.txt includes changes 260 relating to last call comments. The changes are 1) indication of why 261 this document is being published 2) updates to references, 3) the 262 addition of empty security and IANA consideration sections, 4) 263 editorial changes necessary for a document that is also read later, 264 and not just used in discussions at this time. 266 The version draft-ietf-iasa2-trust-rationale-00.txt includes only 267 editorial and language updates. 269 The version draft-arkko-iasa2-trust-rationale-00.txt was the initial 270 version. 272 Author's Address 274 Jari Arkko 275 Ericsson 276 Kauniainen 02700 277 Finland 279 Email: jari.arkko@piuha.net