<?xmlversion="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3.4) -->version='1.0' encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-rswg-rfc7990-updates-12" number="9720" category="info" submissionType="editorial" obsoletes="7990" updates="9280" tocInclude="true" sortRefs="true"symRefs="true">symRefs="true" version="3" xml:lang="en"> <front> <title abbrev="RFC Formats and Versions">RFC Formats and Versions</title> <seriesInfo name="RFC" value="9720"/> <author initials="P." surname="Hoffman" fullname="Paul Hoffman"> <organization>ICANN</organization> <address> <email>paul.hoffman@icann.org</email> </address> </author> <author initials="H." surname="Flanagan" fullname="Heather Flanagan"> <organization>Spherical Cow Consulting</organization> <address> <email>hlf@sphericalcowconsulting.com</email> </address> </author> <dateyear="2024" month="August" day="06"/> <keyword>Internet-Draft</keyword>year="2025" month="January"/> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><?line 40?><t>In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document describes how RFCs are published.</t> <t>This document obsoletes RFC 7990. This document also updates the stability policy in RFC 9280.</t> </abstract> </front> <middle><?line 49?><sectionanchor="introduction"><name>Introduction</name>anchor="introduction"> <name>Introduction</name> <t>"RFC Series Format Requirements and Future Development" <xref target="RFC6949"/> discussed the need to improve the display of items such as author names and artwork in RFCs as well as the need to improve the ability of RFCs to be displayed properly on various devices. Based onthediscussions with communities of interest, such as the IETF, the RFC Series Editor decided to explore a change to the format of the Series. <xref target="RFC7990"/> was the culmination of that exploration.</t> <t>This document is concerned with the production of RFCs, focusing on the published documents. It does not address any changes to the processes each stream uses to develop and review their submissions (specifically, how Internet-Draftswill beare developed). While I-Ds have a similar set of issues and concerns, directly addressing those issues for I-Ds should be discussed within each document stream.</t> <t>The details described in this document are expected to continue to change over time as the community and the RFC Production Center (RPC)gainsgain further experience implementing the policies described here.</t> <t>Implementors ofthosethese components are advised to avoid assuming that all such changes will bebackwards-compatible.</t>backwards compatible.</t> <sectionanchor="changes-to-rfc-7990"><name>Changesanchor="changes-to-rfc-7990"> <name>Changes to RFC 7990</name> <!-- [rfced] We wonder about trimming this sentence down for simplicity. Original: [RFC7990] defined a framework for how RFCs would be published after that document was published, including new formats and a new "canonical format" for archiving RFCs. Perhaps A: [RFC7990] defined a framework for how RFCs would be published. Or perhaps B: [RFC7990] defined a framework for how RFCs would be published, including new "publication formats" and a new "canonical format". --> <t><xref target="RFC7990"/> defined a framework for how RFCs would be published after that document was published, including new formats and a new "canonical format" for archiving RFCs. It talked about "the XML file" as if there would only be one XML file for an RFC because that was the expectation at the time <xref target="RFC7990"/> was published. It also talked about "publication formats" as the versions of HTML, text, and PDF derived from the "canonical format".</t> <t>After extensive experience with publishing RFCs in the RFCXML format <xref target="RFC7991"/>, it has been decided that an RFC's XML file can be updated for narrowly limited purposes. This document changes <xref target="RFC7990"/> in significant ways:</t><t><list style="symbols"><!-- [rfced] If no objections, we will use a definition list under the first bullet in Section 1.1. Original: * It defines four terms that replace the use of the term "canonical" and clarifies "format": - The "definitive format", which is RFCXML - The "definitive version", which is a published RFC in the definitive format - A "publication format", which is currently one of PDF, plain text, or HTML - A "publication version", which is a published RFC in one of the publication formats Perhaps: * It defines four terms that replace the use of the term "canonical" and clarifies "format": definitive format: RFCXML definitive version: a published RFC in the definitive format publication format: currently one of PDF, plain text, or HTML publication version: a published RFC in one of the publication formats --> <ul spacing="normal"> <li> <t>It defines four terms that replace the use of the term "canonical" and clarifies "format":<list style="symbols"></t> <ul spacing="normal"> <li> <t>The "definitive format", which is RFCXML</t> </li> <li> <t>The "definitive version", which is a published RFC in the definitive format</t> </li> <li> <t>A "publication format", which is currently one of PDF, plain text, or HTML</t> </li> <li> <t>A "publication version", which is a published RFC in one of the publication formats</t></list></t></li> </ul> </li> <li> <t>It defines a policy governing how the RFCXML format changes.</t> </li> <li> <t>It defines a policy for when the definitive version of an RFC can be updated and older definitive versions archived.</t> </li> <li> <t>It defines a policy for when the publication versions of an RFC can be updated and older publication versions archived.</t></list></t></li> </ul> <t>When using the new terminology, it is important to note that <xref target="RFC7990"/> used the term "canonical format" to mean two very different things. Quoting from RFC 7990:</t><ul empty="true"><li><blockquote> <t>Canonical format: the authorized, recognized, accepted, and archived version of the document</t></li></ul></blockquote> <t>and</t><ul empty="true"><li><blockquote> <t>At the highest level, the changes being made to the RFC format involve breaking away from solely ASCII plain text and moving to a canonical format that includes all the information required for rendering a document into a wide variety of publication formats.</t></li></ul></blockquote> <t>This document uses two terms, "definitive version" and "definitive format", for the earlier term "canonical format".</t><t>Other terminology changes made by this<t>This documentarealso makes thefollowing: - Itfollowing terminology changes:</t> <ul spacing="normal"> <li>It changes the phrase "xml2rfc version 3" to"RFCXML". - It"RFCXML".</li> <li>It changes the name of the body that publishes RFCs from "RFC Editor" to "RFC Production Center"(RPC).</t>(RPC).</li> </ul> <t>Historical text from <xreftarget="RFC7990"/>target="RFC7990"/>, such asSection 2Sections <xref target="RFC7990" section="2" sectionFormat="bare"/> ("Problem Statement"),Section 4<xref target="RFC7990" section="4" sectionFormat="bare"/> ("Overview of the Decision-Making Process"), andSection 10<xref target="RFC7990" section="10" sectionFormat="bare"/> ("TransitionPlan") werePlan"), was purposely omitted from this document. Text from <xref target="RFC7990"/> that repeated what was in other RFCs, particularlySection 8 (Figures and Artwork) and Section 9 (ContentSections <xref target="RFC7990" section="8" sectionFormat="bare" /> ("Figures and Artwork") and <xref target="RFC7990" section="9" sectionFormat="bare" /> ("Content and PageLayout) wereLayout"), was also removed.</t> </section> <sectionanchor="changes-to-9280"><name>Changesanchor="changes-to-9280"> <name>Changes to RFC 9280</name><t>Section 7.6 of <xref target="RFC9280"/> currently<t><xref target="RFC9280" sectionFormat="of" section="7.6" /> says:</t><ul empty="true"><li><blockquote> <t>Once published, RFC Series documents are not changed.</t></li></ul></blockquote> <t>This document replaces that sentence with:</t><ul empty="true"><li><blockquote> <t>Once published, RFCs may bere-issued,reissued, but the semantic content of publication versions shall be preserved to the greatest extent possible.</t></li></ul></blockquote> <t>This document alsocreatesadds a new policythat would exist in Section 7 ofto <xreftarget="RFC9280"/>:</t> <ul empty="true"><li>target="RFC9280" sectionFormat="of" section="7"/>:</t> <!-- [rfced] Does "to maintain a consistent presentation" apply to all verbs (in which case, "published" seems odd)? Please review. Original: 7.8. Consistency RFCs are copyedited, formatted, published, and may be reissued to maintain a consistent presentation. Perhaps A (two sentences): 7.8. Consistency RFCs are copyedited, formatted, and then published. They may be reissued to maintain a consistent presentation. Perhaps B (remove "published"): RFCs are copyedited and formatted and may be reissued to maintain a consistent presentation. --> <blockquote> <t>7.8. Consistency</t><t>RFCs<t indent="3">RFCs are copyedited, formatted, published, and may be reissued to maintain a consistent presentation.</t></li></ul> <t><xref target="updating"/></blockquote> <!-- [rfced] Should "updated policy" here be updated to "new policy"? Original: Section 2.1 and Section 3 in this document are based on this updated policy in [RFC9280]. Perhaps: Sections 2.1 and 3 in this document are based on this new policy in [RFC9280]. --> <t>Sections <xref target="updating" format="counter"/> and <xreftarget="pub-versions"/>target="pub-versions" format="counter"/> in this document are based on this updated policy in <xref target="RFC9280"/>.</t> </section> <sectionanchor="key-changes-from-the-earlier-rfc-process"><name>Keyanchor="key-changes-from-the-earlier-rfc-process"> <name>Key Changes from the Earlier RFC Process</name> <!-- [rfced] Please review "following the guidance of the group of RFCs described in [RFC7990]". Are any updates needed for clarity? Original: The first RFC to be published following the guidance of the group of RFCs described in [RFC7990] was [RFC8651], published in October 2019. Perhaps: The first RFC to be published following the guidance in [RFC7990] was [RFC8651], published in October 2019. --> <t>The first RFC to be published following the guidance of the group of RFCs described in <xref target="RFC7990"/> was <xref target="RFC8651"/>, published in October 2019. In the time since then, all published RFCs have followed the general plan from <xref target="RFC7990"/>.</t> <t>At the highest level, the changes that <xref target="RFC7990"/> made to the RFC format involved breaking away from solely ASCII <xreftarget="RFC20"/>target="RFC0020"/> plain text and moving to a definitive format that includes all the information required for rendering a document into a wide variety of publication formats. The RPC became responsible for more than just the plain-text file and a PDF rendering that was created from the plain text at the time of publication; the RPC now creates the definitive version and three publication versions of the RFC in order to meet the diverse requirements of the community.</t> <!-- [rfced] Is "publication formats" correct here? We ask because Section 3 is titled "Publication Versions". Also, would it be helpful to include references for the other RFCs that specify these? Original: The publication formats are described in Section 3 and fully specified in other RFCs. --> <t>The final RFCXML file produced by the RPC is the definitive version for RFCs; it holds all the information intended for an RFC. Additional publication versions (HTML, PDF, and plain text) are also published by the RPC. The publication formats are described in <xref target="pub-versions"/> and fully specified in other RFCs.</t> </section> </section> <sectionanchor="definitive-version-of-an-rfc"><name>Definitiveanchor="definitive-version-of-an-rfc"> <name>Definitive Version of an RFC</name> <!-- [rfced] Please review "The definitive version...is the publication version". Should this be updated as follows? Original: The definitive version produced by the RPC is the publication version that holds all the information intended for an RFC. Perhaps: The definitive version produced by the RPC holds all the information intended for an RFC. --> <t>The definitive version produced by the RPC is the publication version that holds all the information intended for an RFC. The RPC may change the definitive version of an RFC over time (that is, change the XML file), as described in <xref target="updating"/>. See <xref target="RFC7991"/> for the original complete description of RFCXML.</t> <!-- [rfced] Should "HTML publication versions" be singular? Original: That SVG will also appear in the HTML publication versions. --> <t>The XML may contain SVG line art, as originally described in <xref target="RFC7996"/>. That SVG will also appear in the HTML publication versions. The XML may contain non-ASCII characters, as originally described in <xref target="RFC7997"/>. These characters will appear in all the publication versions.</t> <t>The definitive version must contain all information necessary to render the specified publication versions; any question about what was intended in the publication will be answered from this file. It is self-contained with all the semantic content known at publication time. For instance, all features that reference externally defined input are expanded. It does not contain src attributes for <artwork> or <sourcecode> elements. It does not contain comments or processing instructions.</t> <sectionanchor="updating"><name>Updatinganchor="updating"> <name>Updating the Definitive Version of an RFC</name> <t>RFCs may bere-issued,reissued, as described in <xref target="changes-to-9280"/>. Such changes must preserve the semantics expressed in the original RFC. Reasons to make such changes include updates to the RFCXML schema, errors discovered in the XML, and changes to the tooling used to generate the publication versions of the definitive version of the RFC. The RPC will keep a public record of when itre-issuesreissues anyRFC,RFC and give a short description of its reasoning for each change.</t> </section> <sectionanchor="expected-updates-to-rfcxml"><name>Expectedanchor="expected-updates-to-rfcxml"> <name>Expected Updates to RFCXML</name> <t>It is anticipated that <xref target="RFC7991"/> will be updated. Updates to the RFCXML specification that are applied to existing RFCs should preserveto the greatest extent possiblethe semantics expressed in the originalRFC.RFC to the greatest extent possible. The goal of limiting changes only to syntax is to preserve the semantic meaning encoded in the published document.</t> <!-- [rfced] To avoid personifying "updates" (updates consider, take steps, limit), we suggest the following. Original: Instead, it only requires that such updates consider the potential for semantic changes, take steps to understand the risk of a semantic change (either deliberate or inadvertent), and to limit those risks. Original: Instead, it only requires that the potential for semantic changes be considered, steps to understand the risk of a semantic change (either deliberate or inadvertent) be taken, and associated risks be limited. --> <t>This policy does not require that updates to RFCXML avoid all risk of introducing semantic changes to existing RFCs. Instead, it only requires that such updates consider the potential for semantic changes, take steps to understand the risk of a semantic change (either deliberate or inadvertent), andtolimit those risks.</t> </section> </section> <sectionanchor="pub-versions"><name>Publicationanchor="pub-versions"> <name>Publication Versions</name> <t>The RPC is permitted but not required tore-issuereissue publication versions of an RFC, as described in <xref target="changes-to-9280"/>. In deciding whether to update the publication versions of an RFC, the RPC will take into account both the risk of semantic changes and consistency of theseries.</t>Series.</t> <t>XML format errors and better design choices have been discovered by the community since the first RFCs were published using the RFCXML format. When the XML in a definitive version changes, the publication versions may change, even if this might not result in observable differences. Similarly, as production tools change, publication versions may be regenerated to ensure a consistent presentation.</t> </section> <sectionanchor="archived-documents"><name>Archivedanchor="archived-documents"> <name>Archived Documents</name> <t>The RPC will keep an archived set of all definitive versions of RFCs as well as archived sets of the publication versions for an RFC that were previously published. These archived sets must be available using the same access methods as for current definitive and publication versions. Every archived set shall record the date that a definitive and/or publication version was created or reissued.</t> <t>When the RPC archives definitive and publication versions, it does so in a manner that allows them to be found by people who want the historical (as compared to current) files.</t> <t>This document does not specify how archives are maintained or how archived documents might be located or identified. The methods for storage and access will be determined by the RPC in consultation with the technical community.</t> </section> <sectionanchor="iana-considerations"><name>IANAanchor="iana-considerations"> <name>IANA Considerations</name> <t>This document has no IANAconsiderations.</t>actions.</t> </section> <sectionanchor="security-considerations"><name>Securityanchor="security-considerations"> <name>Security Considerations</name> <!-- [rfced] Should "definitive versions" here be singular (i.e., "definitive version")? Original: Allowing changes to the definitive versions and publication versions of RFCs introduces risks. Perhaps: Allowing changes to the definitive version and publication versions of RFCs introduces risks. --> <!-- [rfced] Would it be helpful to either add numbers or use two sentences here to improve clarity? Original: A significant risk is that unintended changes could occur in either the definitive version or publication versions of an RFC as a result of an editing error, or may be introduced into a publication version when it is regenerated from the definitive version. Perhaps (add numbers): A significant risk is that unintended changes could 1) occur in either the definitive version or publication versions of an RFC as a result of an editing error or 2) be introduced into a publication version when it is regenerated from the definitive version. Or (split into two sentences): A significant risk is that unintended changes could occur in either the definitive version or publication versions of an RFC as a result of an editing error. In addition, unintended changes may be introduced into a publication version when it is regenerated from the definitive version. --> <!-- [rfced] To improve clarity, may we update the text starting with "and harm" as follows? Original: This may result in the corruption of a standard, practice, or critical piece of information about a protocol, and harm to the reputation of the RFC series. Perhaps: This may result in the corruption of a standard, practice, or critical piece of information about a protocol, which may harm the reputation of the RFC Series. --> <t>Allowing changes to the definitive versions and publication versions of RFCs introduces risks. A significant risk is that unintended changes could occur in either the definitive version or publication versions of an RFC as a result of an editing error, or may be introduced into a publication version when it is regenerated from the definitive version. This may result in the corruption of a standard, practice, or critical piece of information about a protocol, and harm to the reputation of the RFCseries.</t>Series.</t> <t>The RPC is expected to identify, track, and actively mitigate risks introduced by this new policy.</t> </section> </middle> <back> <displayreference target="RFC0020" to="RFC20"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7991.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7996.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7997.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9280.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6949.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7990.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8651.xml"/> </references> </references> <sectionanchor="acknowledgments"><name>Acknowledgments</name> <t>Martin Thomsonanchor="acknowledgments" numbered="false"> <name>Acknowledgments</name> <t><contact fullname="Martin Thomson"/> wrote a great deal of the significant text here as part ofdraft-thomson-rswg-syntax-change.</t>draft-thomson-rswg-syntax-change-01.</t> <t>This document has greatly benefited from the input of the RSWG. In particular,Alexis Rossi, Brian Carpenter, Eliot Lear, Jay Daley, Jean Mahoney, John Levine, and Pete Resnick, gave<contact fullname="Alexis Rossi"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Eliot Lear"/>, <contact fullname="Jay Daley"/>, <contact fullname="Jean Mahoney"/>, <contact fullname="John Levine"/>, and <contact fullname="Pete Resnick"/> provided significant input on the earlydraftsdraft versions of this document.</t> </section></middle> <back> <references title='References' anchor="sec-combined-references"> <references title='Normative References' anchor="sec-normative-references"> <reference anchor="RFC7991"> <front> <title>The "xml2rfc" Version 3 Vocabulary</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="December" year="2016"/> <abstract> <t>This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 7749.</t> </abstract> </front> <seriesInfo name="RFC" value="7991"/> <seriesInfo name="DOI" value="10.17487/RFC7991"/> </reference> <reference anchor="RFC7996"> <front> <title>SVG Drawings for RFCs: SVG 1.2 RFC</title> <author fullname="N. Brownlee" initials="N." surname="Brownlee"/> <date month="December" year="2016"/> <abstract> <t>This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams.</t> </abstract> </front> <seriesInfo name="RFC" value="7996"/> <seriesInfo name="DOI" value="10.17487/RFC7996"/> </reference> <reference anchor="RFC7997"> <front> <title>The Use of Non-ASCII Characters in RFCs</title> <author fullname="H. Flanagan" initials="H." role="editor" surname="Flanagan"/> <date month="December" year="2016"/> <abstract> <t>In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve<!-- [rfced] Would you like toallow for theuseof non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing forabroader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.</t> <t>This document updates RFC 7322. Please view this document in PDF form to see the full text.</t> </abstract> </front> <seriesInfo name="RFC" value="7997"/> <seriesInfo name="DOI" value="10.17487/RFC7997"/> </reference> <reference anchor="RFC9280"> <front> <title>RFC Editor Model (Version 3)</title> <author fullname="P. Saint-Andre" initials="P." role="editor" surname="Saint-Andre"/> <date month="June" year="2022"/> <abstract> <t>This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks relatedconsistent ordering when referring to theRFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream forpublicationof future policy definition documents produced throughformats? We see theprocesses defined herein.</t> <t>This document obsoletes RFC 8728. This document updates RFCs 7841, 8729,following (also note "text" and8730.</t> </abstract> </front> <seriesInfo name="RFC" value="9280"/> <seriesInfo name="DOI" value="10.17487/RFC9280"/> </reference> </references> <references title='Informative References' anchor="sec-informative-references"> <reference anchor="RFC20"> <front> <title>ASCII format for network interchange</title> <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/> <date month="October" year="1969"/> </front> <seriesInfo name="STD" value="80"/> <seriesInfo name="RFC" value="20"/> <seriesInfo name="DOI" value="10.17487/RFC0020"/> </reference> <reference anchor="RFC6949"> <front> <title>RFC Series Format Requirements"plain text"): HTML, text, andFuture Development</title> <author fullname="H. Flanagan" initials="H." surname="Flanagan"/> <author fullname="N. Brownlee" initials="N." surname="Brownlee"/> <date month="May" year="2013"/> <abstract> <t>This document describes the current requirementsPDF PDF, plain text, or HTML HTML, PDF, andrequests for enhancements forplain text --> <!-- [rfced] Please review theformat"Inclusive Language" portion of thecanonical version of RFCs. Termsonline Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes aredefined to help clarify exactly which stagesneeded. Updates ofdocument production are under discussionthis nature typically result in more precise language, which is helpful forformat changes. The requirements describedreaders. Note that our script did not flag any words in particular, but thisdocument will determine what changes will be made to RFC format. This document updates RFC 2223.</t> </abstract> </front> <seriesInfo name="RFC" value="6949"/> <seriesInfo name="DOI" value="10.17487/RFC6949"/> </reference> <reference anchor="RFC7990"> <front> <title>RFC Format Framework</title> <author fullname="H. Flanagan" initials="H." surname="Flanagan"/> <date month="December" year="2016"/> <abstract> <t>In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication formats willshould still berendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document servesreviewed asthe framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan.</t> </abstract> </front> <seriesInfo name="RFC" value="7990"/> <seriesInfo name="DOI" value="10.17487/RFC7990"/> </reference> <reference anchor="RFC8651"> <front> <title>Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension</title> <author fullname="B. Cheng" initials="B." surname="Cheng"/> <author fullname="D. Wiggins" initials="D." surname="Wiggins"/> <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/> <date month="October" year="2019"/> <abstract> <t>This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enablesamodem to use DLEP messages to pause and resume data traffic coming from its peer router.</t> </abstract> </front> <seriesInfo name="RFC" value="8651"/> <seriesInfo name="DOI" value="10.17487/RFC8651"/> </reference> </references> </references> </back> <!-- ##markdown-source: H4sIAAAAAAAAA71aa4/byLH9zl/RkIGbMSDp2pPEXo+BRSZjO55kvevr8W7y 7aJFtqTOUGymmxxZMfzf76mq7ib1sp0vF1hjOVQ/qutx6lQ1Z7NZ0dmuNlfq w5sb9cb5je6C0k2lfjM+WNeEQi8W3jx8ZUDlykZvsETl9bKb+bBdzfyyfP7i xZNZ31a6M2H29LIoQodp/6tr12Bs53tTYNXfF24RXG0w6ErRlCJOuVIvLn94 UhS29Tw6dJdPnrx4clncb6/UbdMZ35hu9oq2LErdXSnbLF0R+sXGBpLr467F NqaynfNW10Wh+27t/FWhZoVSGI0d3s/VW7dcbnRDr+QQ73Vfj986v8J+N9c/ /0x/mY229ZVqMWi+lkF/sqVumjnGjZd+O1dvat3o1Xjtt0Z3a+P3fuH171q8 xjq1unFb/GtCX3e2WY22XNfLP4U0rHTbMg+al25TFA2bxj4YnJBsBV0+HR6f DY/P4yOp9wr6hdr2Z14+iQ/PXvzhxTAvvf3h2R+xcDGbzZRehM7rsiuK2wYH qXC0zim7ab17MApHVd7oSi9sbbudckuaHtR2bWujQt+2zpP8NNB6pX25tg9x 8JRnV2ZpG0uiqQfxNlqEfiFnvIMuTIBv6CZgENyqUkvvNqqttW1mnfnUqeu7 m9tbEuof735SfYi70XR68eBKvehr7XcvVWWXS+NN06m2X9RQMq2YtoXHezpM gyOmXbq17tRCB4jpyn6DmfPi49qG/CfED6W3C8i4hlX57LQMrx/WppoXBxNy KPD5SOeHS+o6OBUjhE+CoIrqbR2k3sH7eDJZF+uzmTa2qmpTFI8obryr+pLO VhSTkRYlstUH86/eekN7SZS/6bseMr8yD6Z2Lb2fqM+fo3N8+QK1hbIPAUoh aRpDD/sugBEwCJvfdmYTYPlyrTSW54Dk0JC9tO+2zt/HIwQaszV1Tf8/t/ih b+HnRd4SwzGyNb7GANhSe+t6KNM82NKEefFnTXLjlygmHYSNvbXdWiGqNj15 H6Qj2QlyTOimWX6adfv645vpoUe+ZtDBPqWtRGTzqa0d1KhVudbNytA7miSh l5xaps8L1i9ZH/rdxo3Kvt7YRpySh2OarMrvjlwJz0CIklCykvPQKm22ftLY FDKUEhhREdk982IQ6Rbe7HC0xsEHqwqKIJPt4nFCOg/Wh2YDXhgNJQEdjN4g 7mREJU7EtkZKsWYbQ39A7aAuQgu9LQnlasAARc4+2pN54BRkZlnPVI/nxd8Z VG5nrxBs+oE0HezGIrRVMKxgrN9HP4uKwdkr+HrZwT3imQQfHGI6DoeBZNGw dn1dReeKHk9qha/yUbPi5cxsD5KwA3iHjAQV+Xa3H9FwCxgSYoirQDiAYs8u Ep0Fzg5gtRuTvC655o6Pk7zv/WDcG0MqUxcf3t88ViugIU7Se849tBfcDBqg QKo51BMsMoSQBw/yYorBYW7TUOeD+B8pCXK0gF3GCvLu6sEGOYV+cBYBDSVu ZHFN2FVL7CSnSXZc6PJ+q30VZrQg/HlR056PHqmbwb0SIhZ74cEZAltqYDJw hOGDbJYBd5vMNrg1fIj0SSJlK1CY5RFTWKms+4okb+CkyxHr0fxmgpTvGk7Y 8uOEd5UURtNob46aTtf3tOfC9Z2akJIp8SzhrBOypuXIh+5ETtfAFyEslJrH ycqC6gtTakSTCJ+gQbxHoAGv6RU7yyGMjPLObcwk+9KNE1888yS5XE6EMP7b j+9+Aughv05ZJ+9fvYEhPNJ0To3mhIpg0mtWPSYapOwHM3ZGxqgoYtKgREtO 1xEt07mefvkCS3WI9wDFmGYAXPY21tjvwqBHCES6lexZsVob7b3bQuc1wIJe tr1v4dnhMO8mlx3rFMIFu2oYq9iFdoF4kSKsZLck+OjhacZvggjlDfJSKamL 7BiBn0aMFDYRlAJ4YW2sMokKJAKm1EwRskxG3Cj+PCVmhfCyISrszPBoyvF4 PQoP8rOo96M94orXp3xlvF7Ze6JSnHf5lHCRqfCy6DdQPrnR6QW/T8K4dM5Z +567bwid6NGKwLQhByOIOHauaOj5menkNNu1OVLPiJ7GUD3wNrKoq4khH88K ETgoMr9j25P89Ds2PsNr085Iodhg4MiEc+SYtnG1W+041GAIJA3QdnJ4gDLo QASjcWD0iQ4e+HXGSszcGIgJukeS7EbkmzLqKszV//SO0xLjScJ+hNeP6uZg uSshgkwm7b8JvZHTHeKSn3VZmrbjJ2aYctrDciLFOarEpqJNrgVH13a1BudT NTEN4XkJCRaGxNvoKpM5kjJ6kW0eXA0Do3LW9zROAx3kLMTwERdSmAwRweJt HCcPyp/qUGuiZklM5BpInbRpLt9wGC/kXaBNihXee8QKG157C5hkOmyEOp8I nyNCKSQOBmM4m55EFD7ESWQiiThXaV9b4895Bnb9hVnKyPGyxlnXi90J/iRU uq7dFue9khjKzJQiZu2pTpt82tSXfllm6/+eXXEiCDCZH0+k2iT5yMJVOzFC QqIgSYrNyrWUEP+86DEjmwglwzHf2kCNCTo7m58XGQdRqjLujCxwqS4mWA/U aKPukO2ZjU0eT/OAP2DALzgZ8+oo8ytkRDrp7J244Xvh5zSNTJWmPn2CuR9z Ha3e17qZPEbxxdUqZ0SCcqTIbkjxIyMgW548Q8p5hpFom0gLYTdbWQqQFnWf LakMxyZJpB/UxRu7QukptOtaSsPHe2K/UBc3YMvsBURDNLjyT3oHLhNlZ46D atYJwJ1glFQmq8+Pos1nnZvRmy9FkfZ4Pn9GyuRT8U9fRsktSMr/Uf1CDGbE H0fFYC6i2FOpfpLNjqv/SA4iVQjkMIkYnduEgoIJozczrljwetELdgWzAUrb kisK7i4sT6eAsNbCw1toG/4jDJ6WWHmyXOiEscHxHUokIecn2hKljI4UOWYu YapMbs0n+DwZP+v2QLN8yufzH+aKW2AYDQXs8A7/5e5J6doddfXoqIIa/DjS CyNpUotohTMOoLYjuNWkEVm9kzM3XSqiP3/mvIlYgaFpoc+fsfIs6UpY3zEA LYZOAn5KqXfoyIwOKYXN38wuu2KmzK8jOEbooEiVMnJpPTRHr6W/MVChjHpi r95Wmrwkhv/Ku77NvZG9IvSwOOC/qbVHpHpYHyN/KTu3gFSXT56+mFOjLxcY oArCZZsp56M9hhbrcBEw8oGVaYwH4sHPmyO0oPLgm1n3iGt8PQFX38zAvNYl rfSVXHyU0f7fkzF5ATIHF4Ab8uvQkg8vYnm4cZwFodV/9kGUOGqCcvUjxSuV aoMwuYyU0B1Vb2NljErKffFeitYhVgMuncL/DDOWToU35/lrMqEd9ZI3xnSx PUdDTVKrIGqclNsh8xQuDZws8Xo6vPS9yB12WWZ7VlTSKHnwS64uQZ5PW5g6 gk0VLSzke15cVxXnUF2fPueFFM9cD5FKBkU/lh4KIekQSIO84gMnnIOnHcT2 AWbRRsu+powlzTUZNyRhTo5gC1kVvx3WM6mfdaSsr6j2hALE5f5DnSbnJ1BP /dNvlV9Dz+xCYhVEYzQ3eQYRoSNkHFLAHDzAjBsOmciCu63YzahlRT37uEg7 aq5ik+iRtB1L7yQF3f32F1WjxKOWN0uQloOJTsL0M5LlIx2EpnLjjD1FtyBX PtXr5Fsn3W5+UgqQ75mgIDRD9zgY/V3SPBdpTDCjmVGqLFAy72l5zrnThvAr CUhLjL2jMZQTNQrGzkUYE6qTvfrUZi+5U/2vHimFgYibXSMyGj3OHlfXqUEJ YrwdX/zAv8l5uI+GZ7Dj5SzKnLrt6fRHLOweWMl9uvFG5Kjz4o0jxdE1aWkk oy4BqcyBI5PmIrk0zMd8MpB0QG3T9rmbrOlE+137pNPgS+zewaZ9Fxvc/1V3 L+Pdy48q/h1c70vU0ZX5URlp/UpD83hFgl+BY58uACi50Em8VD9BSM+vMa5i aXIebMDIcwwWxRmeexy3hyyewnfcb2bfSiR3zzqBlEYXAIMf5ABnCPpgdCD4 Zh55b/b72JEHDPdymY5QxIVyjV2mynhPzXO6PiBwGnb6ByUE7vjtX6Z0DvwR 2upjT13YU2e+2gT65rXpAKfs3ffGtKm5VnLnxFc0mrtNtssKl+sezBdRV1bu WNbOd4fIZ+EKnvXFDRx4Bd+QyOnEE16nC49fB5XFnmWMKTaLbZmV7JE+AuEU l5Foz4tfT2s+3SR1OfNwim3b2qZ7OZQBudsc73gGD/l6FfSfeRBpfeXwFzTE 3WbaNlmc+/7YLuwQUp84f7rTnsqNM5oKHHCHsLV3a5eKtFiF5LCNDEr00R/q P93cQMHehvt488k5nnYd4Gzw1T0lUoWAykpX3C/kc8UNU11LkZO25UIsoXjr SL1WukFHO6EO4MDrTMu79oT+/EkJT07C6sOJ6sJY5jmVqQEVHECMs7pCcNCO sRmCNdku8W6LFoy86P0o1tJXL4CoPZJV5LAilVP3inslVIyPlF5J4pKQ+kYj 9zsR7jbee5ABELTSPUvfCHxHv3iaWRtHFStZKpOydD3cfeHi5XFS8ZEPxDvV VLAnsAnxOrsYtdcjCNKMhek6NgtdomAtR5fyUjTKbc4AlJFaDteeufIcSuOQ 2lUpDo6+9hAR5tLnTiSQ+wEnAHPwunMaHNgosP2B0HIp1GCD8jVZnT7RYaq9 oFDWhBqp182fINzJJTXddNMN3dAvJPAPef2zAnBKTIlBIK0JvXxpcLbJ8Uhd pz74q9SdKk6lhWZomMdbdMKFUxcYqccw+mRjPDWnppMHGV1wSkXKhqQvBFwf ACCji0shnftLc1onlvagoUtS8WD6QNUy3QEEjENwuIplpB1jG298HC7ITtLV 13xNsacNaZvFjMlpV6fLEH2w6H+7k7cve6U3dwmE26S7mBSYcdvwPaIy7DLW ozpg50awNum+W1MzhouzTWwlLRHjHGCtcahjACEOYjWpEZOb1BckKt3ORxCL 2nvMRPj4tiBnG8nBO75ty+egLJzacXL00c+j705iKEHM2pVJS8gXQB9i+5JU k1k5aUBc6gJzs0OsPnwsIncKB5Vqo+KHdInxR7DrTLmWq4lxd4E+obr++Vra k5WRb2/C4eHpQrpxMrLcGylL3Bloj2DscJnr1Mw7YIInrwzPOEAOxZS2sUzM Zdd799UM5zZmZRww1UFp71K+SCghK6kpZtFz/PLM9eJA6QkREiDKW+riMpOh nMA3whHRsuRV6pGdDJ7IUG3Yg8DcwjqWMl7q0y4DMkti8b7P/FUrphXaU1uZ iltL5RghBozGLtFaI03WcXEqdaUmEO9c6WphFSiPN8mM3qBEG33CJe2unCZH BGL8QVD0d/okEsLcx4vMkg4GbCQiuSLgYRuPVZduyoZm/FwpBv+SatDaVKuI /O/oAqZRH9duE0ixnm51tfBeqFE4K6PpyH24N8ifrlDiwgo0SL4A7mQh+RJY KO0ss//jUOF9+LuXBibbs6EUtUlZd3//C/Od4cJoipAh+qk+ECefFn/2Fo51 o33L123T4nVtAUI/GRr6V9j9la7NDo90+/xOr13Df7l1gzEPAIdpwTdJ1M/5 YAIA4H5arIiSjI8epWryjeZODh6z3N7FGH+ASR84Ff8Hbje5NGwtAAA=best practice. --> </back> </rfc>