]> Akamai Technologies

rsalz@akamai.com

General TBD Internet-Draft, IASA, terminology RFC 8717 updated several RFCs pertaining to the organization of the IETF to use the term "Managing Director, IETF Secretariat" (MDS). As that term does not accurately reflect the organization or roles of the IETF staff, the MDS term is no longer relevant. This document removes mention of particular staff roles, and instead updates the source documents so that the job to done, and who the responsible entity is (generally, the IETF LLC) are described. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction updated several RFCs pertaining to the organization of the IETF to use the term "Managing Director, IETF Secretariat" (MDS). As that term does not accurately reflect the organization or roles of the IETF staff, the MDS term is no longer relevant. This document removes mention of particular staff roles, and instead updates the source documents so that the job to done, and who the responsible entity is (generally, the IETF LLC) are described. This document updates , , , and .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Updates Being Made explained that did not need to be updated because removed the need for it. While the same section of RFC 8717 provided an update to , that has similarly been overtaken by events in that it was obsoleted by , and Section 3 of RFC 9281 does not need revising. Further, the IETF is in the "consideration" stage of forming a working group to update ; for discussion, see the mailing list. An online document proposing changes to RFC 2418 to comply with this document are available. The following sub-sections make the specific changes for each RFC and therefore this document completely replaces Section 2 of RFC 8717.

Changes to RFC 3710 describes the composition of the IESG. This section is updated to replace the original text that twice mentions "IETF Executive Director" with "a member of the IETF staff as specified by the IETF LLC."

Changes to RFC 3929 RFC 3929, an Experimental RFC, proposes a number of methods to resolve a deadlock when an IETF Working Group is unable to come to a decision. says that volunteers should send their names to the IETF Executive Directory, who should use to choose if their is an excess of volunteers. As the IESG is responsible for the standards process, this task should be fulfilled by someone they announce. Similarly, in an alternate method is described. Again, the text is changed so that the IESG announces who will perform that task.

Changes to RFC 4633 says that the IETF Executive Director is empowered to restrict posting to the IETF discussion list. This document updates RFC 4633 to remove that ability.

Changes to RFC 6702 says that WG Chairs and Area Directors are encouraged to ask the IETF Executive Directory to contact those who submitted an early intellectual property disclosure and request an update. This document updates RFC 6702 to say that the IETF LLC, or their designee, should be contacted.

Security Considerations This document has no security considerations.

IANA Considerations This document has no IANA actions.

References Normative References This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community. This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community. Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be. This memo defines an Experimental Protocol for the Internet community. The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. This document is not an Internet Standards Track specification; it is published for informational purposes. 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 many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879. This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the individuals and organizations involved in the IETF standards process, as described in BCP 9. It includes brief descriptions of the entities involved and the role they play in the standards process. The IETF and its structure have undergone many changes since RFC 2028 was published in 1996. This document reflects the changed organizational structure of the IETF and obsoletes RFC 2028. This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. This memo provides information for the Internet community.

Acknowledgments Just me.