]>

1770 Massachusetts Ave, Ste 322 Cambridge MA 02140 USA +1 617 245 1457 john-ietf@jck.com

General IASA2 In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the 2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes.

In 2018, the IETF began the transition to a new administrative structure, and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure . Key IASA 2.0 changes have been specified in a series of documents, including changes to the IETF Trust , the rationale for it , a new defining document for the IETF Administration LLC (informally called the "IETF LLC" or just "the LLC" in places in this document and elsewhere) and adjustments to the procedures for nominations and selections for relevant positions . In addition to more substantive changes that are described in those and other documents, the IASA 2.0 structure changes several position titles and organizational relationships that are referenced in other documents. Rather than reissue those documents individually, this document provides a unified update to them. This document updates RFCs 2028, 2418, 3005, 3710, 5377, 6702, and 7500 (citations in context below) to make those terminology and related changes. For clarity, it also obsoletes RFCs 3716 and 3929 which were Experimental or Informational documents that are no longer relevant (see ). The sections that follow identify the details of the relevant documents and the required changes. Note in Draft: This document lists changes that the WG may choose to process as standalone replacement documents instead. The relevant sections are provided to speed things along should it decide to not do that.

Some documents that discuss the IETF Trust or its relationship to the community describe it, or the Trustees, in relation to the IAOC. That connection must be eliminated to reflect the new IASA 2.0 structure. This document applies that change to the following: RFC 5377, Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents. These changes require dropping "made up of the members of the IAOC [RFC4371]" after "board of trustees" in the first paragraph of Section 1 and "which is made up of the members of the IAOC, as described in [RFC4071] and [RFC4371]" in the first paragraph of Section 3. RFC Editor please note that the bracketed strings above are quoted text, not references.

All mentions of the IETF Administrative Oversight Committee (IAOC) that are not removed by the prior section, shall be updated and replaced by the IETF Administration LLC (IETF-LLC). This is necessary because the IAOC is phased out under the IASA 2.0 structure. This document applies that change to the following: RFC 4844, the RFC Series and RFC Editor Sections 3.3, 3.4, and 4. RFC 7500 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries, Section 3.4. This means that the IETF LLC, the body responsible for IETF administrative and financial matters, maintains an SLA with the current registry operator, the Internet Corporation for Assigned Names and Numbers (ICANN). It also means that both the Internet Architecture Board (IAB) and the IETF LLC are accountable to the larger Internet community for the IANA registries.

