rfc9720xml2.original.xml   rfc9720.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='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) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-rswg-rfc7990-updates-12" category="info" s <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
ubmissionType="editorial" obsoletes="7990" updates="9280" tocInclude="true" sort -rswg-rfc7990-updates-12" number="9720" category="info" submissionType="editoria
Refs="true" symRefs="true"> l" obsoletes="7990" updates="9280" tocInclude="true" sortRefs="true" symRefs="tr
ue" version="3" xml:lang="en">
<front> <front>
<title abbrev="RFC Formats and Versions">RFC Formats and Versions</title> <title abbrev="RFC Formats and Versions">RFC Formats and Versions</title>
<seriesInfo name="RFC" value="9720"/>
<author initials="P." surname="Hoffman" fullname="Paul Hoffman"> <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
<organization>ICANN</organization> <organization>ICANN</organization>
<address> <address>
<email>paul.hoffman@icann.org</email> <email>paul.hoffman@icann.org</email>
</address> </address>
</author> </author>
<author initials="H." surname="Flanagan" fullname="Heather Flanagan"> <author initials="H." surname="Flanagan" fullname="Heather Flanagan">
<organization>Spherical Cow Consulting</organization> <organization>Spherical Cow Consulting</organization>
<address> <address>
<email>hlf@sphericalcowconsulting.com</email> <email>hlf@sphericalcowconsulting.com</email>
</address> </address>
</author> </author>
<date year="2025" month="January"/>
<date year="2024" month="August" day="06"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>Internet-Draft</keyword> <keyword>example</keyword>
<abstract> <abstract>
<?line 40?>
<t>In order to improve the readability of RFCs while supporting their archivabil ity, 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. <t>In order to improve the readability of RFCs while supporting their archivabil ity, 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> This document describes how RFCs are published.</t>
<t>This document obsoletes RFC 7990.
<t>This document obsoletes RFC 7990.
This document also updates the stability policy in RFC 9280.</t> This document also updates the stability policy in RFC 9280.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 49?> <section anchor="introduction">
<name>Introduction</name>
<section anchor="introduction"><name>Introduction</name>
<t>"RFC Series Format Requirements and Future Development" <xref target="RFC6949 <t>"RFC Series Format Requirements and Future Development" <xref target="R
"/> discussed the need to improve the display of items such as author names and FC6949"/> discussed the need to improve the display of items such as author name
artwork in RFCs as well as the need to improve the ability of RFCs to be display s and artwork in RFCs as well as the need to improve the ability of RFCs to be d
ed properly on various devices. isplayed properly on various devices.
Based on the discussions with communities of interest, such as the IETF, the RFC Based on discussions with communities of interest, such as the IETF, the RFC Ser
Series Editor decided to explore a change to the format of the Series. ies Editor decided to explore a change to the format of the Series.
<xref target="RFC7990"/> was the culmination of that exploration.</t> <xref target="RFC7990"/> was the culmination of that exploration.</t>
<t>This document is concerned with the production of RFCs, focusing on the
<t>This document is concerned with the production of RFCs, focusing on the publi published documents.
shed documents. It does not address any changes to the processes each stream uses to develop and
It does not address any changes to the processes each stream uses to develop and review their submissions (specifically, how Internet-Drafts are developed).
review their submissions (specifically, how Internet-Drafts will be 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> 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 chan
ge over time as the community and the RFC Production Center (RPC) gain further e
xperience implementing the policies described here.</t>
<t>Implementors of these components are advised to avoid assuming that all
such changes will be backwards compatible.</t>
<section anchor="changes-to-rfc-7990">
<name>Changes to RFC 7990</name>
<!-- [rfced] We wonder about trimming this sentence down for simplicity.
<t>The details described in this document are expected to continue to change ove Original:
r time as the community and the RFC Production Center (RPC) gains further experi [RFC7990] defined a framework for how RFCs would be published after
ence implementing the policies described here.</t> that document was published, including new formats and a new
"canonical format" for archiving RFCs.
<t>Implementors of those components are advised to avoid assuming that all such Perhaps A:
changes will be backwards-compatible.</t> [RFC7990] defined a framework for how RFCs would be published.
<section anchor="changes-to-rfc-7990"><name>Changes to RFC 7990</name> 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 fo rmat" for archiving RFCs. <t><xref target="RFC7990"/> defined a framework for how RFCs would be pub lished after that document was published, including new formats and a new "canon ical 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 publi shed. 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 publi shed.
It also talked about "publication formats" as the versions of HTML, text, and PD F derived from the "canonical format".</t> It also talked about "publication formats" as the versions of HTML, text, and PD F derived from the "canonical format".</t>
<t>After extensive experience with publishing RFCs in the RFCXML format
<t>After extensive experience with publishing RFCs in the RFCXML format <xref ta <xref target="RFC7991"/>, it has been decided that an RFC's XML file can be upda
rget="RFC7991"/>, it has been decided that an RFC's XML file can be updated for ted for narrowly limited purposes.
narrowly limited purposes.
This document changes <xref target="RFC7990"/> in significant ways:</t> 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
<t>It defines four terms that replace the use of the term "canonical" and clar bullet in Section 1.1.
ifies "format":
<list style="symbols">
<t>The "definitive format", which is RFCXML</t>
<t>The "definitive version", which is a published RFC in the definitive fo
rmat</t>
<t>A "publication format", which is currently one of PDF, plain text, or H
TML</t>
<t>A "publication version", which is a published RFC in one of the publica
tion formats</t>
</list></t>
<t>It defines a policy governing how the RFCXML format changes.</t>
<t>It defines a policy for when the definitive version of an RFC can be update
d and older definitive versions archived.</t>
<t>It defines a policy for when the publication versions of an RFC can be upda
ted and older publication versions archived.</t>
</list></t>
<t>When using the new terminology, it is important to note that <xref target="RF Original:
C7990"/> used the term "canonical format" to mean two very different things. Quo * It defines four terms that replace the use of the term "canonical"
ting from RFC 7990:</t> and clarifies "format":
<ul empty="true"><li> - The "definitive format", which is RFCXML
<t>Canonical format: the authorized, recognized, accepted, and archived versio
n of the document</t>
</li></ul>
<t>and</t> - The "definitive version", which is a published RFC in the
definitive format
<ul empty="true"><li> - A "publication format", which is currently one of PDF, plain
<t>At the highest level, the changes being made to the RFC format involve brea text, or HTML
king away from solely ASCII plain text and moving to a canonical format that inc
ludes all the information required for rendering a document into a wide variety
of publication formats.</t>
</li></ul>
<t>This document uses two terms, "definitive version" and "definitive format", f - A "publication version", which is a published RFC in one of the
or the earlier term "canonical format".</t> publication formats
<t>Other terminology changes made by this document are the following: Perhaps:
- It changes the phrase "xml2rfc version 3" to "RFCXML". * It defines four terms that replace the use of the term "canonical"
- It changes the name of the body that publishes RFCs from "RFC Editor" to "RFC and clarifies "format":
Production Center" (RPC).</t>
<t>Historical text from <xref target="RFC7990"/> such as Section 2 ("Problem Sta definitive format: RFCXML
tement"), Section 4 ("Overview of the Decision-Making Process"), and Section 10
("Transition Plan") were purposely omitted from this document.
Text from <xref target="RFC7990"/> that repeated what was in other RFCs, particu
larly Section 8 (Figures and Artwork) and Section 9 (Content and Page Layout) we
re also removed.</t>
</section> definitive version: a published RFC in the definitive format
<section anchor="changes-to-9280"><name>Changes to RFC 9280</name>
<t>Section 7.6 of <xref target="RFC9280"/> currently says:</t> publication format: currently one of PDF, plain text, or HTML
<ul empty="true"><li> publication version: a published RFC in one of the publication formats
<t>Once published, RFC Series documents are not changed.</t> -->
</li></ul>
<t>This document replaces that sentence with:</t> <ul spacing="normal">
<li>
<t>It defines four terms that replace the use of the term "canonical
" and clarifies "format":
</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 def
initive 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 t
he publication formats</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 c
an be updated and older publication versions archived.</t>
</li>
</ul>
<t>When using the new terminology, it is important to note that <xref ta
rget="RFC7990"/> used the term "canonical format" to mean two very different thi
ngs. Quoting from RFC 7990:</t>
<ul empty="true"><li> <blockquote>
<t>Once published, RFCs may be re-issued, but the semantic content of publicat <t>Canonical format: the authorized, recognized, accepted, and archi
ion versions shall be preserved to the greatest extent possible.</t> ved version of the document</t>
</li></ul> </blockquote>
<t>and</t>
<blockquote>
<t>At the highest level, the changes being made to the RFC format in
volve breaking away from solely ASCII plain text and moving to a canonical forma
t that includes all the information required for rendering a document into a wid
e variety of publication formats.</t>
</blockquote>
<t>This document uses two terms, "definitive version" and "definitive fo
rmat", for the earlier term "canonical format".</t>
<t>This document also makes the following terminology changes:</t>
<t>This document also creates a new policy that would exist in Section 7 of <xre <ul spacing="normal">
f target="RFC9280"/>:</t> <li>It changes the phrase "xml2rfc version 3" to "RFCXML".</li>
<li>It changes the name of the body that publishes RFCs from "RFC Editor"
to "RFC Production Center" (RPC).</li>
</ul>
<t>Historical text from <xref target="RFC7990"/>, such as Sections <xref
target="RFC7990" section="2" sectionFormat="bare"/> ("Problem Statement"), <xre
f target="RFC7990" section="4" sectionFormat="bare"/> ("Overview of the Decision
-Making Process"), and <xref target="RFC7990" section="10" sectionFormat="bare"/
> ("Transition Plan"), was purposely omitted from this document.
Text from <xref target="RFC7990"/> that repeated what was in other RFCs, particu
larly Sections <xref target="RFC7990" section="8" sectionFormat="bare" /> ("Figu
res and Artwork") and <xref target="RFC7990" section="9" sectionFormat="bare" />
("Content and Page Layout"), was also removed.</t>
</section>
<section anchor="changes-to-9280">
<name>Changes to RFC 9280</name>
<t><xref target="RFC9280" sectionFormat="of" section="7.6" /> says:</t>
<blockquote>
<t>Once published, RFC Series documents are not changed.</t>
</blockquote>
<t>This document replaces that sentence with:</t>
<blockquote>
<t>Once published, RFCs may be reissued, but the semantic content of
publication versions shall be preserved to the greatest extent possible.</t>
</blockquote>
<t>This document also adds a new policy to <xref target="RFC9280" sectio
nFormat="of" section="7"/>:</t>
<ul empty="true"><li> <!-- [rfced] Does "to maintain a consistent presentation" apply to all verbs (in
<t>7.8. Consistency</t> which case, "published" seems odd)? Please review.
<t>RFCs are copyedited, formatted, published, and may be reissued to maintain Original:
a consistent presentation.</t> 7.8. Consistency
</li></ul>
<t><xref target="updating"/> and <xref target="pub-versions"/> in this document RFCs are copyedited, formatted, published, and may be reissued to
are based on this updated policy in <xref target="RFC9280"/>.</t> maintain a consistent presentation.
</section> Perhaps A (two sentences):
<section anchor="key-changes-from-the-earlier-rfc-process"><name>Key Changes fro 7.8. Consistency
m the Earlier RFC Process</name>
<t>The first RFC to be published following the guidance of the group of RFCs des RFCs are copyedited, formatted, and then published. They may be reissued t
cribed in <xref target="RFC7990"/> was <xref target="RFC8651"/>, published in Oc o
tober 2019. maintain a consistent presentation.
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 R Perhaps B (remove "published"):
FC format involved breaking away from solely ASCII <xref target="RFC20"/> plain RFCs are copyedited and formatted and may be reissued to maintain
text and moving to a definitive format that includes all the information require a consistent presentation.
d for rendering a document into a wide variety of publication formats. -->
<blockquote>
<t>7.8. Consistency</t>
<t indent="3">RFCs are copyedited, formatted, published, and may be
reissued to maintain a consistent presentation.</t>
</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 <xref target="pub-ver
sions" format="counter"/> in this document are based on this updated policy in <
xref target="RFC9280"/>.</t>
</section>
<section anchor="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 R
FCs described in <xref target="RFC7990"/> was <xref target="RFC8651"/>, publishe
d 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 <xref target="RFC0020
"/> plain text and moving to a definitive format that includes all the informati
on 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 rend ering that was created from the plain text at the time of publication; the RPC n ow creates the definitive version and three publication versions of the RFC in o rder to meet the diverse requirements of the community.</t> The RPC became responsible for more than just the plain-text file and a PDF rend ering that was created from the plain text at the time of publication; the RPC n ow creates the definitive version and three publication versions of the RFC in o rder 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. <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 b y the RPC. Additional publication versions (HTML, PDF, and plain text) are also published b y the RPC.
The publication formats are described in <xref target="pub-versions"/> and fully specified in other RFCs.</t> The publication formats are described in <xref target="pub-versions"/> and fully specified in other RFCs.</t>
</section>
</section>
<section anchor="definitive-version-of-an-rfc">
<name>Definitive Version of an RFC</name>
</section> <!-- [rfced] Please review "The definitive version...is the publication
</section> version". Should this be updated as follows?
<section anchor="definitive-version-of-an-rfc"><name>Definitive Version of an RF
C</name>
<t>The definitive version produced by the RPC is the publication version that ho Original:
lds all the information intended for an RFC. 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 t
hat holds all the information intended for an RFC.
The RPC may change the definitive version of an RFC over time (that is, change t he XML file), as described in <xref target="updating"/>. The RPC may change the definitive version of an RFC over time (that is, change t he XML file), as described in <xref target="updating"/>.
See <xref target="RFC7991"/> for the original complete description of RFCXML.</t > 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="RF C7996"/>. <t>The XML may contain SVG line art, as originally described in <xref target="RF C7996"/>.
That SVG will also appear in the HTML publication versions. That SVG will also appear in the HTML publication versions.
The XML may contain non-ASCII characters, as originally described in <xref targe t="RFC7997"/>. The XML may contain non-ASCII characters, as originally described in <xref targe t="RFC7997"/>.
These characters will appear in all the publication versions.</t> These characters will appear in all the publication versions.</t>
<t>The definitive version must contain all information necessary to render
<t>The definitive version must contain all information necessary to render the s the specified publication versions; any question about what was intended in the
pecified publication versions; any question about what was intended in the publi publication will be answered from this file.
cation will be answered from this file.
It is self-contained with all the semantic content known at publication time. It is self-contained with all the semantic content known at publication time.
For instance, all features that reference externally defined input are expanded. For instance, all features that reference externally defined input are expanded.
It does not contain src attributes for &lt;artwork&gt; or &lt;sourcecode&gt; ele ments. It does not contain src attributes for &lt;artwork&gt; or &lt;sourcecode&gt; ele ments.
It does not contain comments or processing instructions.</t> It does not contain comments or processing instructions.</t>
<section anchor="updating">
<section anchor="updating"><name>Updating the Definitive Version of an RFC</name <name>Updating the Definitive Version of an RFC</name>
> <t>RFCs may be reissued, as described in <xref target="changes-to-9280"/
>.
<t>RFCs may be re-issued, as described in <xref target="changes-to-9280"/>.
Such changes must preserve the semantics expressed in the original RFC. Such changes must preserve the semantics expressed in the original RFC.
Reasons to make such changes include updates to the RFCXML schema, errors discov ered in the XML, and changes to the tooling used to generate the publication ver sions of the definitive version of the RFC. Reasons to make such changes include updates to the RFCXML schema, errors discov ered in the XML, and changes to the tooling used to generate the publication ver sions of the definitive version of the RFC.
The RPC will keep a public record of when it re-issues any RFC, and give a short The RPC will keep a public record of when it reissues any RFC and give a short d
description of its reasoning for each change.</t> escription of its reasoning for each change.</t>
</section>
</section> <section anchor="expected-updates-to-rfcxml">
<section anchor="expected-updates-to-rfcxml"><name>Expected Updates to RFCXML</n <name>Expected Updates to RFCXML</name>
ame> <t>It is anticipated that <xref target="RFC7991"/> will be updated.
Updates to the RFCXML specification that are applied to existing RFCs should pre
<t>It is anticipated that <xref target="RFC7991"/> will be updated. serve the semantics expressed in the original RFC to the greatest extent possibl
Updates to the RFCXML specification that are applied to existing RFCs should pre e.
serve to the greatest extent possible the semantics expressed in the original RF
C.
The goal of limiting changes only to syntax is to preserve the semantic meaning encoded in the published document.</t> 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, limi t), we suggest the following.
<t>This policy does not require that updates to RFCXML avoid all risk of introdu Original:
cing semantic changes to existing RFCs. Instead, it only
Instead, it only requires that such updates consider the potential for semantic requires that such updates consider the potential for semantic
changes, take steps to understand the risk of a semantic change (either delibera changes, take steps to understand the risk of a semantic change
te or inadvertent), and to limit those risks.</t> (either deliberate or inadvertent), and to limit those risks.
</section>
</section>
<section anchor="pub-versions"><name>Publication Versions</name>
<t>The RPC is permitted but not required to re-issue 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 t
ake into account both the risk of semantic changes and consistency of the series
.</t>
<t>XML format errors and better design choices have been discovered by the commu Original:
nity since the first RFCs were published using the RFCXML format. 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 delibera
te or inadvertent), and limit those risks.</t>
</section>
</section>
<section anchor="pub-versions">
<name>Publication Versions</name>
<t>The RPC is permitted but not required to reissue publication versions o
f an RFC, as described in <xref target="changes-to-9280"/>.
In deciding whether to update the publication versions of an RFC, the RPC will t
ake into account both the risk of semantic changes and consistency of the 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 chang e, even if this might not result in observable differences. When the XML in a definitive version changes, the publication versions may chang e, even if this might not result in observable differences.
Similarly, as production tools change, publication versions may be regenerated t o ensure a consistent presentation.</t> Similarly, as production tools change, publication versions may be regenerated t o ensure a consistent presentation.</t>
</section>
</section> <section anchor="archived-documents">
<section anchor="archived-documents"><name>Archived Documents</name> <name>Archived Documents</name>
<t>The RPC will keep an archived set of all definitive versions of RFCs as
<t>The RPC will keep an archived set of all definitive versions of RFCs as well well as archived sets of the publication versions for an RFC that were previous
as archived sets of the publication versions for an RFC that were previously pub ly published.
lished.
These archived sets must be available using the same access methods as for curre nt definitive and publication versions. These archived sets must be available using the same access methods as for curre nt definitive and publication versions.
Every archived set shall record the date that a definitive and/or publication ve rsion was created or reissued.</t> Every archived set shall record the date that a definitive and/or publication ve rsion was created or reissued.</t>
<t>When the RPC archives definitive and publication versions, it does so i
<t>When the RPC archives definitive and publication versions, it does so in a ma n a manner that allows them to be found by people who want the historical (as co
nner that allows them to be found by people who want the historical (as compared mpared to current) files.</t>
to current) files.</t> <t>This document does not specify how archives are maintained or how archi
ved documents might be located or identified.
<t>This document does not specify how archives are maintained or how archived do
cuments might be located or identified.
The methods for storage and access will be determined by the RPC in consultation with the technical community.</t> The methods for storage and access will be determined by the RPC in consultation with the technical community.</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
</section> <!-- [rfced] Should "definitive versions" here be singular (i.e., "definitive
<section anchor="iana-considerations"><name>IANA Considerations</name> version")?
<t>This document has no IANA considerations.</t> Original:
Allowing changes to the definitive versions and publication versions
of RFCs introduces risks.
</section> Perhaps:
<section anchor="security-considerations"><name>Security Considerations</name> Allowing changes to the definitive version and publication versions
of RFCs introduces risks.
-->
<t>Allowing changes to the definitive versions and publication versions of RFCs <!-- [rfced] Would it be helpful to either add numbers or use two sentences
introduces risks. here to improve clarity?
A significant risk is that unintended changes could occur in either the definiti
ve 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 de
finitive 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 RFC series.</t>
<t>The RPC is expected to identify, track, and actively mitigate risks introduce Original:
d by this new policy.</t> 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.
</section> Perhaps (add numbers):
<section anchor="acknowledgments"><name>Acknowledgments</name> 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.
<t>Martin Thomson wrote a great deal of the significant text here as part of dra Or (split into two sentences):
ft-thomson-rswg-syntax-change.</t> 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.
-->
<t>This document has greatly benefited from the input of the RSWG. <!-- [rfced] To improve clarity, may we update the text starting with "and
In particular, harm" as follows?
Alexis Rossi,
Brian Carpenter,
Eliot Lear,
Jay Daley,
Jean Mahoney,
John Levine,
and Pete Resnick,
gave significant input on the early drafts of this document.</t>
</section> 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.
</middle> 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 definiti
ve 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 de
finitive 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 RFC Series.</t>
<t>The RPC is expected to identify, track, and actively mitigate risks int
roduced by this new policy.</t>
</section>
</middle>
<back> <back>
<displayreference target="RFC0020" to="RFC20"/>
<references title='References' anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name>
<references title='Normative References' anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name>
<reference anchor="RFC7991"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 991.xml"/>
<title>The "xml2rfc" Version 3 Vocabulary</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> 996.xml"/>
<date month="December" year="2016"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<abstract> 997.xml"/>
<t>This document defines the "xml2rfc" version 3 vocabulary: an XML-based <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
language used for writing RFCs and Internet-Drafts. It is heavily derived from t 280.xml"/>
he version 2 vocabulary that is also under discussion. This document obsoletes t </references>
he v2 grammar described in RFC 7749.</t> <references anchor="sec-informative-references">
</abstract> <name>Informative References</name>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
<seriesInfo name="RFC" value="7991"/> 020.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC7991"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</reference> 949.xml"/>
<reference anchor="RFC7996"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 990.xml"/>
<title>SVG Drawings for RFCs: SVG 1.2 RFC</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="N. Brownlee" initials="N." surname="Brownlee"/> 651.xml"/>
<date month="December" year="2016"/> </references>
<abstract>
<t>This document specifies SVG 1.2 RFC -- an SVG profile for use in diagra
ms that may appear in RFCs -- and considers some of the issues concerning the cr
eation 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 di
verse Internet community, the RFC Series must evolve to allow for the use of non
-ASCII characters in RFCs. While English remains the required language of the Se
ries, the encoding of future RFCs will be in UTF-8, allowing for a broader range
of characters than typically used in the English language. This document descri
bes the RFC Editor requirements and gives guidance regarding the use of non-ASCI
I characters in RFCs.</t>
<t>This document updates RFC 7322. Please view this document in PDF form t
o 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 de
fines two high-level tasks related to the RFC Series. First, policy definition i
s the joint responsibility of the RFC Series Working Group (RSWG), which produce
s policy proposals, and the RFC Series Approval Board (RSAB), which approves suc
h proposals. Second, policy implementation is primarily the responsibility of th
e RFC Production Center (RPC) as contractually overseen by the IETF Administrati
on Limited Liability Company (IETF LLC). In addition, various responsibilities o
f 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 doc
ument establishes the Editorial Stream for publication of future policy definiti
on documents produced through the processes defined herein.</t>
<t>This document obsoletes RFC 8728. This document updates RFCs 7841, 8729
, and 8730.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9280"/>
<seriesInfo name="DOI" value="10.17487/RFC9280"/>
</reference>
</references> </references>
<references title='Informative References' anchor="sec-informative-reference <section anchor="acknowledgments" numbered="false">
s"> <name>Acknowledgments</name>
<t><contact fullname="Martin Thomson"/> wrote a great deal of the signific
ant text here as part of draft-thomson-rswg-syntax-change-01.</t>
<t>This document has greatly benefited from the input of the RSWG.
In particular,
<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 early draft versions of this document.</t>
</section>
<reference anchor="RFC20"> <!-- [rfced] Would you like to use a consistent ordering when referring to the
<front> publication formats? We see the following (also note "text" and "plain
<title>ASCII format for network interchange</title> text"):
<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 and Future 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 requirements and requests for enhan
cements for the format of the canonical version of RFCs. Terms are defined to he
lp clarify exactly which stages of document production are under discussion for
format changes. The requirements described in this document 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 arch
ivability, the canonical format of the RFC Series will be transitioning from pla
in-text ASCII to XML using the xml2rfc version 3 vocabulary; different publicati
on formats will be rendered from that base document. With these changes comes an
increase in complexity for authors, consumers, and the publisher of RFCs. This
document serves as the 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 Exten
sion</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 Protoco
l (DLEP) that enables a modem to use DLEP messages to pause and resume data traf
fic coming from its peer router.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8651"/>
<seriesInfo name="DOI" value="10.17487/RFC8651"/>
</reference>
</references> HTML, text, and PDF
</references> PDF, plain text, or HTML
</back> HTML, PDF, and plain text
-->
<!-- ##markdown-source: <!-- [rfced] Please review the "Inclusive Language" portion of the online
H4sIAAAAAAAAA71aa4/byLH9zl/RkIGbMSDp2pPEXo+BRSZjO55kvevr8W7y Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
7aJFtqTOUGymmxxZMfzf76mq7ib1sp0vF1hjOVQ/qutx6lQ1Z7NZ0dmuNlfq and let us know if any changes are needed. Updates of this nature typically
w5sb9cb5je6C0k2lfjM+WNeEQi8W3jx8ZUDlykZvsETl9bKb+bBdzfyyfP7i result in more precise language, which is helpful for readers.
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=
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</back>
</rfc> </rfc>
 End of changes. 77 change blocks. 
451 lines changed or deleted 410 lines changed or added

This html diff was produced by rfcdiff 1.48.