wdiff rfc8523v1.txt rfc8523.txt

Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 8523 Ericsson
Category: Informational January March 2019
ISSN: 2070-1721

Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust

Abstract

This document is published to capture captures the rationale for the changes introduced in
RFC 8524, "Update to the Process for Selection of Trustees for the
IETF Trust".

At the time RFC 8524 was published, IETF administrative structure
changes ("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

This document is not an Internet Standards Track specification; it is
published for informational purposes.

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). Not all documents
approved by the IESG are candidates for any level of Internet
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 be obtained at
https://www.rfc-editor.org/info/rfc8523.

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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. General Approach . . . . . . . . . . . . . . . . . . . . . . 3
4. Changing the Way Trustees Are Selected . . . . . . . . . . . 3
5. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6

1. Introduction

This document is published to capture captures the rationale for the changes introduced in
[RFC8524].

At the time [RFC8524] was published, IETF administrative structure
changes ("IASA 2.0") had an impact on the IETF Trust [RFC4071]
[RFC4371] [IASA2]. 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 the trustees Trustees is implemented by [RFC8524].

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]. 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 become trustees Trustees 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 previous system, there were eight IAOC members. Two were
named by the IETF Nominating Committee (NomCom), one by the Internet
Engineering Steering Group (IESG), one by the Internet Architecture
Board (IAB), and one by the Internet Society (ISOC) Board of
Trustees. There were three ex officio members via their roles as
IETF Chair, ISOC CEO, and IAB Chair. In addition, the IETF
Administrative Director (IAD) served also as one of the trustees. Trustees.

3. General Approach

There were two basic approaches to resolving the issue with the
trustees
Trustees once the IAOC ceased to exist. One approach would be to
merge all IETF Trust functions in the new IASA structure and under
the new legal entity. However, this memo advocates a second approach
where the IETF Trust is kept independent.

The rationale for advocating the second approach is, in part, 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 Selected

When the trustees Trustees 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 were rethought, both in terms of
the number and source of the trustees, Trustees, as well as the desired
qualifications and length of terms.

Several options were possible, of course. A newly designed naming selection
process could have been devised. The argument here is devised, but in this document we argue for a
relatively
limited change, however, change based largely on the basis of fact that a) the IETF Trust
arrangements worked generally working well, and on b) the relatively
modest expected time commitments combined with commitment
is expected to be modest, and c) the assets need for very careful management of the assets.
management.

As a result, a smaller group of trustees Trustees appeared sufficient.

In addition, the terms set for the trustees Trustees selected from the IETF
community could be longer than the two 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 be trustees Trustees 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 have trustees Trustees 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 this role, but the Internet Society is
perhaps more suitable for the role given their focus on the broad use
of the IETF Trust assets and not merely administrative aspects.)

If the same principles used for previous appointments continued to be
used, then appointments performed by the NomCom would need to be
confirmed by another entity. 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 the trustees. 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 discussed in
Section 2, the IESG holds the ability to continue to name trustees. Trustees.
Once the updated procedures were in place, the IETF Trust had its
management nominated in the usual manner, and the exceptional IESG
process was no longer needed.

6. Security Considerations

This memo has no security implications for the Internet.

7. IANA Considerations

This document has no IANA actions.

8. References

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

8.2. Informative References

[IASA2] Haberman, B., Hall, J., and J. Livingood, "Structure of
the IETF Administrative Support Activity, Version 2.0",
Work in Progress, draft-ietf-iasa2-rfc4071bis-04, January
2019.

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

[RFC8524] Arkko, J. and T. Hardie, "Update to the Process for
Selection of Trustees for the IETF Trust", RFC 8524,
DOI 10.17487/RFC8524, January 2019.

[Trust-FD]
IETF Trust, "Founding Documents", February 2014,
<https://trustee.ietf.org/founding-documents.html>.

Acknowledgements

The author would like to thank other members of the earlier IASA 2.0
design team: Brian Haberman, Eric Rescorla, Jason Livingood, Joe
Hall, and Leslie Daigle. The author 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, Adam
Roach, and Meral Shirazipour for careful review.

Author's Address

Jari Arkko
Ericsson
Kauniainen 02700
Finland

Email: jari.arkko@piuha.net