Under the IASA 2.0 structure, most of the responsibilities of the former position of IETF Executive Director been assigned to a new position (or at least title) of Managing Director of the IETF Secretariat. An "Executive Director" title is now associated with different, and largely new, responsibilities as an Officer of the IETF Administration LLC. These changes are described in the description of the new structural arrangements . Editorial comment/rant (JcK 20181114): Or at least they had better be clearly described there because, if they are not, this document is the wrong place to try to fix it. I've done the best I could to combine my view of what this should say (which does not necessarily align with WG discussions) and Jason's (which presumably does, but had another issue or two). Basically, from the standpoint of a clear understanding of the new roles and titles, taking the old roles of "IETF Executive Director" and "IETF Administrative Director" and renaming the Secretariat management part of the former role to "Managing Director, IETF Secretariat" would have been a little confusing because the old "IETF Executive Director" position had functions that were not inherently limited to the Secretariat function as the IETF has understood it. But then taking some of the IAD functions and calling them "Executive Director" (without "IETF", but the term with "IETF" is still present in older documents that the WG has concluded it doesn't need to update and in some more recent sloppy usage) while distributing other IAD functions to the Secretariat is a recipe for complete confusion... and I've seen messages in which several people who have been active in the WG appear to be confused. I accept Alissa's judgment that it is too late to change this, or at least the association of the "Executive Director" title with that LLC function, but suggest we need to be _very_ careful -- much more careful than we have apparently been so far -- about good-quality explanations and absolute consistency about terminology. This document applies that change to the following: RFC 2028, The Organizations Involved in the IETF Standards Process , Section 3.3. Editorial note (JcK 20181115) Jason suggested somewhat different text, specifically "This means that the administrative functions necessary to support the activities of the IETF are performed by a Secretariat, led by the Managing Director, IETF Secretariat, and consisting of his or her staff in the IETF Secretariat." I don't think "This" (the change) means any such thing because 2028 fairly clearly establishes the administrative function role of the Secretariat and its staff. All this change does is what is described in the first paragraph of this section, i.e., switch titles, so the additional attempted explanation is unnecessary and likely to be confusing. A similar change was proposed for the description of the RFC 2418 change below. The WG should decide what it wants. RFC 2418, IETF Working Group Guidelines and Procedures RFC 3710, An IESG Charter, Section 2. RFC 6702, Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules, Section 5 . Note that the current description of the Internet Standards Process does not require an update by this document for this purpose because the reference to the IETF Executive Director in RFC 2026 was replaced by a document that precedes the current effort and that was, in turn, obsoleted by RFC 8179. Note in Draft: Bob Hinden's note of November 10, 2018 11:37 +0900 indicates that RFC4844 should continue to reference the IETF Executive Director.

In a few cases, it is no longer appropriate for either the Managing Director, IETF Secretariat (former IETF Executive Director position) or the new IETF Executive Director (for the LLC) to perform a particular historical function. The relevant documents are updated to remove the IETF Executive Director from the list of people with specific responsibilities or authority. Those documents will not be updated to use "Managing Director, IETF Secretariat" but, instead, the mention of the position will simply be dropped. This document applies that change to the following: RFC 3005, IETF Discussion List Charter , section titled "Charter for the IETF Discussion List". This document is modified to remove the authorization for the IETF Executive Director to restrict people from posting, etc.

The IASA2 Working Group has also identified several RFCs that no longer apply as a result of the change to the new IASA 2.0 structure. The result is that several informational, experimental, or other RFCs can be deprecated. This document deprecates the following: RFC 3929, which touches on aspects of the administration of the IETF, such as mentioning the IETF Executive Director. It dates to 2004 and is experimental. RFC 3979, that is updated by , which corrects mentions of the IETF Executive Director to the IETF Secretariat. RFC 4633, which is an experimental document that refers to IETF Executive Director. It describes a 2006 experiment that ran for 18 months. RFC 4879, that is updated by , which corrects mentions of the IETF Executive Director to the IETF Secretariat. It is also recommended that the above documents be reclassified to Historic to further reduce the risk of any confusion.

Brian Carpenter's careful checking and identification of documents that did, and did not, require consideration was essential to the draft in its current form.

Jason Livingood did the hard work of identifying the documents that required updating and supplied considerable text used in this document.

RFC Editor: Please remove this section before publication. This memo includes no requests to or actions for IANA.

The changes specified in this document are matters of terminology and organizational structure derived from documents it references. It should have no effect on Internet security.

&rfc2028; &rfc2418; &rfc3005; &rfc4844; &rfc5377; &rfc3710; &rfc6702; &rfc7500;

IETF Administration LLC

&rfc2026; &rfc3716; &rfc3929; &rfc3979; &rfc4633; &rfc4879; &rfc8179;

RFC Editor: Please remove this appendix before publication.

Removed RFCs 3979 and 4879 from the "obsoletes" list because they had already been obsoleted (by 8179). It also removes RFC 8179 from the "updates" list because 8179 uses "IETF Secretariat" terminology rather than "IETF Executive Director". Note in Draft: That suggests an idea which might considerably mitigate the name confusion issue: Instead of singling out the Managing Director of the Secretariat as a named individual, perhaps we should be referring to the Secretariat itself, leaving the contact point or address up to them as an internal administrative matter. Just a thought. --JcK Added text to explain why RFC 2026 is not on the hit list. Added an acknowledgment to Brian Carpenter. If he catches another batch of errors and supplies text, he gets promoted to Contributor. Adjusted reference [RFC-Struct] to point to 4071bis. Minor editorial corrections and changes.