<?xmlversion="1.0" encoding="US-ASCII"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!-- Getting references from the online citation library. There has to be one entity for each item to be referenced. --> <!ENTITY rfc2026 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml"> <!ENTITY rfc2028 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2028.xml"> <!ENTITY rfc2418 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2418.xml"> <!ENTITY rfc3005 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3005.xml"> <!ENTITY rfc3710 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3710.xml"> <!ENTITY rfc3716 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3716.xml"> <!ENTITY rfc3929 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3929.xml"> <!ENTITY rfc3979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3979.xml"> <!ENTITY rfc4633 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4633.xml"> <!-- <!ENTITY rfc4844 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4844.xml"> --> <!ENTITY rfc4879 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4879.xml"> <!-- <!ENTITY rfc5377 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5377.xml"> --> <!ENTITY rfc6702 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6702.xml"> <!-- <!ENTITY rfc7500 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7500.xml"> --> <!ENTITY rfc8179 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8179.xml"> <!-- Fudge for XMLmind which doesn't have this built in --> <!ENTITY nbsp " "> ]> <!-- Extra statement used by XSLT processors to control the output style. --> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- Processing Instructions- PIs (for a complete list and description, see file http://xml.resource.org/authoring/README.html. You may find that some sphisticated editors are not able to edit PIs when palced here. An alternative position is just inside the rfc elelment as noted below. --> <!-- Some of the more generally applicable PIs that most I-Ds might want to use --> <!-- Try to enforce the ID-nits conventions and DTD validity --> <?rfc strict="yes" ?> <!-- Items used when reviewing the document --> <!-- Controls display of <cref> elements --> <?rfc comments="yes" ?> <!-- When no, put comments at end in comments section, otherwise, put inline --> <?rfc inline="yes" ?> <!-- When yes, insert editing marks: editing marks consist of a string such as <29> printed in the blank line at the beginning of each paragraph of text. --> <?rfc editing="no" ?> <!-- Create Table of Contents (ToC) and set some options for it. Note the ToC may be omitted for very short documents,but idnits insists on a ToC if the document has more than 15 pages. --> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <!-- If "yes" eliminates blank lines before main section entries. --> <?rfc tocdepth="3"?> <!-- Sets the number of levels of sections/subsections... in ToC. Can be overridden by 'toc="include"/"exclude"' on the section element--> <!-- Choose the options for the references. Some like symbolic tags in the references (and citations) and others prefer numbers. The RFC Editor always uses symbolic tags. The tags used are the anchor attributes of the references. --> <?rfc symrefs="yes"?> <?rfc sortrefs="yes" ?> <!-- If "yes", causes the references to be sorted in order of tags. This doesn't have any effect unless symrefs is "yes" also. --> <!-- These two save paper: Just setting compact to "yes" makes savings by not starting each main section on a new page but does not omit the blank lines between list items. If subcompact is also "yes" the blank lines between list items are also omitted. --> <?rfc compact="yes" ?> <?rfc subcompact="no" ?> <!-- end of list of popular I-D processing instructions --> <!-- This is -07c, the posting version -->version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" consensus="true" docName="draft-ietf-iasa2-consolidated-upd-07" indexInclude="true" ipr="trust200902"category="bcp"number="8717" prepTime="2020-02-26T17:48:47" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" updates="2028, 2418, 3005, 3710, 3929, 4633, 6702"> <!-- JcK 20181203: removed 3979, 4879, 8179 from Obsoletes list JcK 20190117: removed 4844, 5377 JcK 20190311, removed 3929, 4633 and moved to updates --> <!-- ***** FRONT MATTER ***** -->xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-consolidated-upd-07" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8717" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <titleabbrev="IASA2abbrev="IASA 2.0 ConsolidatedUpdates">Updates">IETF Administrative Support Activity 2.0: ConsolidatedIASA 2.0Updatesofto IETF Administrative Terminology</title><!-- Before -05 was "Consolidated IASA2-Related Document Updates" Change per email from Brian Carpenter, 20180117 --> <!-- add 'role="editor"' below for the editors if appropriate --><seriesInfo name="RFC" value="8717" stream="IETF"/> <seriesInfo name="BCP" value="101" stream="IETF"/> <author fullname="John C Klensin"initials="J.C."initials="J." surname="Klensin" role="editor"><organization/><organization showOnFrontPage="true"/> <address> <postal> <street>1770 Massachusetts Ave, Ste 322</street> <city>Cambridge</city> <region>MA</region> <code>02140</code> <country>USA</country> </postal> <phone>+1 617 245 1457</phone> <email>john-ietf@jck.com</email> </address> </author> <datemonth="March" day="11" year="2019" /> <!-- Meta-data Declarations -->month="02" year="2020"/> <area>General</area><!-- WG name at the upper left corner of the doc, IETF fine for individual submissions. You can also omit this element in which case it defaults to "Network Working Group" - a hangover from the ancient history of the IETF! --><workgroup>IASA2</workgroup><!-- You can add <keyword/> elements here. They will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. --> <!-- <keyword>Text</keyword> (as many of those elements as needed --> <abstract> <t>In<keyword>IASA</keyword> <abstract pn="section-abstract"> <t pn="section-abstract-1">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.</t> </abstract><!-- Note here if needed <note title=""><t> .... </t></note> --> </front> <middle><boilerplate> <sectiontitle="Introduction" anchor="Intro"> <t>In 2018,anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t pn="section-boilerplate.1-1"> This memo documents an Internet Best Current Practice. </t> <t pn="section-boilerplate.1-2"> This document is a product of theIETF beganInternet Engineering Task Force (IETF). It represents the consensus of thetransition to a new administrative structure, and updated itsIETFAdministrative Support Activity (IASA) to a new "IASA 2.0" structure <xref target="RFC-Struct"/>. Key IASA 2.0 changes havecommunity. It has received public review and has been<!-- Theapproved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. </t> <t pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc8717" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t pn="section-boilerplate.2-1"> Copyright (c) 2020 IETFinitiated a major revisionTrust and the persons identified as the document authors. All rights reserved. </t> <t pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date ofits administrative support arrangementspublication of this document. Please review these documents carefully, as they describe your rights andproceduresrestrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in2018Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> </li> <li pn="section-toc.1-1.2"> <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-where-appropriate-replaceme">Where Appropriate, Replacement of the IETF Executive Director Position with the Managing Director, IETF Secretariat</xref></t> </li> <li pn="section-toc.1-1.3"> <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-removal-of-the-ietf-executi">Removal of the IETF Executive Director as an Option</xref></t> </li> <li pn="section-toc.1-1.4"> <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-deprecated-documents">Deprecated Documents</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2"> <li pn="section-toc.1-1.4.2.1"> <t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-documents-whose-context-is-">Documents Whose Context Is Changed by This Specification</xref></t> </li> <li pn="section-toc.1-1.4.2.2"> <t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-general-description-of-the-">General Description of the IETF Administrative Model</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.5"> <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.6"> <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2"> <li pn="section-toc.1-1.6.2.1"> <t keepWithNext="true" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.6.2.2"> <t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.7"> <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t> </li> <li pn="section-toc.1-1.8"> <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t> </li> <li pn="section-toc.1-1.9"> <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="Intro" numbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t pn="section-1-1">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 <xreftarget="RFC-Struct"/>. Thosetarget="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>. Key IASA 2.0 changes have been-->specified in a series of documents, including<!-- notably a description of -->changes to the IETF Trust <xreftarget="RFC-trust-update"/>,target="RFC8714" format="default" sectionFormat="of" derivedContent="RFC8714"/>, the rationale for it <xreftarget="RFC-trust-rationale"/>,target="RFC8715" format="default" sectionFormat="of" derivedContent="RFC8715"/>, a new defining document for the IETF Administration LLC <xreftarget="LLC-Agreement"/>target="LLC-Agreement" format="default" sectionFormat="of" derivedContent="LLC-Agreement"/> (informally called the "IETF LLC" or just "the LLC" in places in this document andelsewhere)elsewhere), and adjustments to the procedures for nominations and selections for relevant positions <xreftarget="RFC-7437bis"/>.</t> <t>Intarget="RFC8713" format="default" sectionFormat="of" derivedContent="RFC8713"/>.</t> <t pn="section-1-2">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. </t><!-- Among the substantive changes in those documents are changes in names of organizations, position titles, and associated relationships. Rather than reissue those documents individually, address other topics but mention those names, titles, and relationships, this specification provides updates to them to ensure that there is no confusion due to changes in terminology. --> <t><t pn="section-1-3"> This document updates RFCs 2028, 2418, 3005, 3710, 3929, 4633, and<!-- 5377 removed -->6702 (citations in context below) to make those terminology and related changes. In addition, with the authorization of the IAB, it requests that the Informational RFC 3716 be made Historic (see <xreftarget="MakeHistoric"/>).target="MakeHistoric" format="default" sectionFormat="of" derivedContent="Section 4"/>). The sections that follow identify the details of the relevant documents and the required changes. </t><!-- <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t> --></section><!--<sectiontitle="Remove Text About the Connection Betweenanchor="ExecDir-Managing" numbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-where-appropriate-replaceme">Where Appropriate, Replacement of theIAOC andIETFTrust"> <t> Some documents that discussExecutive Director Position with the Managing Director, IETFTrust 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. <t> This document applies that change to the following: <list style="symbols"> <t> <xref target="RFC5377">RFC 5377</xref>, 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. <vspace blankLines="0"/> <cref> RFC Editor please note that the bracketed strings above are quoted text, not references. </cref></t> </list></t> </section> --> <!-- <section title="Replacement of IAOC with IETF Administration LLC" anchor="LLCRepl"> <t>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. </t> <t> This document applies that change to the following: <list style="symbols"> <t><xref target="RFC4844">RFC 4844</xref>, the RFC Series and RFC Editor Sections 3.3, 3.4, and 4.</t> <t><xref target="RFC7500">RFC 7500</xref> 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.</t> </list></t> </section> --> <section title="Where Appropriate, Replacement of the IETF Executive Director position with the Managing Director, IETF Secretariat" anchor="ExecDir-Managing"> <t>UnderSecretariat</name> <t pn="section-2-1">Under the IASA 2.0 structure, most of the responsibilities of the former position of IETF Executive Director have been assigned to a new position (or at least title) of ManagingDirector of theDirector, IETF Secretariat. An "Executive Director" title is now associated with different, and largely new, responsibilities as anOfficerofficer of the IETF Administration LLC. These changes aredescribedcovered in the description of the new structural arrangements <xreftarget="RFC-Struct"/>.</t> <t>target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>.</t> <t pn="section-2-2"> This document applies that change to thefollowing: <!-- RFC Editor: the inconsistency in the positioning of section numbers in citations below is deliberate, to call your attention to an issue about this type of reference that I've been commenting/ inquiring/ complaining about since 1999. Fix it however you like. --> <list style="symbols"> <t>RFCfollowing:</t> <ul spacing="normal" bare="false" empty="false" pn="section-2-3"> <li pn="section-2-3.1">RFC 2028,The"The Organizations Involved in the IETF StandardsProcessProcess", <xreftarget="RFC2028"/>, Section 3.3.</t> <t>RFCtarget="RFC2028" sectionFormat="comma" section="3.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2028#section-3.3" derivedContent="RFC2028"/>.</li> <li pn="section-2-3.2">RFC 2418,IETF"IETF Working Group Guidelines andProceduresProcedures", <xreftarget="RFC2418"/>, Section 1.</t> <t>RFCtarget="RFC2418" sectionFormat="comma" section="1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2418#section-1" derivedContent="RFC2418"/>.</li> <li pn="section-2-3.3">RFC 3710,An"An IESGCharter, Section 2Charter", <xreftarget="RFC3710"/>.</t> <t>RFCtarget="RFC3710" sectionFormat="comma" section="2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3710#section-2" derivedContent="RFC3710"/>.</li> <li pn="section-2-3.4">RFC 3929,Alternative"Alternative Decision Making Processes for Consensus-Blocked Decisions in theIETFIETF", <xreftarget="RFC3929"/>,target="RFC3929" format="default" sectionFormat="of" derivedContent="RFC3929"/>, Sections4.1.1 and 4.3 (twice).</t> <t>RFC<xref target="RFC3929" section="4.1.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3929#section-4.1.1" derivedContent="RFC3929"/> and <xref target="RFC3929" section="4.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3929#section-4.3" derivedContent="RFC3929"/> (twice).</li> <li pn="section-2-3.5">RFC 4633,Experiment"Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) MailingListsLists", <xreftarget="RFC4633"/>, Section 1.</t> <t>RFCtarget="RFC4633" sectionFormat="comma" section="1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4633#section-1" derivedContent="RFC4633"/>.</li> <li pn="section-2-3.6">RFC 6702,Promoting"Promoting Compliance with Intellectual Property Rights (IPR) DisclosureRules, Section 5Rules", <xreftarget="RFC6702"/>.</t> </list></t> <t>target="RFC6702" section="5" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6702#section-5" derivedContent="RFC6702"/>.</li> </ul> <t pn="section-2-4"> Note that the current description of the Internet Standards Process <xreftarget="RFC2026"/>target="RFC2026" format="default" sectionFormat="of" derivedContent="RFC2026"/> 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 <xref target="RFC3979" format="default" sectionFormat="of" derivedContent="RFC3979"/> that precedes the currenteffort <xref target="RFC3979"/>effort, and that document was, in turn, obsoleted by <xreftarget="RFC8179">RFCtarget="RFC8179" format="default" sectionFormat="of" derivedContent="RFC8179">RFC 8179</xref>.</t> </section> <sectiontitle="Removenumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-removal-of-the-ietf-executi">Removal of the IETF Executive Director as anOption"> <t>Option</name> <t pn="section-3-1"> 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.</t><t><t pn="section-3-2"> This document applies that change to the following:<list style="symbols"> <t>RFC</t> <ul spacing="normal" bare="false" empty="false" pn="section-3-3"> <li pn="section-3-3.1">RFC 3005,IETF"IETF Discussion ListCharterCharter" <xreftarget="RFC3005"/>,target="RFC3005" format="default" sectionFormat="of" derivedContent="RFC3005"/>, 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.</t> <!-- Jason: As a result, onlyetc.</li> </ul> </section> <section anchor="MakeHistoric" numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-deprecated-documents">Deprecated Documents</name> <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1"> <name slugifiedName="name-documents-whose-context-is-">Documents Whose Context Is Changed by This Specification</name> <t pn="section-4.1-1">Both of theIETF Chair, or a sergeant-at-arms appointeddocuments that follow were obsoleted in 2017 by <xref target="RFC8179" format="default" sectionFormat="of" derivedContent="RFC8179">RFC 8179</xref>, which changed mentions of theChair, are empoweredIETF Executive Director todo so. --> </list></t> </section> <section title="Deprecated Documents" anchor="MakeHistoric"> <t><cref> Notepoint to theWG, IESG, and RFC Editor: I hope this section correctly reflects the conclusions of discussions in and with the WG. If it does not, the issues should certainly be identified and fixed. However, details of some of the actions are the responsibility of the RFC Editor and RFC 3716 is an IAB document containing the report of an IAB Advisory Committee. If that text, especially the phrasing of various actions, is not quite right, I hope those involved can sort the language out with the RFC Editor rather than requiring that the WG iterate on the draft. --JcK, editor. RFC Editor: should this paragraph reach you, please remove it.</cref></t> <section title="Documents Whose Context is Changed by This Specification "> <t>Both of the documents that follow were obsoleted in 2017 by <xref target="RFC8179">RFC 8179</xref>, which changed mentions of the IETF Executive Director to point to the IETF Secretariat more generally.</t> <t><list style="symbols"> <t><xref target="RFC3979">RFC 3979</xref>.</t> <t><xref target="RFC4879">RFC 4879</xref>.</t> </list></t> </section> <section title="General DescriptionIETF Secretariat more generally.</t> <ul spacing="normal" bare="false" empty="false" pn="section-4.1-2"> <li pn="section-4.1-2.1"> <xref target="RFC3979" format="default" sectionFormat="of" derivedContent="RFC3979">RFC 3979</xref></li> <li pn="section-4.1-2.2"> <xref target="RFC4879" format="default" sectionFormat="of" derivedContent="RFC4879">RFC 4879</xref></li> </ul> </section> <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-general-description-of-the-">General Description of the IETFAdminstrative Model"> <t><xref target="RFC3716">RFCAdministrative Model</name> <t pn="section-4.2-1"><xref target="RFC3716" format="default" sectionFormat="of" derivedContent="RFC3716">RFC 3716</xref>iswas a report of an IAB Advisory Committee that served as a starting point for the work that led to the original IASA structure. That reportiswas an IAB document rather than an IETF one. The IAB approved a proposal to move RFC 3716 to Historic on March 6,2019.2019 <xref target="IAB-3716-Historic" format="default" sectionFormat="of" derivedContent="IAB-3716-Historic"/>. </t> </section> </section> <sectionanchor="Acknowledgments" title="Acknowledgments"> <t> 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. He also made several other significant contributions. Bob Hinden also gave the document a careful reading and made useful suggestions. In additional to the above, Alissa Cooper, Eliot Lear, Heather Flanagan (the RFC Series Editor), and the current membership to the IAB helped sort out the handing of RFC 3716.</t> </section> <section title="Contributors"> <t>Jason Livingood did the hard work of identifying the documents that required updating and supplied considerable text used in this document.</t> </section> <section anchor="IANA" title="IANA Considerations"> <t><cref> RFC Editor: Please remove this section before publication.</cref></t> <t>This memo includes no requests to or actions for IANA.</t> </section> <sectionanchor="Security"title="Security Considerations"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t pn="section-5-1">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.</t> </section> </middle><!-- *****BACK MATTER ***** --><back> <referencestitle="Normative References"> <!-- &rfc2119; --> &rfc2028; &rfc2418; &rfc3005; <!-- &rfc4844; --> <!-- &rfc5377; --> &rfc3710; &rfc6702; <!-- &rfc7500; -->pn="section-6"> <name slugifiedName="name-references">References</name> <references pn="section-6.1"> <name slugifiedName="name-normative-references">Normative References</name> <referenceanchor="RFC-Struct" target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc4071bis/">anchor="LLC-Agreement" target="https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf" quoteTitle="true" derivedAnchor="LLC-Agreement"> <front><title>Structure<title>Limited Liability Company Agreement oftheIETFAdministrative Support Activity, Version 2.0</title> <author initials="B." surname="Haberman"> <organization></organization> <address/> </author> <author initials="J." surname="Hall"> <organization></organization> <address/> </author> <author initials="J." surname="Livingood"> <organization></organization> <address/>Administration LLC</title> <author> <organization showOnFrontPage="true">IETF Administration LLC</organization> </author> <date year="2018"month="December" day="5" />month="August" day="28"/> </front> </reference><!--<referenceanchor="RFC-StructS3" target="https://tools.ietf.org/html/draft-ietf-iasa2-struct-06#section-3">anchor="RFC2028" target="https://www.rfc-editor.org/info/rfc2028" quoteTitle="true" derivedAnchor="RFC2028"> <front><title>Structure of<title>The Organizations Involved in the IETFAdministrative Support Activity, Version 2.0</title>Standards Process</title> <authorinitials="B." surname="Haberman"> <organization></organization> <address/>initials="R." surname="Hovey" fullname="R. Hovey"> <organization showOnFrontPage="true"/> </author> <authorinitials="J." surname="Hall"> <organization></organization> <address/> </author> <author initials="J." surname="Livingood"> <organization></organization> <address/>initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <dateyear="2018" month="December" day="5" /> </front> </reference> --> <reference anchor="RFC-trust-update" target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-update/"> <front> <title>Update toyear="1996" month="October"/> <abstract> <t>This document describes theProcess for Selectionindividuals and organizations involved in the IETF. This includes descriptions ofTrustees forthe IESG, the IETFTrust</title> <author initials="J." surname="Arkko"> <organization></organization> <address/> </author> <author initials="T." surname="Hardie"> <organization></organization> <address/> </author> <date year="2018" /> </front> </reference> <reference anchor="RFC-trust-rationale" target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-rationale/"> <front> <title>Discussion ofWorking Groups and theIASA 2.0 Changes as They Relate torelationship between the IETFTrust</title> <author initials="J." surname="Arkko"> <organization></organization> <address/> </author> <date year="2018" />and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="11"/> <seriesInfo name="RFC" value="2028"/> <seriesInfo name="DOI" value="10.17487/RFC2028"/> </reference> <referenceanchor="LLC-Agreement" target="https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf">anchor="RFC2418" target="https://www.rfc-editor.org/info/rfc2418" quoteTitle="true" derivedAnchor="RFC2418"> <front><title>Limited Liability Company Agreement of IETF Administration LLC</title><title>IETF Working Group Guidelines and Procedures</title> <author> <organization>IETF Administration LLC</organization> <address/>initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <dateyear="2018" month="August" day="28"/> </front> </reference> <reference anchor="RFC-7437bis" target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7437bis/"> <front> <title>IAB, IESG,year="1998" month="September"/> <abstract> <t>This document describes the guidelines andIETF LLC Selection, Confirmation,procedures for formation andRecall Process: Operationoperation oftheIETFNominatingworking groups. This document specifies an Internet Best Current Practices for the Internet Community, andRecall Committees</title> <author initials="M." surname="Kucherawy" role="editor"> <organization></organization> <address/> </author> <author initials="R." surname="Hinden" role="editor"> <organization></organization> <address/> </author>requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="25"/> <seriesInfo name="RFC" value="2418"/> <seriesInfo name="DOI" value="10.17487/RFC2418"/> </reference> <reference anchor="RFC3005" target="https://www.rfc-editor.org/info/rfc3005" quoteTitle="true" derivedAnchor="RFC3005"> <front> <title>IETF Discussion List Charter</title> <authorinitials="J." surname="Livingood" role="editor"> <organization></organization> <address/>initials="S." surname="Harris" fullname="S. Harris"> <organization showOnFrontPage="true"/> </author> <dateyear="2018" /> </front> </reference> </references> <references title="Informative References"> &rfc2026; &rfc3716; &rfc3929; &rfc3979; &rfc4633; &rfc4879; &rfc8179; </references> <!-- Sections below here become Appendices. --> <section title="Change Log" anchor="ChangeLog"> <t>RFC Editor: Please remove this appendix before publication.</t> <section title="Changes from version -00 (2018-11-15) to -01"> <t><list style="symbols"> <t> 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"year="2000" month="November"/> <abstract> <t>The Internet Engineering Task Force (IETF) discussion mailing listbecause 8179 uses "IETF Secretariat" terminology rather than "IETF Executive Director". <vspace blankLines="1"/> <cref> Note in Draft: That suggests an idea which might considerably mitigatefurthers thename confusion issue: Insteaddevelopment and specification ofsingling out the Managing DirectorInternet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is theSecretariat as a named individual, perhaps we should be referringmost general IETF mailing list, considerable latitude is allowed. Advertising, whether tothe Secretariat itself, leaving the contact pointsolicit business oraddress up to thempromote employment opportunities, falls well outside the range of acceptable topics, asan internal administrative matter. Justdo discussions of athought. --JcK</cref></t> <t> Added text to explain why RFC 2026 is not onpersonal nature. This document specifies an Internet Best Current Practices for thehit list.</t> <t> Added an acknowledgment to Brian Carpenter. If he catches another batch of errors and supplies text, he gets promoted to Contributor.</t> <t> Adjusted reference [RFC-Struct] to point to 4071bis.</t> <t> Minor editorial correctionsInternet Community, andchanges. </t> </list></t> </section> <section title="Changes from version -01 (dated 2018-12-06 but posted 2012-12-07) to -02"> <t> I accidentally omitted RFC 4844 fromrequests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="45"/> <seriesInfo name="RFC" value="3005"/> <seriesInfo name="DOI" value="10.17487/RFC3005"/> </reference> <reference anchor="RFC3710" target="https://www.rfc-editor.org/info/rfc3710" quoteTitle="true" derivedAnchor="RFC3710"> <front> <title>An IESG charter</title> <author initials="H." surname="Alvestrand" fullname="H. Alvestrand"> <organization showOnFrontPage="true"/> </author> <date year="2004" month="February"/> <abstract> <t>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 documentheader "updates" listthe charter of the IESG as it is presently understood. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="3710"/> <seriesInfo name="DOI" value="10.17487/RFC3710"/> </reference> <reference anchor="RFC6702" target="https://www.rfc-editor.org/info/rfc6702" quoteTitle="true" derivedAnchor="RFC6702"> <front> <title>Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules</title> <author initials="T." surname="Polk" fullname="T. Polk"> <organization showOnFrontPage="true"/> </author> <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre"> <organization showOnFrontPage="true"/> </author> <date year="2012" month="August"/> <abstract> <t>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.</t> </abstract> </front> <seriesInfo name="RFC" value="6702"/> <seriesInfo name="DOI" value="10.17487/RFC6702"/> </reference> <reference anchor="RFC8711" target="https://www.rfc-editor.org/info/rfc8711" quoteTitle="true" derivedAnchor="RFC8711"> <front> <title>Structure of the IETF Administrative Support Activity, Version012.0</title> <author initials="B." surname="Haberman"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Hall"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Livingood"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="February"/> </front> <seriesInfo name="BCP" value="101"/> <seriesInfo name="RFC" value="8711"/> <seriesInfo name="DOI" value="10.17487/RFC8711"/> </reference> <reference anchor="RFC8713" target="https://www.rfc-editor.org/info/rfc8713" quoteTitle="true" derivedAnchor="RFC8713"> <front> <title>IAB, IESG, IETF Trust, andnoticed that in responseIETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees</title> <author initials="M." surname="Kucherawy" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Hinden" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Livingood" role="editor"> <organization showOnFrontPage="true"/> </author> <date month="February" year="2020"/> </front> <seriesInfo name="BCP" value="10"/> <seriesInfo name="RFC" value="8713"/> <seriesInfo name="DOI" value="10.17487/RFC8713"/> </reference> <reference anchor="RFC8714" target="https://www.rfc-editor.org/info/rfc8714" quoteTitle="true" derivedAnchor="RFC8714"> <front> <title>Update toan unrelated question almost immediately after posting. The correction seemed important enough to justify almost immediate re-posting. Changes are only that header,the Process for Selection of Trustees for the IETF Trust</title> <author initials="J." surname="Arkko"> <organization showOnFrontPage="true"/> </author> <author initials="T." surname="Hardie"> <organization showOnFrontPage="true"/> </author> <date month="February" year="2020"/> </front> <seriesInfo name="BCP" value="101"/> <seriesInfo name="RFC" value="8714"/> <seriesInfo name="DOI" value="10.17487/RFC8714"/> </reference> <reference anchor="RFC8715" target="https://www.rfc-editor.org/info/rfc8715" quoteTitle="true" derivedAnchor="RFC8715"> <front> <title>IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust</title> <author initials="J." surname="Arkko"> <organization showOnFrontPage="true"/> </author> <date month="February" year="2020"/> </front> <seriesInfo name="RFC" value="8715"/> <seriesInfo name="DOI" value="10.17487/RFC8715"/> </reference> </references> <references pn="section-6.2"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="IAB-3716-Historic" target="https://www.iab.org/documents/minutes/minutes-2019/iab-minutes-2019-03-06/" quoteTitle="true" derivedAnchor="IAB-3716-Historic"> <front> <title>IAB Minutes 2019-03-06</title> <author> <organization showOnFrontPage="true">Internet Architecture Board</organization> </author> <date year="2019" month="March" day="6"/> </front> </reference> <reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026" quoteTitle="true" derivedAnchor="RFC2026"> <front> <title>The Internet Standards Process -- Revision 3</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1996" month="October"/> <abstract> <t>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a documentfile name,between stages and thedate. --JcK </t> </section> <section title="Changes from version -02 (2018-12-07) to -03"> <t><list style="symbols"> <t> Removedtypes of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion andpointers to RFC 7500 -suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="2026"/> <seriesInfo name="DOI" value="10.17487/RFC2026"/> </reference> <reference anchor="RFC3716" target="https://www.rfc-editor.org/info/rfc3716" quoteTitle="true" derivedAnchor="RFC3716"> <front> <title>The IETF in the Large: Administration and Execution</title> <author> <organization showOnFrontPage="true">IAB Advisory Committee</organization> </author> <date year="2004" month="March"/> <abstract> <t>In the fall of 2003, the IETF Chair and the IABwill publish separately. </t> <t> Added textChair formed an IAB Advisory Committee (AdvComm), with a mandate todescribe (very superficially) RFC 3716. Thatreview the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF. The AdvComm mandate did not include the standards process itself. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="3716"/> <seriesInfo name="DOI" value="10.17487/RFC3716"/> </reference> <reference anchor="RFC3929" target="https://www.rfc-editor.org/info/rfc3929" quoteTitle="true" derivedAnchor="RFC3929"> <front> <title>Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF</title> <author initials="T." surname="Hardie" fullname="T. Hardie"> <organization showOnFrontPage="true"/> </author> <date year="2004" month="October"/> <abstract> <t>This documentwas obsoletedproposes 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 theprevious versiongroup has come to consensus that a particular decision must be made butnot described.</t> <t> Removed rant about titles and responsibilities from <xref target="ExecDir-Managing"/> andcannot agree on the decision itself. This document describes alternative mechanisms for reaching asubsequent editorial note I hope itdecision in those cases. This isno longer needed --JcK. In additional, several blocksnot meant to provide an exhaustive list, but to provide a known set oftexttools thatwere commented outcan be used when needed. This memo defines an Experimental Protocol for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="3929"/> <seriesInfo name="DOI" value="10.17487/RFC3929"/> </reference> <reference anchor="RFC3979" target="https://www.rfc-editor.org/info/rfc3979" quoteTitle="true" derivedAnchor="RFC3979"> <front> <title>Intellectual Property Rights in IETF Technology</title> <author initials="S." surname="Bradner" fullname="S. Bradner" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2005" month="March"/> <abstract> <t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed inearlier versions oftheXMLIETF are designed to ensure that IETF working groups and participants havebeen removed entirely.</t> </list></t> </section> <section title="Changes from version -03 (2018-12-12) to -04"> <t><list style="symbols"> <t> Removed RFC 4844 fromas much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit theupdate listInternet community anddiscussion becausetheconsensus inpublic at large, while respecting the legitimate rights of IPR holders. This memo details theWG seemedIETF policies concerning IPR related tobetechnology worked on within the IETF. It also describes the objectives thatit (andthe policies are designed to meet. This memo updates RFCEditor) should be handled separately. </t> <t> Removed2026 and, with RFC5377 from3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for theupdate listInternet Community, and requests discussionbecause it involves the Trust. </t> <t> Editor's note in draft: <list style="empty"> <t> The above changesand suggestions for improvements.</t> </abstract> </front> <seriesInfo name="RFC" value="3979"/> <seriesInfo name="DOI" value="10.17487/RFC3979"/> </reference> <reference anchor="RFC4633" target="https://www.rfc-editor.org/info/rfc4633" quoteTitle="true" derivedAnchor="RFC4633"> <front> <title>Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists</title> <author initials="S." surname="Hartman" fullname="S. Hartman"> <organization showOnFrontPage="true"/> </author> <date year="2006" month="August"/> <abstract> <t>Discussion in theearlier removal ofcommunity has begun to question whether RFC 3683 and RFC7500 so3934 provide theIAB could publish it ownappropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists. This documentcompletely eliminateis an RFC 3933 experiment designed to allow theearlier Sections 2 and 3. That may call forcommunity to experiment with arevisionbroader set of tools for mailing list management while trying to determine what theIntroduction and/or Abstract, but I have not done a reviewlong-term guidelines should be. This memo defines an Experimental Protocol forthis iterationthe Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="4633"/> <seriesInfo name="DOI" value="10.17487/RFC4633"/> </reference> <reference anchor="RFC4879" target="https://www.rfc-editor.org/info/rfc4879" quoteTitle="true" derivedAnchor="RFC4879"> <front> <title>Clarification ofwhether such changes are needed.</t> <t> As documents and references are shuffledthe Third Party Disclosure Procedure in RFC 3979</title> <author initials="T." surname="Narten" fullname="T. Narten"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="April"/> <abstract> <t>This document clarifies andout of this one, it occurred to me that havingupdates anon-normative appendix somewheresingle sentence in RFC 3979. Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is thatwould identify all ofthedocuments containing changes to reflectIETF Executive Director notify theIASA 1.x to 2.0 transition would be of great helpIPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have anyfuture historian trying to understand what we did and probably helpfuldisclosure that needs to be made, per applicable RFC 3979 rules. This document specifies an Internet Best Current Practices for theIETF if some of these changes don't work out and/or require further tuning. After a brief discussion, JasonInternet Community, andI concluded that appendix did not belongrequests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="RFC" value="4879"/> <seriesInfo name="DOI" value="10.17487/RFC4879"/> </reference> <reference anchor="RFC8179" target="https://www.rfc-editor.org/info/rfc8179" quoteTitle="true" derivedAnchor="RFC8179"> <front> <title>Intellectual Property Rights inthis iteration of this document.</t> </list></t> </list></t> </section> <section title="Changes from version -04 (2019-01-17) to -05"> <t><list style="symbols"> <t> Changed title from "Consolidated IASA2-Related Document Updates"IETF Technology</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Contreras" fullname="J. Contreras"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="May"/> <abstract> <t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to"Consolidated IASA 2.0 Updates oftechnologies developed in the IETFAdministrative Terminology" per suggestions from Brian Carpenter and Bob Hindenare designed to ensure that IETF working groups and2019-01-31 WG decision.</t> <t> Removed CREF from <xref target="Intro"/> (shouldparticipants havebeen doneas much information as possible about any IPR constraints on a technical proposal as early as possible in-04).the development process. Theonly remaining CREFspolicies are intended to benefit theone in this section (above) that should probably be preserved through IETF Last CallInternet community andnotes totheRFC Editor. </t> <t> Updated acknowledgments.</t> </list></t> </section> <section title="Changes from version -05 (2019-01-31) to -06"> <t><list style="symbols"> <t> Changespublic at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related totext about documentstechnology worked on within the IETF. It also describes the objectives that the policies areupdated and made historic, per advice from RFC Editor, WG Chairs, and IAB.designed to meet. Thisincludes a statement about IAB action of 2019-03-06 that requests that thedocument updates RFCEditor move2026 and, with RFC3716 to Historic but does not obsolete5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879.</t> </abstract> </front> <seriesInfo name="BCP" value="79"/> <seriesInfo name="RFC" value="8179"/> <seriesInfo name="DOI" value="10.17487/RFC8179"/> </reference> </references> </references> <section anchor="Acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-acknowledgments">Acknowledgments</name> <t pn="section-appendix.a-1"> <contact fullname="Brian Carpenter's"/> careful checking and identification of documents thatInformational report. When minimal changes were attempted, <xref target="MakeHistoric"/> became very hard to readdid, andhencedid not, require consideration wasrestructuredessential to the document in its current form. He also made several other significant contributions. <contact fullname="Bob Hinden"/> also gave the document a careful reading andsomewhat rewritten (and then further modifiedmade useful suggestions. In additional towork around an xml2rfc glitch). Special attention should be paidthe above, <contact fullname="Alissa Cooper"/>, <contact fullname="Eliot Lear"/>, <contact fullname="Heather Flanagan"/> (the RFC Series Editor), and the current membership to thenote atIAB helped sort out thebeginninghanding ofthat section.</t> <t> Updated the Acknowledgments section.</t> </list></t>RFC 3716.</t> </section> <sectiontitle="Changes from version -06 (2019-03-06) to -07"> <t><list style="symbols"> <t> Moved RFCs 3929 and 4633 from "obsoleted" to "updated" and stripped text requested that they be made Historic atnumbered="false" toc="include" removeInRFC="false" pn="section-appendix.b"> <name slugifiedName="name-contributors">Contributors</name> <t pn="section-appendix.b-1"><contact fullname="Jason Livingood"/> did thedirectionhard work of identifying theIETF Chair, WG Co-chair, and an author. </t> <t> Added a section number for a document listed in Section 2documents thatwas missing.</t> <t> Added some notes to the RFC Editorrequired updating andothers.</t> <t> Updated the acknowledgments.</t> </list></t>supplied considerable text used in this document.</t> </section><!--<sectiontitle="Changes from version -07 (2019-03-11) to -08"> <t><list style="symbols"> <t> ... </t> </list></t> </section> -->anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c"> <name slugifiedName="name-authors-address">Author's Address</name> <author fullname="John C Klensin" initials="J." surname="Klensin" role="editor"> <organization showOnFrontPage="true"/> <address> <postal> <street>1770 Massachusetts Ave, Ste 322</street> <city>Cambridge</city> <region>MA</region> <code>02140</code> <country>USA</country> </postal> <phone>+1 617 245 1457</phone> <email>john-ietf@jck.com</email> </address> </author> </section> </back> </rfc>