Internet Engineering Task Force (IETF) J. ArkkoInternet-DraftRequest for Comments: 8715 EricssonIntended status:Category: InformationalOctober 11, 2018 Expires: April 14, 2019 Discussion of the IASA 2.0 Changes as They RelateFebruary 2020 ISSN: 2070-1721 IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trustdraft-ietf-iasa2-trust-rationale-03Abstract This documentis published to capturecaptures the rationale for the changes introduced in RFCNNNN (RFC Editor: please replace NNNN with the RFC number of [I-D.ietf-iasa2-trust-update]), Update8714, "Update to the Process for Selection of Trustees for the IETFTrust.Trust". At the time RFCNNNN8714 was published,IETF administrative structurethe changes("IASA 2.0")to the IETF Administrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF Trust because members of the IETF Administrative Oversight Committee (IAOC), which was being phased out, had served as Trustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update. Status of This Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draftthe IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documentsvalidapproved by the IESG are candidates fora maximumany level ofsix monthsInternet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 14, 2019.https://www.rfc-editor.org/info/rfc8715. Copyright Notice Copyright (c)20182020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents(http://trustee.ietf.org/license-info)(https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 22. Background. . . . . . . . . . . . . . . . . . . . . . . . . 33. General Approach. . . . . . . . . . . . . . . . . . . . . . 34. Changing the Way Trustees Are Selected. . . . . . . . . . . 45. Transition. . . . . . . . . . . . . . . . . . . . . . . . . 46. Security Considerations. . . . . . . . . . . . . . . . . . . 57. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 58.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 9.References. . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1.8.1. Normative References. . . . . . . . . . . . . . . . . . 5 9.2.8.2. Informative References. . . . . . . . . . . . . . . . . 5 Appendix A. Changes from Previous Versions . . . . . . . . . . . 6Acknowledgements Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 61. Introduction This documentis published to capturecaptures the rationale for the changes introduced in[I-D.ietf-iasa2-trust-update].[RFC8714]. At the time[I-D.ietf-iasa2-trust-update][RFC8714] was published,IETF administrative structurethe changes("IASA 2.0")to the IETF Administrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF Trust [RFC4071] [RFC4371][I-D.ietf-iasa2-struct].[RFC8711]. This is because members of the IETF Administrative Oversight Committee (IAOC), which was being phased out, had served as Trustees of the IETF Trust. A minimal change regarding the selection of thetrusteesTrustees is implemented by[I-D.ietf-iasa2-trust-update].[RFC8714]. This companion memo provides some background on the details of the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update. 2. Background The purpose of the IETF Trust is to acquire, hold, maintain, and license certain existing and future intellectual property and other property used in connection with the administration of the IETF[RFC4371].[RFC8714]. The intellectual property is, for instance, rights that the IETF contributors grant for text in RFCs and Internet-Drafts. The IETF Trust also manages trademarks such as "IETF" and domain names such as "ietf.org". The IETF Trust is also serving the broader Internet community by holding domains and trademarks associated with the Internet Assigned Numbers Authority (IANA) [RFC7979]. The IETF Trust is a legal entity, registered in the Commonwealth of Virginia [Trust-FD]. Previously, the members of the IAOC also served as ex officio Trustees of the IETF Trust. The founding documents specify persons eligible to becometrusteesTrustees as having to be then-current members of the IAOC [Trust-FD]. The documents also specify that if for any reason there are fewer than three individuals serving as Trustees, then the Internet Engineering Steering Group (IESG), or the IESG's successor as the leadership of the IETF, shall appoint one or more individuals to serve in a temporary capacity as Trustee(s) until eligible persons can be found. In the previoussystemsystem, there were eightIAOC members.voting members of the IAOC. Two were named by the IETF Nominating Committee (NomCom), one by theIESG,Internet Engineering Steering Group (IESG), one by the Internet Architecture Board (IAB), and one by the Internet Society (ISOC) Board of Trustees.In addition, thereThere were three ex officio members via their roles as IETF Chair, ISOC CEO, and IAB Chair. In addition, the IETF Administrative Director (IAD)servedwas a non-voting IAOC member who also served as one of thetrustees.Trustees. 3. General Approach There were two basic approaches to resolving the issue with thetrustees, whenTrustees once the IAOC ceased to exist. Onecould have imagined mergingapproach would be to merge all IETF Trust functions in the new IASA structure and under the new legal entity.ThisHowever, this memoadvocatedadvocates a second approach where the IETF Trust is kept independent. The rationale for advocating the second approachisis, inpartpart, to minimize changes to the IETF Trust while the IETF's administrative structure is undergoing major change. In addition, the IETF Trust and other administrative IETF processes are quite different. While very important, the IETF Trust is a low-activity entity where changes are minimal and gradual, and there are no pressing issues. 4. Changing the Way Trustees Are SelectedAt the time whenWhen thetrustees servedTrustees were serving on both the IETF Trust and the IAOC, many of the requirements for naming a particular group of people were driven by the IAOC's requirements. For the IETF Trust in the new model, some of those arrangements wereable to berethought, both in terms of the number and source of thetrustees,Trustees, as well as the desired qualifications and length of terms. Several options were possible, of course. A newly designednamingselection process could have beendevised. The argument here isdevised, but in this document we argue fora relativelylimitedchange, however,change based largely on thebasis offact that a) the IETF Trust arrangements worked generallyworkingwell,and onb) therelatively modestexpected timecommitments combined withcommitment is expected to be modest, and c) the assets needforvery carefulmanagement of the assets.management. As a result, a smaller group oftrusteesTrustees appeared sufficient. In addition, the terms set for thetrusteesTrustees selected from the IETF community could beset tolonger than thetwo yeartwo-year period typical of other IETF bodies. One could have continued the practice of having the chairs and CEOs from the IETF, IAB, and Internet Society betrusteesTrustees as well, but this may not be necessary. In general, the tasks of the IETF Trust are well defined, and while there is a need for coordination, it does not need to be at the level of chairs or CEOs. Given all this, one approach was to havetrusteesTrustees appointed by the NomCom, the IESG, and the ISOC Board of Trustees. (One might also have considered the IETF Administration LLC legal entity instead of the Internet Society for thisrole. Butrole, but the Internet Society is perhaps more suitable for therole,role given their focus on the broad use of the IETF Trust assets and not merely administrativeaspects).aspects.) If the same principleswould continue to be used as wereusedinfor previousappointments,appointments continued to be used, then appointments performed by the NomCom would need to be confirmed by anotherentity, whichentity. This could be, for instance, either the IESG or the IAB. The IESG had previously been the confirming body for the IAOC, so it has been retained in that role for thetrustees.Trustees. 5. Transition When the new entity for the IETF Administration LLC was set up, the IAOC was expected to be discontinued soon thereafter. Fortunately, there was no pressing need to change all the components of the IAOC and its dependent organizations at the same time. As discussedabove (Section 2),in Section 2, the IESG holds the ability to continue to nametrustees. And onceTrustees. Once the updated procedures were in place, the IETF Trust had its management nominated in the usual manner, and theexceptional IESGIESG's exception process was no longer needed. 6. Security Considerations This memo has no security implications for the Internet. 7. IANA Considerations Thismemo requestsdocument has noaction from IANA. 9.IANA actions. 8. References9.1.8.1. Normative References [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, <https://www.rfc-editor.org/info/rfc4071>. [RFC4371] Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371, January 2006, <https://www.rfc-editor.org/info/rfc4371>.9.2.8.2. Informative References[I-D.ietf-iasa2-struct] Haberman, B., Hall, J., and J. Livingood, "Record of Proposed Structure of the IETF Administrative Support Activity (IASA), Version 2.0", draft-ietf-iasa2-struct-06 (work in progress), September 2018. [I-D.ietf-iasa2-trust-update] Arkko, J. and T. Hardie, "Update to the Selection of Trustees for the IETF Trust", draft-ietf-iasa2-trust- update-00 (work in progress), September 2018.[RFC7979] Lear, E., Ed. and R. Housley, Ed., "Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries", RFC 7979, DOI 10.17487/RFC7979, August 2016, <https://www.rfc-editor.org/info/rfc7979>.[Trust-FD][RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of the IETFTrust, , "Founding Documents", February 2014 (https://trustee.ietf.org/founding-documents.html). Appendix A. Changes from Previous VersionsAdministrative Support Activity, Version 2.0", BCP 101, RFCEditor: Please remove this section upon publication. The version draft-ietf-iasa2-trust-rationale-03.txt made some editorial corrections. The version draft-ietf-iasa2-trust-rationale-02.txt made some editorial corrections. The version draft-ietf-iasa2-trust-rationale-01.txt includes changes relating to last call comments. The changes are 1) indication of why this document is being published 2) updates8711, DOI 10.17487/RFC8711, February 2020, <https://www.rfc-editor.org/info/rfc8711>. [RFC8714] Arkko, J. and T. Hardie, "Update toreferences, 3)theadditionProcess for Selection ofempty security and IANA consideration sections, 4) editorial changes necessaryTrustees fora document that is also read later, and not just used in discussions at this time. The version draft-ietf-iasa2-trust-rationale-00.txt includes only editorial and language updates. The version draft-arkko-iasa2-trust-rationale-00.txt wastheinitial version. 8.IETF Trust", BCP 101, RFC 8714, DOI 10.17487/RFC8714, February 2020, <https://www.rfc-editor.org/info/rfc8714>. [Trust-FD] IETF Trust, "Founding Documents", <https://trustee.ietf.org/founding-documents.html>. Acknowledgements The author would like to thank other members of the earlier IASA 2.0 designteam who wereteam: Brian Haberman, Eric Rescorla, Jason Livingood, Joe Hall, and Leslie Daigle. Theauthorsauthor would also like to thank Alissa Cooper, Ted Hardie, Andrew Sullivan, Brian Carpenter, Lucy Lynch, and John Levine for interesting discussions in this problem space, and Adrian Farrel, Tero Kivinen, Russ Housley, Benjamin Kaduk, AdamRoachRoach, and Meral Shirazipour for careful review. Author's Address Jari Arkko Ericsson FI-02700 Kauniainen02700Finland Email: jari.arkko@piuha.net