wdiff rfc8714v1.txt rfc8714.txt

Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 8524 8714 Ericsson
BCP: 101 T. Hardie
Obsoletes: 4371 February 2019 January 2020
Category: Best Current Practice
ISSN: 2070-1721

Update to the Process for Selection of Trustees for the IETF Trust

Abstract

This memo updates the process for selection of trustees Trustees for the IETF
Trust. Previously, the Internet IETF Administrative Oversight Committee
(IAOC) members also acted as trustees, Trustees, but the IAOC has been
eliminated as part of an update to the structure of the Internet IETF
Administrative Support Activity (IASA). This memo specifies that the
trustees
Trustees shall be selected separately.

This memo obsoletes RFC 4371. The changes relate only to the
selection of trustees. Trustees. All other aspects of the IETF Trust remain as
they are today.

Status of This Memo

This memo documents an Internet Best Current Practice.

This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8524.
https://www.rfc-editor.org/info/rfc8714.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IETF Trust . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Selection of Trustees . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 4
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5

1. Introduction

This memo obsoletes RFC 4371. [RFC4371]. The changes relate only to the
selection of trustees. Trustees. All other aspects of the IETF Trust remain as
they are today. Section 2 copies the definition as it was in RFC
4371,
[RFC4371], only leaving out the part about trustee Trustee selection and
adding a reference to the IETF Trust website.

For a discussion of why this change is needed and a rationale for
these specific changes, see [RFC8523]. [RFC8715].

2. IETF Trust

A Trust ("the IETF Trust") has been formed for the purpose of
acquiring, holding, maintaining, and licensing certain existing and
future intellectual property and other property used in connection
with the administration of the IETF. The Trust was formed by the
signatures of its Settlors and initial Trustees. The Settlors, who
contributed initial intellectual property to the Trust, were ISOC and
the Corporation for National Research Initiatives. The Beneficiary
of the IETF Trust is the IETF as a whole.

Further details of the IETF Trust may be found at the IETF Trust's
website, <https://trustee.ietf.org/>.

3. Selection of Trustees

This document revises the original Trustee selection procedures
defined in [RFC4071] and [RFC4371] to eliminate the requirement that
trustees
Trustees be drawn from the members of the IAOC.

In this newly revised IETF Trust structure, there will be five
Trustees. Three shall be appointed by the IETF Nominating Committee
(NomCom) and confirmed by the Internet Engineering Steering Group
(IESG), one shall be appointed by the IESG, and one shall be
appointed by the Internet Society (ISOC) Board of Trustees. The
appointments by the IESG and the ISOC Board of Trustees do not
require confirmation.

The IETF Trust Chair informs the nominating committee of the Trustee
positions to be reviewed. The IETF Trust will provide a summary of
the expertise desired of the Trustee candidates to each appointing
body.

A change to the Trust Agreement is required to put this change into
effect, and this document requests that the current Trustees make
this change at the earliest convenient time and no later than the end
of the 104th IETF meeting in March 2019.

The terms of the appointed trustees Trustees from the IETF NomCom shall be
three years. The initial selection shall be one, two, and three year
terms in order to initially stagger the terms. The other
appointments by the IESG and the ISOC Board of Trustees shall be two
year terms, with the initial terms being one and two years,
respectively. The goal of the staggered initial terms is to minimize
potential Trustee turnover in any single year. To maintain the
staggered terms, each appointing body may, at its discretion, appoint
Trustees for shorter terms as needed in exceptional situations, e.g.,
for mid-term vacancies or when an appointment is not ready by the
time of the first IETF meeting of the year.

Once the initial trustee Trustee selections according to the procedures in
this document are complete, and at each subsequent annual meeting of
the IETF Trust (once new trustees Trustees are seated), the trustees Trustees shall
elect one trustee Trustee to serve as IETF Trust Chair by a majority vote of
the IETF Trust.

Trustees appointed by the IETF NomCom may be recalled according to
the recall process described in [BCP10]. Trustees appointed by the
IESG or by the ISOC Board of Directors may be recalled by the
appointing body. For appointments made by the IESG, the IESG is
expected to run an open selection process and to consider the
necessary skill set and conflicts of interest as part of that
process.

4. Security Considerations

This memo has no security implications for the Internet.

5. IANA Considerations

This document has no IANA actions.

6. References

6.1. Normative References

[BCP10] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
Ed., "IAB, IESG, IETF Trust, and IAOC IETF LLC Selection,
Confirmation, and Recall Process: Operation of the IETF
Nominating and Recall Committees", BCP 10, RFC 7437,
January 2015, <https://www.rfc-editor.org/info/bcp10>.

Dawkins, S., "IAB, IESG, and IAOC Selection, Confirmation,
and Recall Process: IAOC Advisor for the Nominating
Committee", BCP 10, RFC 8318, 8713,
January 2018. 2020, <https://rfc-editor.org/info/bcp10>.

[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>.

6.2. Informative References

[RFC8523]

[RFC8715] Arkko, J., "Discussion of the IASA 2.0 Changes as They
Relate to the IETF Trust", RFC 8523, 8715, DOI 10.17487/RFC8523,
February 2019, <https://www.rfc-editor.org/info/rfc8523>. 10.17487/RFC8715,
January 2020, <https://rfc-editor.org/info/rfc8715>.

Acknowledgements

The authors would like to thank members of the earlier IASA 2.0
design team: Brian Haberman, Eric Rescorla, Jari Arkko, Jason
Livingood, Joe Hall, and Leslie Daigle. The authors would also like
to thank Alissa Cooper, Andrew Sullivan, Brian Carpenter, Lucy Lynch,
and John Levine for interesting discussions in this problem space.
The authors would also like to thank Russ Housley, Bob Hinden, Scott
Mansfield, Alexey Melnikov, Suresh Krishnan, Mirja Kuhlewind, Kühlewind, Ben
Campbell, Spencer Dawkins, Martin Vigoreux, Benjamin Kaduk, and
Adrian Farrel for careful review. Finally, the authors would like to
thank the authors of [RFC4371], as the text from that RFC remains in
this document.

Authors' Addresses

Jari Arkko
Ericsson
FI-02700 Kauniainen 02700
Finland

Email: jari.arkko@piuha.net

Ted Hardie

Email: ted.ietf@gmail.com