rfc9413.original.xml		rfc9413.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<!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;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.22 (Ruby 3.1.		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	3) -->		-iab-protocol-maintenance-12" number="9413" submissionType="IAB" category="info"
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" ob
	-iab-protocol-maintenance-12" category="info" consensus="true" submissionType="I		soletes="" xml:lang="en" version="3">
	AB" tocInclude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.16.0 -->		<!-- xml2rfc v2v3 conversion 3.16.0 -->
	<front>		<front>
	<title>Maintaining Robust Protocols</title>		<title>Maintaining Robust Protocols</title>
	<seriesInfo name="Internet-Draft" value="draft-iab-protocol-maintenance-12"/ >		<seriesInfo name="RFC" value="9413"/>
	<author initials="M." surname="Thomson" fullname="Martin Thomson">		<author initials="M." surname="Thomson" fullname="Martin Thomson">
	<organization/>		<organization/>
	<address>		<address>
	<email>mt@lowentropy.net</email>		<email>mt@lowentropy.net</email>
	</address>		</address>
	</author>		</author>
	<author initials="D." surname="Schinazi" fullname="David Schinazi">		<author initials="D." surname="Schinazi" fullname="David Schinazi">
	<organization/>		<organization/>
	<address>		<address>
	<email>dschinazi.ietf@gmail.com</email>		<email>dschinazi.ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2023" month="February" day="02"/>		<date year="2023" month="June"/>
	<workgroup>EDM</workgroup>		<keyword>robustness</keyword>
			<keyword>postel</keyword>
			<keyword>principle</keyword>
			<keyword>law</keyword>
			<keyword>wrong</keyword>
			<keyword>tolerance</keyword>
	<abstract>		<abstract>
	<t>The main goal of the networking standards process is to enable the long term		<t>The main goal of the networking standards process is to enable the long -term
	interoperability of protocols. This document describes active protocol		interoperability of protocols. This document describes active protocol
	maintenance, a means to accomplish that goal. By evolving specifications and		maintenance, a means to accomplish that goal. By evolving specifications and
	implementations, it is possible to reduce ambiguity over time and create a		implementations, it is possible to reduce ambiguity over time and create a
	healthy ecosystem.</t>		healthy ecosystem.</t>
	<t>The robustness principle, often phrased as "be conservative in what you send,		<t>The robustness principle, often phrased as "be conservative in what you send,
	and liberal in what you accept", has long guided the design and implementation		and liberal in what you accept", has long guided the design and implementation
	of Internet protocols. However, it has been interpreted in a variety of ways.		of Internet protocols. However, it has been interpreted in a variety of ways.
	While some interpretations help ensure the health of the Internet, others can		While some interpretations help ensure the health of the Internet, others can
	negatively affect interoperability over time. When a protocol is actively		negatively affect interoperability over time. When a protocol is actively
	maintained, protocol designers and implementers can avoid these pitfalls.</t>		maintained, protocol designers and implementers can avoid these pitfalls.</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	The latest revision of this draft can be found at <eref target="https://
	intarchboard.github.io/draft-protocol-maintenance/draft-iab-protocol-maintenance
	.html"/>.
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	EDM IAB Program mailing list (<eref target="mailto:edm@iab.org"/>),
	which is archived at <eref target="https://www.iab.org/mailman/listinfo/
	edm"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/edm/"/>
	.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/intarchboard/draft-protocol-maintenance
	"/>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>There is good evidence to suggest that many important protocols are rou tinely		<t>There is good evidence to suggest that many important protocols are rou tinely
	maintained beyond their inception. In particular, a sizeable proportion of IETF		maintained beyond their inception. In particular, a sizable proportion of IETF
	activity is dedicated to the stewardship of existing protocols. This document		activity is dedicated to the stewardship of existing protocols. This document
	first discusses hazards in applying the robustness principle too broadly (see		first discusses hazards in applying the robustness principle too broadly (see
	<xref target="robustness"/>), and offers an alternative strategy for handling in teroperability		<xref target="robustness"/>) and offers an alternative strategy for handling int eroperability
	problems in deployments (see <xref target="active"/>).</t>		problems in deployments (see <xref target="active"/>).</t>
	<t>Ideally, protocol implementations can be actively maintained so that un expected		<t>Ideally, protocol implementations can be actively maintained so that un expected
	conditions are proactively identified and resolved. Some deployments might still		conditions are proactively identified and resolved. Some deployments might still
	need to apply short-term mitigations for deployments that cannot be easily		need to apply short-term mitigations for deployments that cannot be easily
	updated, but such cases need not be permanent. This is discussed further in		updated, but such cases need not be permanent. This is discussed further in
	<xref target="active"/>.</t>		<xref target="active"/>.</t>
	</section>		</section>
	<section anchor="robustness">		<section anchor="robustness">
	<name>Protocol Robustness</name>		<name>Protocol Robustness</name>
	<t>The robustness principle has been hugely influential in shaping the des ign of		<t>The robustness principle has been hugely influential in shaping the des ign of
	the Internet. As stated in the IAB document on Architectural Principles of the		the Internet. As stated in the IAB document "Architectural Principles of the
	Internet <xref target="RFC1958"/>, the robustness principle advises to:</t>		Internet" <xref target="RFC1958"/>, the robustness principle advises to:</t>
	<blockquote>		<blockquote>Be strict when sending and tolerant when receiving. Implementations
	<t>Be strict when sending and tolerant when receiving. Implementations		must
	must
	follow specifications precisely when sending to the network, and tolerate		follow specifications precisely when sending to the network, and tolerate
	faulty input from the network. When in doubt, discard faulty input silently,		faulty input from the network. When in doubt, discard faulty input silently,
	without returning an error message unless this is required by the		without returning an error message unless this is required by the
	specification.</t>		specification.
	</blockquote>		</blockquote>
	<t>This simple statement captures a significant concept in the design of		<t>This simple statement captures a significant concept in the design of
	interoperable systems. Many consider the application of the robustness		interoperable systems. Many consider the application of the robustness
	principle to be instrumental in the success of the Internet as well as the		principle to be instrumental in the success of the Internet as well as the
	design of interoperable protocols in general.</t>		design of interoperable protocols in general.</t>
	<t>There are three main aspects to the robustness principle:</t>		<t>There are three main aspects to the robustness principle:</t>
	<dl>		<dl>
	<dt>Robustness to software defects:</dt>		<dt>Robustness to software defects:</dt>
	<dd>		<dd>
	<t>No software is perfect, and failures can lead to unexpected behavio r.		<t>No software is perfect, and failures can lead to unexpected behavio r.
	Well-designed software strives to be resilient to such issues, whether they		Well-designed software strives to be resilient to such issues, whether they
	occur in the local software, or in software that it communicates with. In		occur in the local software or in software that it communicates with. In
	particular, it is critical for software to gracefully recover from these issues		particular, it is critical for software to gracefully recover from these issues
	without aborting unrelated processing.</t>		without aborting unrelated processing.</t>
	</dd>		</dd>
	<dt>Robustness to attacks:</dt>		<dt>Robustness to attacks:</dt>
	<dd>		<dd>
	<t>Since not all actors on the Internet are benevolent, networking sof tware needs		<t>Since not all actors on the Internet are benevolent, networking sof tware needs
	to be resilient to input that is intentionally crafted to cause unexpected		to be resilient to input that is intentionally crafted to cause unexpected
	consequences. For example, software must ensure that invalid input doesn't allow		consequences. For example, software must ensure that invalid input doesn't allow
	the sender to access data, change data, or perform actions that it would otherwi se not be allowed to.</t>		the sender to access data, change data, or perform actions that it would otherwi se not be allowed to.</t>
	</dd>		</dd>
	<dt>Robustness to the unexpected:</dt>		<dt>Robustness to the unexpected:</dt>
	<dd>		<dd>
	<t>It can be possible for an implementation to receive inputs that the		<t>It can be possible for an implementation to receive inputs that the
	specification did not prepare it for. This scenario excludes those cases where a		specification did not prepare it for. This scenario excludes those cases where a
	the specification explicitly defines how a faulty message is handled. Instead,		the specification explicitly defines how a faulty message is handled. Instead,
	this refers to cases where handling is not defined or where there is some		this refers to cases where handling is not defined or where there is some
	ambiguity in the specification. In this case, some interpretations of the		ambiguity in the specification. In this case, some interpretations of the
	robustness principle advocate that the implementation tolerate the faulty input		robustness principle advocate that the implementation tolerate the faulty input
	and silently discard it. Some interpretations even suggest that a faulty or		and silently discard it.
			Some interpretations even suggest that a faulty or
	ambiguous message be processed according to the inferred intent of the sender.</ t>		ambiguous message be processed according to the inferred intent of the sender.</ t>
	</dd>		</dd>
	</dl>		</dl>
	<t>The facets of the robustness principle that protect against defects or attack		<t>The facets of the robustness principle that protect against defects or attacks
	are understood to be necessary guiding principles for the design and		are understood to be necessary guiding principles for the design and
	implementation of networked systems. However, an interpretation that advocates		implementation of networked systems. However, an interpretation that advocates
	for tolerating unexpected inputs is no longer considered best practice in all		for tolerating unexpected inputs is no longer considered best practice in all
	scenarios.</t>		scenarios.</t>
	<t>Time and experience shows that negative consequences to interoperabilit y		<t>Time and experience show that negative consequences to interoperability
	accumulate over time if implementations silently accept faulty input. This		accumulate over time if implementations silently accept faulty input. This
	problem originates from an implicit assumption that it is not possible to effect		problem originates from an implicit assumption that it is not possible to effect
	change in a system the size of the Internet. When one assumes that changes to		change in a system the size of the Internet. When one assumes that changes to
	existing implementations are not presently feasible, tolerating flaws feels		existing implementations are not presently feasible, tolerating flaws feels
	inevitable.</t>		inevitable.</t>
	<t>Many problems that this third aspect of the robustness principle was in tended to		<t>Many problems that this third aspect of the robustness principle was in tended to
	solve can instead be better addressed by active maintenance. Active protocol		solve can instead be better addressed by active maintenance. Active protocol
	maintenance is where a community of protocol designers, implementers, and		maintenance is where a community of protocol designers, implementers, and
	deployers work together to continuously improve and evolve protocol		deployers work together to continuously improve and evolve protocol
	specifications alongside implementations and deployments of those protocols. A		specifications alongside implementations and deployments of those protocols. A
	community that takes an active role in the maintenance of protocols will no		community that takes an active role in the maintenance of protocols will no
	longer need to rely on the robustness principle to avoid interoperability issues .</t>		longer need to rely on the robustness principle to avoid interoperability issues .</t>
	<section anchor="fallibility-of-specifications">		<section anchor="fallibility-of-specifications">
	<name>Fallibility of Specifications</name>		<name>Fallibility of Specifications</name>
	<t>The context from which the robustness principle was developed provide s valuable		<t>The context from which the robustness principle was developed provide s valuable
	insights into its intent and purpose. The earliest form of the principle in the		insights into its intent and purpose. The earliest form of the principle in the
	RFC series (the Internet Protocol specification <xref target="RFC0760"/>) is pre ceded by a		RFC Series (the Internet Protocol specification <xref target="RFC0760"/>) is pre ceded by a
	sentence that reveals a motivation for the principle:</t>		sentence that reveals a motivation for the principle:</t>
	<blockquote>		<blockquote>While the goal of this specification is to be explicit about the pro
	<t>While the goal of this specification is to be explicit about the pr		tocol
	otocol
	there is the possibility of differing interpretations. In general, an		there is the possibility of differing interpretations. In general, an
	implementation should be conservative in its sending behavior, and liberal in		implementation should be conservative in its sending behavior, and liberal in
	its receiving behavior.</t>		its receiving behavior.</blockquote>
	</blockquote>
	<t>This formulation of the principle expressly recognizes the possibilit y that the		<t>This formulation of the principle expressly recognizes the possibilit y that the
	specification could be imperfect. This contextualizes the principle in an		specification could be imperfect. This contextualizes the principle in an
	important way.</t>		important way.</t>
	<t>Imperfect specifications are unavoidable, largely because it is more important		<t>Imperfect specifications are unavoidable, largely because it is more important
	to proceed to implementation and deployment than it is to perfect a		to proceed to implementation and deployment than it is to perfect a
	specification. A protocol benefits greatly from experience with its use. A		specification. A protocol benefits greatly from experience with its use. A
	deployed protocol is immeasurably more useful than a perfect protocol		deployed protocol is immeasurably more useful than a perfect protocol
	specification. This is particularly true in early phases of system design, to		specification. This is particularly true in early phases of system design, to
	which the robustness principle is best suited.</t>		which the robustness principle is best suited.</t>
	<t>As demonstrated by the IAB document on Successful Protocols <xref tar		<t>As demonstrated by the IAB document "What Makes for a Successful
	get="RFC5218"/>,		Protocol?"&nbsp;<xref target="RFC5218"/>, success or failure of a protoc
	success or failure of a protocol depends far more on factors like usefulness		ol
	than on technical excellence. Timely publication of protocol specifications,		depends far more on factors like usefulness than on technical
	even with the potential for flaws, likely contributed significantly to the		excellence. Timely publication of protocol specifications, even with
	eventual success of the Internet.</t>		the potential for flaws, likely contributed significantly to the
			eventual success of the Internet.</t>
	<t>This premise that specifications will be imperfect is correct. Howeve r, ignoring		<t>This premise that specifications will be imperfect is correct. Howeve r, ignoring
	faulty or ambiguous input is almost always the incorrect solution to the problem .</t>		faulty or ambiguous input is almost always the incorrect solution to the problem .</t>
	</section>		</section>
	<section anchor="extensibility">		<section anchor="extensibility">
	<name>Extensibility</name>		<name>Extensibility</name>
	<t>Good extensibility <xref target="EXT"/> can make it easier to respond to new use		<t>Good extensibility <xref target="RFC6709"/> can make it easier to res pond to new use
	cases or changes in the environment in which the protocol is deployed.</t>		cases or changes in the environment in which the protocol is deployed.</t>
	<t>The ability to extend a protocol is sometimes mistaken for an applica tion of the		<t>The ability to extend a protocol is sometimes mistaken for an applica tion of the
	robustness principle. After all, if one party wants to start using a new feature		robustness principle. After all, if one party wants to start using a new feature
	before another party is prepared to receive it, it might be assumed that the		before another party is prepared to receive it, it might be assumed that the
	receiving party is being tolerant of new types of input.</t>		receiving party is being tolerant of new types of input.</t>
	<t>A well-designed extensibility mechanism establishes clear rules for t he handling		<t>A well-designed extensibility mechanism establishes clear rules for t he handling
	of elements like new messages or parameters. This depends on specifying the		of elements like new messages or parameters. This depends on specifying the
	handling of malformed or illegal inputs so that implementations behave		handling of malformed or illegal inputs so that implementations behave
	consistently in all cases that might affect interoperation. New messages or		consistently in all cases that might affect interoperation. New messages or
	parameters thereby become entirely expected. If extension mechanisms and error		parameters thereby become entirely expected. If extension mechanisms and error
	handling are designed and implemented correctly, new protocol features can be		handling are designed and implemented correctly, new protocol features can be
	deployed with confidence in the understanding of the effect they have on		deployed with confidence in the understanding of the effect they have on
	existing implementations.</t>		existing implementations.</t>
	<t>In contrast, relying on implementations to consistently handle unexpe cted input		<t>In contrast, relying on implementations to consistently handle unexpe cted input
	is not a good strategy for extensibility. Using undocumented or		is not a good strategy for extensibility. Using undocumented or
	accidental features of a protocol as the basis of an extensibility mechanism can		accidental features of a protocol as the basis of an extensibility mechanism can
	be extremely difficult, as is demonstrated by the case study in <xref section="A		be extremely difficult, as is demonstrated by the case study in <xref section="A
	.3" sectionFormat="of" target="EXT"/>. It is better and easier to design a prot		.3" sectionFormat="of" target="RFC6709"/>. It is better and easier to design a
	ocol for extensibility		protocol for extensibility
	initially than to retrofit the capability (see also <xref target="EDNS0"/>).</t>		initially than to retrofit the capability (see also <xref target="RFC6891"/>).</
			t>
	</section>		</section>
	<section anchor="flexibility">		<section anchor="flexibility">
	<name>Flexible Protocols</name>		<name>Flexible Protocols</name>
	<t>A protocol could be designed to permit a narrow set of valid inputs,		<t>A protocol could be designed to permit a narrow set of valid inputs,
	or it could		or it could be designed to treat a wide range of inputs as valid.</t>
	be designed to treat a wide range of inputs as valid.</t>		<t>A more flexible protocol is more complex to specify and implement; va
	<t>A more flexible protocol is more complex to specify and implement: va		riations, especially those that are not commonly used, can create potential
	riations -
	especially those that are not commonly used - can create potential
	interoperability hazards. In the absence of strong reasons to be flexible, a		interoperability hazards. In the absence of strong reasons to be flexible, a
	simpler protocol is more likely to successfully interoperate.</t>		simpler protocol is more likely to successfully interoperate.</t>
	<t>Where input is provided by users, allowing flexibility might serve to make the		<t>Where input is provided by users, allowing flexibility might serve to make the
	protocol more accessible, especially for non-expert users. HTML authoring		protocol more accessible, especially for non-expert users. HTML authoring
	<xref target="HTML"/> is an example of this sort of design.</t>		<xref target="HTML"/> is an example of this sort of design.</t>
	<t>In protocols where there are many participants that might generate me ssages		<t>In protocols where there are many participants that might generate me ssages
	based on data from other participants some flexibility might contribute to		based on data from other participants, some flexibility might contribute to
	resilience of the system. A routing protocol is a good example of where this		resilience of the system. A routing protocol is a good example of where this
	might be necessary.</t>		might be necessary.</t>
	<t>In BGP <xref target="BGP"/>, a peer generates UPDATE messages based o		<t>In BGP <xref target="RFC4271"/>, a peer generates UPDATE messages
	n messages it		based on messages it receives from other peers. Peers can copy
	receives from other peers. Peers can copy attributes without validation,		attributes without validation, potentially propagating invalid
	potentially propagating invalid values. RFC 4271 <xref target="BGP"/> mandated a		values. RFC 4271 <xref target="RFC4271"/> mandated a session reset for
	session		invalid UPDATE messages, a requirement that was not widely
	reset for invalid UPDATE messages, a requirement that was not widely		implemented. In many deployments, peers would treat a malformed
	implemented. In many deployments, peers would treat a malformed UPDATE in less		UPDATE in less stringent ways, such as by treating the affected route
	stringent ways, such as by treating the affected route as having been withdrawn.		as having been withdrawn. Ultimately, RFC 7606 <xref
	Ultimately, RFC 7606 <xref target="BGP-REH"/> documented this practice and provi		target="RFC7606"/> documented this practice and provided precise
	ded		rules, including mandatory actions for different error conditions.</t>
	precise rules, including mandatory actions for different error conditions.</t>
	<t>A protocol can explicitly allow for a range of valid expressions of t he same		<t>A protocol can explicitly allow for a range of valid expressions of t he same
	semantics, with precise definitions for error handling. This is distinct from a		semantics, with precise definitions for error handling. This is distinct from a
	protocol that relies on the application of the robustness principle. With the		protocol that relies on the application of the robustness principle. With the
	former, interoperation depends on specifications that capture all relevant		former, interoperation depends on specifications that capture all relevant
	details; whereas - as noted in <xref target="ecosystem"/> - interoperation in th		details, whereas interoperation in the latter
	e latter		depends more extensively on implementations making compatible decisions, as note
	depends more extensively on implementations making compatible decisions.</t>		d in <xref target="ecosystem"/>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="applicability">		<section anchor="applicability">
	<name>Applicability</name>		<name>Applicability</name>
	<t>The guidance in this document is intended for protocols that are deploy ed to the		<t>The guidance in this document is intended for protocols that are deploy ed to the
	Internet. There are some situations in which this guidance might not apply to a		Internet. There are some situations in which this guidance might not apply to a
	protocol due to conditions on its implementation or deployment.</t>		protocol due to conditions on its implementation or deployment.</t>
	<t>In particular, this guidance depends on an ability to update and deploy		<t>In particular, this guidance depends on an ability to update and deploy
	implementations. Being able to rapidly update implementations that are deployed		implementations. Being able to rapidly update implementations that are deployed
	to the Internet helps managing security risk but in reality some software		to the Internet helps manage security risks, but in reality, some software
	deployments have lifecycles that make software updates either rare or altogether		deployments have lifecycles that make software updates either rare or altogether
	impossible.</t>		impossible.</t>
	<t>Where implementations are not updated, there is no opportunity to apply the		<t>Where implementations are not updated, there is no opportunity to apply the
	practices that this document recommends. In particular, some practices - such as		practices that this document recommends. In particular, some practices -- such a
	those described in <xref target="intolerance"/> - only exist to support the deve		s
	lopment of		those described in <xref target="intolerance"/> -- only exist to support the dev
			elopment of
	protocol maintenance and evolution. Employing this guidance is therefore only		protocol maintenance and evolution. Employing this guidance is therefore only
	applicable where there is the possibility of improving deployments through		applicable where there is the possibility of improving deployments through
	timely updates of their implementations.</t>		timely updates of their implementations.</t>
	</section>		</section>
	<section anchor="harmful-consequences-of-tolerating-the-unexpected">		<section anchor="harmful-consequences-of-tolerating-the-unexpected">
	<name>Harmful Consequences of Tolerating the Unexpected</name>		<name>Harmful Consequences of Tolerating the Unexpected</name>
	<t>Problems in other implementations can create an unavoidable need to tem porarily		<t>Problems in other implementations can create an unavoidable need to tem porarily
	tolerate unexpected inputs. However, this course of action carries risks.</t>		tolerate unexpected inputs. However, this course of action carries risks.</t>
	<section anchor="decay">		<section anchor="decay">
	<name>Protocol Decay</name>		<name>Protocol Decay</name>
	<t>Tolerating unexpected input might be an expedient tool for systems in early		<t>Tolerating unexpected input might be an expedient tool for systems in early
	phases of deployment, such as was the case for the early Internet. Being lenient		phases of deployment, which was the case for the early Internet. Being lenient
	in this way defers the effort of dealing with interoperability problems and		in this way defers the effort of dealing with interoperability problems and
	prioritizes progress. However, this deferral can amplify the ultimate cost of		prioritizes progress. However, this deferral can amplify the ultimate cost of
	handling interoperability problems.</t>		handling interoperability problems.</t>
	<t>Divergent implementations of a specification emerge over time. When v ariations		<t>Divergent implementations of a specification emerge over time. When v ariations
	occur in the interpretation or expression of semantic components,		occur in the interpretation or expression of semantic components,
	implementations cease to be perfectly interoperable.</t>		implementations cease to be perfectly interoperable.</t>
	<t>Implementation bugs are often identified as the cause of variation, t hough it is		<t>Implementation bugs are often identified as the cause of variation, t hough it is
	often a combination of factors. Using a protocol in ways that were not		often a combination of factors. Using a protocol in ways that were not
	anticipated in the original design, or ambiguities and errors in the		anticipated in the original design or ambiguities and errors in the
	specification are often contributing factors. Disagreements on the		specification are often contributing factors. Disagreements on the
	interpretation of specifications should be expected over the lifetime of a		interpretation of specifications should be expected over the lifetime of a
	protocol.</t>		protocol.</t>
	<t>Even with the best intentions to maintain protocol correctness, the p ressure to		<t>Even with the best intentions to maintain protocol correctness, the p ressure to
	interoperate can be significant. No implementation can hope to avoid having to		interoperate can be significant. No implementation can hope to avoid having to
	trade correctness for interoperability indefinitely.</t>		trade correctness for interoperability indefinitely.</t>
	<t>An implementation that reacts to variations in the manner recommended in the		<t>An implementation that reacts to variations in the manner recommended in the
	robustness principle enters a pathological feedback cycle. Over time:</t>		robustness principle enters a pathological feedback cycle. Over time:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Implementations progressively add logic to constrain how data is t		<li>Implementations progressively add logic to constrain how data is
	ransmitted,		transmitted or to permit variations in what is received.</li>
	or to permit variations in what is received.</li>
	<li>Errors in implementations or confusion about semantics are permitt ed or		<li>Errors in implementations or confusion about semantics are permitt ed or
	ignored.</li>		ignored.</li>
	<li>These errors can become entrenched, forcing other implementations to be		<li>These errors can become entrenched, forcing other implementations to be
	tolerant of those errors.</li>		tolerant of those errors.</li>
	</ul>		</ul>
	<t>A flaw can become entrenched as a de facto standard. Any implementati on of the		<t>A flaw can become entrenched as a de facto standard. Any implementati on of the
	protocol is required to replicate the aberrant behavior, or it is not		protocol is required to replicate the aberrant behavior, or it is not
	interoperable. This is both a consequence of tolerating the unexpected, and a		interoperable. This is both a consequence of tolerating the unexpected and a
	product of a natural reluctance to avoid fatal error conditions. Ensuring		product of a natural reluctance to avoid fatal error conditions. Ensuring
	interoperability in this environment is often referred to as aiming to be "bug		interoperability in this environment is often referred to as aiming to be "bug-f
	for bug compatible".</t>		or-bug compatible".</t>
	<t>For example, in TLS <xref target="TLS"/>, extensions use a tag-length		<t>For example, in TLS <xref target="RFC8446"/>, extensions use a tag-le
	-value format		ngth-value format
	and can be added to messages in any order. However, some server implementations		and can be added to messages in any order.
			However, some server implementations
	terminated connections if they encountered a TLS ClientHello message that ends		terminated connections if they encountered a TLS ClientHello message that ends
	with an empty extension. To maintain interoperability with these servers, which		with an empty extension. To maintain interoperability with these servers, which
	were widely deployed, client implementations were required to be aware of this		were widely deployed, client implementations were required to be aware of this
	bug and ensure that a ClientHello message ends in a non-empty extension.</t>		bug and ensure that a ClientHello message ends in a non-empty extension.</t>
	<t>Overapplication of the robustness principle therefore encourages a ch ain		<t>Overapplication of the robustness principle therefore encourages a ch ain
	reaction that can create interoperability problems over time. In particular,		reaction that can create interoperability problems over time. In particular,
	tolerating unexpected behavior is particularly deleterious for early		tolerating unexpected behavior is particularly deleterious for early
	implementations of new protocols as quirks in early implementations can affect		implementations of new protocols, as quirks in early implementations can affect
	all subsequent deployments.</t>		all subsequent deployments.</t>
	</section>		</section>
	<section anchor="ecosystem">		<section anchor="ecosystem">
	<name>Ecosystem Effects</name>		<name>Ecosystem Effects</name>
	<t>From observing widely deployed protocols, it appears there are two st able points		<t>From observing widely deployed protocols, it appears there are two st able points
	on the spectrum between being strict versus permissive in the presence of		on the spectrum between being strict versus permissive in the presence of
	protocol errors:</t>		protocol errors:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>If implementations predominantly enforce strict compliance with		<li>If implementations predominantly enforce strict compliance with
	specifications, newer implementations will experience failures if they do not		specifications, newer implementations will experience failures if they do not
	comply with protocol requirements. Newer implementations need to fix		comply with protocol requirements. Newer implementations need to fix
	compliance issues in order to be successfully deployed. This ensures that most		compliance issues in order to be successfully deployed. This ensures that most
	deployments are compliant over time.</li>		deployments are compliant over time.</li>
	<li>Conversely, if non-compliance is tolerated by existing implementat ions,		<li>Conversely, if non-compliance is tolerated by existing implementat ions,
	non-compliant implementations can be deployed successfully. Newer		non-compliant implementations can be deployed successfully. Newer
	implementations then have strong incentive to tolerate any existing		implementations then have a strong incentive to tolerate any existing
	non-compliance in order to be successfully deployed. This ensures that most		non-compliance in order to be successfully deployed. This ensures that most
	deployments are tolerant of the same non-compliant behavior.</li>		deployments are tolerant of the same non-compliant behavior.</li>
	</ul>		</ul>
	<t>This happens because interoperability requirements for protocol imple		<t>This happens because interoperability requirements for protocol
	mentations		implementations are set by other deployments. Specifications and test
	are set by other deployments. Specifications and test suites - where they exist		suites -- where they exist -- can guide the initial development of
	-		implementations. Ultimately, the need to interoperate with deployed
	can guide the initial development of implementations. Ultimately, the		implementations is a de facto conformance test suite that can
	need to interoperate with deployed implementations is a de facto conformance		supersede any formal protocol definition.</t>
	test suite that can supersede any formal protocol definition.</t>
	<t>For widely used protocols, the massive scale of the Internet makes la rge-scale		<t>For widely used protocols, the massive scale of the Internet makes la rge-scale
	interoperability testing infeasible for all but a privileged few. The cost of		interoperability testing infeasible for all but a privileged few. The cost of
	building a new implementation using reverse engineering increases as the number		building a new implementation using reverse engineering increases as the number
	of implementations and bugs increases. Worse, the set of tweaks necessary for		of implementations and bugs increases. Worse, the set of tweaks necessary for
	wide interoperability can be difficult to discover. In the worst case, a new		wide interoperability can be difficult to discover. In the worst case, a new
	implementer might have to choose between deployments that have diverged so far		implementer might have to choose between deployments that have diverged so far
	as to no longer be interoperable.</t>		as to no longer be interoperable.</t>
	<t>Consequently, new implementations might be forced into niche uses, wh ere the		<t>Consequently, new implementations might be forced into niche uses, wh ere the
	problems arising from interoperability issues can be more closely managed.		problems arising from interoperability issues can be more closely managed.
	However, restricting new implementations into limited deployments risks causing		However, restricting new implementations into limited deployments risks causing
	forks in the protocol. If implementations do not interoperate, little prevents		forks in the protocol. If implementations do not interoperate, little prevents
	those implementations from diverging more over time.</t>		those implementations from diverging more over time.</t>
	<t>This has a negative impact on the ecosystem of a protocol. New implem entations		<t>This has a negative impact on the ecosystem of a protocol. New implem entations
	are key to the continued viability of a protocol. New protocol implementations		are key to the continued viability of a protocol. New protocol implementations
	are also more likely to be developed for new and diverse use cases and are often		are also more likely to be developed for new and diverse use cases and are often
	the origin of features and capabilities that can be of benefit to existing users .</t>		the origin of features and capabilities that can be of benefit to existing users .</t>
	<t>The need to work around interoperability problems also reduces the ab ility of		<t>The need to work around interoperability problems also reduces the ab ility of
	established implementations to change. An accumulation of mitigations for		established implementations to change. An accumulation of mitigations for
	interoperability issues makes implementations more difficult to maintain and can		interoperability issues makes implementations more difficult to maintain and can
	constrain extensibility (see also the IAB document on the Long-Term Viability of		constrain extensibility (see also the IAB document "Long-Term Viability of
	Protocol Extension Mechanisms <xref target="RFC9170"/>).</t>		Protocol Extension Mechanisms" <xref target="RFC9170"/>).</t>
	<t>Sometimes what appear to be interoperability problems are symptomatic		<t>Sometimes, what appear to be interoperability problems are symptomati
	of issues		c of issues
	in protocol design. A community that is willing to make changes to the protocol,		in protocol design. A community that is willing to make changes to the protocol,
	by revising or extending specifications and then deploying those changes,		by revising or extending specifications and then deploying those changes,
	makes the protocol better.		makes the protocol better.
	Tolerating unexpected input instead conceals problems, making it harder, if not		Tolerating unexpected input instead conceals problems, making it harder, if not
	impossible, to fix them later.</t>		impossible, to fix them later.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="active">		<section anchor="active">
	<name>Active Protocol Maintenance</name>		<name>Active Protocol Maintenance</name>
	<t>The robustness principle can be highly effective in safeguarding agains t flaws		<t>The robustness principle can be highly effective in safeguarding agains t flaws
	in the implementation of a protocol by peers. Especially when a specification		in the implementation of a protocol by peers. Especially when a specification
	remains unchanged for an extended period of time, incentive to be tolerant of		remains unchanged for an extended period of time, the incentive to be tolerant o f
	errors accumulates over time. Indeed, when faced with divergent interpretations		errors accumulates over time. Indeed, when faced with divergent interpretations
	of an immutable specification, the only way for an implementation to remain		of an immutable specification, the only way for an implementation to remain
	interoperable is to be tolerant of differences in interpretation and		interoperable is to be tolerant of differences in interpretation and
	implementation errors. However, when official specifications fail to be		implementation errors. However, when official specifications fail to be
	updated then deployed implementations - including their quirks - often become		updated, then deployed implementations -- including their quirks -- often become
	a substitute standard.</t>		a substitute standard.</t>
	<t>Tolerating unexpected inputs from another implementation might seem log		<t>Tolerating unexpected inputs from another implementation might seem log
	ical,		ical, even necessary. However, that conclusion relies on an assumption that exis
	even necessary. But that conclusion relies on an assumption that existing		ting
	specifications and implementations cannot change. Applying the robustness		specifications and implementations cannot change. Applying the robustness
	principle in this way disproportionately values short-term gains over the		principle in this way disproportionately values short-term gains over the
	negative effects on future implementations and the protocol as a whole.</t>		negative effects on future implementations and the protocol as a whole.</t>
	<t>For a protocol to have sustained viability, it is necessary for both		<t>For a protocol to have sustained viability, it is necessary for both
	specifications and implementations to be responsive to changes, in addition to		specifications and implementations to be responsive to changes, in addition to
	handling new and old problems that might arise over time. For example, when an		handling new and old problems that might arise over time. For example, when an
	implementer discovers a scenario where a specification defines some input as		implementer discovers a scenario where a specification defines some input as
	faulty but does not define how to handle that input, the implementer can provide		faulty but does not define how to handle that input, the implementer can provide
	significant value to the ecosystem by reporting the issue and helping evolve the		significant value to the ecosystem by reporting the issue and helping to evolve the
	specification.</t>		specification.</t>
	<t>When a discrepancy is found between a specification and its implementat ion, a		<t>When a discrepancy is found between a specification and its implementat ion, a
	maintenance discussion inside the standards process allows reaching consensus on		maintenance discussion inside the standards process allows reaching consensus on
	how best to evolve the specification. Subsequently updating implementations to		how best to evolve the specification. Subsequently, updating implementations to
	match evolved specifications ensures that implementations are consistently		match evolved specifications ensures that implementations are consistently
	interoperable and removes needless barriers for new implementations. Maintenance		interoperable and removes needless barriers for new implementations. Maintenance
	also enables continued improvement of the protocol. New use cases are an		also enables continued improvement of the protocol. New use cases are an
	indicator that the protocol could be successful <xref target="RFC5218"/>.</t>		indicator that the protocol could be successful <xref target="RFC5218"/>.</t>
	<t>Protocol designers are strongly encouraged to continue to maintain and evolve		<t>Protocol designers are strongly encouraged to continue to maintain and evolve
	protocol specifications beyond their initial inception and definition. This		protocol specifications beyond their initial inception and definition. This
	might require the development of revised specifications, extensions, or other		might require the development of revised specifications, extensions, or other
	supporting material that evolves in concert with implementations. Involvement of		supporting material that evolves in concert with implementations. Involvement of
	those who implement and deploy the protocol is a critical part of this process,		those who implement and deploy the protocol is a critical part of this process,
	as they provide input on their experience with how the protocol is used.</t>		as they provide input on their experience with how the protocol is used.</t>
	<t>Most interoperability problems do not require revision of protocols or protocol		<t>Most interoperability problems do not require revision of protocols or protocol
	specifications, as software defects can happen even when the specification is		specifications, as software defects can happen even when the specification is
	unambiguous. For instance, the most effective means of dealing with a		unambiguous. For instance, the most effective means of dealing with a
	defective implementation in a peer could be to contact the developer		defective implementation in a peer could be to contact the developer
	responsible. It is far more efficient in the long term to fix one isolated bug		responsible. It is far more efficient in the long term to fix one isolated bug
	than it is to deal with the consequences of workarounds.</t>		than it is to deal with the consequences of workarounds.</t>
	<t>Early implementations of protocols have a stronger obligation to closel y follow		<t>Early implementations of protocols have a stronger obligation to closel y follow
	specifications as their behavior will affect all subsequent implementations. In		specifications, as their behavior will affect all subsequent implementations. In
	addition to specifications, later implementations will be guided by what		addition to specifications, later implementations will be guided by what
	existing deployments accept. Tolerance of errors in early deployments is most		existing deployments accept. Tolerance of errors in early deployments is most
	likely to result in problems. Protocol specifications might need more frequent		likely to result in problems. Protocol specifications might need more frequent
	revision during early deployments to capture feedback from early rounds of		revision during early deployments to capture feedback from early rounds of
	deployment.</t>		deployment.</t>
	<t>Neglect can quickly produce the negative consequences this document des cribes.		<t>Neglect can quickly produce the negative consequences this document des cribes.
	Restoring the protocol to a state where it can be maintained involves first		Restoring the protocol to a state where it can be maintained involves first
	discovering the properties of the protocol as it is deployed, rather than the		discovering the properties of the protocol as it is deployed rather than the
	protocol as it was originally documented. This can be difficult and		protocol as it was originally documented. This can be difficult and
	time-consuming, particularly if the protocol has a diverse set of		time-consuming, particularly if the protocol has a diverse set of
	implementations. Such a process was undertaken for HTTP <xref target="HTTP"/> af ter		implementations. Such a process was undertaken for HTTP <xref target="RFC9110"/> after
	a period of minimal maintenance. Restoring HTTP specifications to relevance took		a period of minimal maintenance. Restoring HTTP specifications to relevance took
	significant effort.</t>		significant effort.</t>
	<t>Maintenance is most effective if it is responsive, which is greatly aff ected by		<t>Maintenance is most effective if it is responsive, which is greatly aff ected by
	how rapidly protocol changes can be deployed. For protocol deployments that		how rapidly protocol changes can be deployed. For protocol deployments that
	operate on longer time scales, temporary workarounds following the spirit of the		operate on longer time scales, temporary workarounds following the spirit of the
	robustness principle might be necessary. For this, improvements in software		robustness principle might be necessary. For this, improvements in software
	update mechanisms ensure that the cost of reacting to changes is much lower than		update mechanisms ensure that the cost of reacting to changes is much lower than
	it was in the past. Alternatively, if specifications can be updated more readily		it was in the past. Alternatively, if specifications can be updated more readily
	than deployments, details of the workaround can be documented, including the		than deployments, details of the workaround can be documented, including the
	desired form of the protocols once the need for workarounds no longer exists and		desired form of the protocols once the need for workarounds no longer exists and
	skipping to change at line 416 ¶		skipping to change at line 405 ¶
	conditions. This increases the chances that implementations will have consistent		conditions. This increases the chances that implementations will have consistent
	and interoperable handling of unusual conditions.</t>		and interoperable handling of unusual conditions.</t>
	<t>Choosing to generate fatal errors for unspecified conditions instead of		<t>Choosing to generate fatal errors for unspecified conditions instead of
	attempting error recovery can ensure that faults receive attention. This		attempting error recovery can ensure that faults receive attention. This
	intolerance can be harnessed to reduce occurrences of aberrant implementations.< /t>		intolerance can be harnessed to reduce occurrences of aberrant implementations.< /t>
	<t>Intolerance toward violations of specification improves feedback for new		<t>Intolerance toward violations of specification improves feedback for new
	implementations in particular. When a new implementation encounters a peer that		implementations in particular. When a new implementation encounters a peer that
	is intolerant of an error, it receives strong feedback that allows the problem		is intolerant of an error, it receives strong feedback that allows the problem
	to be discovered quickly.</t>		to be discovered quickly.</t>
	<t>To be effective, intolerant implementations need to be sufficiently w idely		<t>To be effective, intolerant implementations need to be sufficiently w idely
	deployed that they are encountered by new implementations with high probability.		deployed so that they are encountered by new implementations with high probabili ty.
	This could depend on multiple implementations deploying strict checks.</t>		This could depend on multiple implementations deploying strict checks.</t>
	<t>Interoperability problems also need to be made known to those in a po sition to		<t>Interoperability problems also need to be made known to those in a po sition to
	address them. In particular, systems with human operators, such as user-facing		address them. In particular, systems with human operators, such as user-facing
	clients, are ideally suited to surfacing errors. Other systems might need to		clients, are ideally suited to surfacing errors. Other systems might need to
	use less direct means of making errors known.</t>		use less direct means of making errors known.</t>
	<t>This does not mean that intolerance of errors in early deployments of protocols		<t>This does not mean that intolerance of errors in early deployments of protocols
	has the effect of preventing interoperability. On the contrary, when existing		has the effect of preventing interoperability. On the contrary, when existing
	implementations follow clearly-specified error handling, new implementations or		implementations follow clearly specified error handling, new implementations or
	features can be introduced more readily as the effect on existing		features can be introduced more readily, as the effect on existing
	implementations can be easily predicted; see also <xref target="extensibility"/> .</t>		implementations can be easily predicted; see also <xref target="extensibility"/> .</t>
	<t>Any intolerance also needs to be strongly supported by specifications , otherwise		<t>Any intolerance also needs to be strongly supported by specifications ; otherwise,
	they encourage fracturing of the protocol community or proliferation of		they encourage fracturing of the protocol community or proliferation of
	workarounds; see <xref target="exclusion"/>.</t>		workarounds. See <xref target="exclusion"/>.</t>
	<t>Intolerance can be used to motivate compliance with any protocol requ irement.		<t>Intolerance can be used to motivate compliance with any protocol requ irement.
	For instance, the INADEQUATE_SECURITY error code and associated requirements in		For instance, the INADEQUATE_SECURITY error code and associated requirements in
	HTTP/2 <xref target="H2"/> resulted in improvements in the security of the		HTTP/2 <xref target="RFC9113"/> resulted in improvements in the security of the
	deployed base.</t>		deployed base.</t>
	<t>A notification for a fatal error is best sent as explicit error messa ges to the		<t>A notification for a fatal error is best sent as explicit error messa ges to the
	entity that made the error. Error messages benefit from being able to carry		entity that made the error. Error messages benefit from being able to carry
	arbitrary information that might help the implementer of the sender of the		arbitrary information that might help the implementer of the sender of the
	faulty input understand and fix the issue in their software. QUIC error frames		faulty input understand and fix the issue in their software. QUIC error frames
	<xref target="QUIC"/> are an example of a fatal error mechanism that helped		<xref target="RFC9000"/> are an example of a fatal error mechanism that helped
	implementers improve software quality throughout the protocol lifecycle.		implementers improve software quality throughout the protocol lifecycle.
	Similarly, Extended DNS Errors <xref target="EDE"/> has recently been		Similarly, the use of Extended DNS Errors <xref target="RFC8914"/> has been
	effective in providing better descriptions of DNS resolution errors to clients.< /t>		effective in providing better descriptions of DNS resolution errors to clients.< /t>
	<t>Stateless protocol endpoints might generate denial-of-service attacks		<t>Stateless protocol endpoints might generate denial-of-service attacks if they
	if they		send an error message in response to every message that is received from an
	send an error messages in response to every message that is received from an
	unauthenticated sender. These implementations might need to silently discard		unauthenticated sender. These implementations might need to silently discard
	these messages.</t>		these messages.</t>
	</section>		</section>
	<section anchor="exclusion">		<section anchor="exclusion">
	<name>Exclusion</name>		<name>Exclusion</name>
	<t>Any protocol participant that is affected by changes arising from mai ntenance		<t>Any protocol participant that is affected by changes arising from mai ntenance
	might be excluded if they are unwilling or unable to implement or deploy changes		might be excluded if they are unwilling or unable to implement or deploy changes
	that are made to the protocol.</t>		that are made to the protocol.</t>
	<t>Deliberate exclusion of problematic implementations is an important t ool that		<t>Deliberate exclusion of problematic implementations is an important t ool that
	can ensure that the interoperability of a protocol remains viable. While		can ensure that the interoperability of a protocol remains viable. While
	backward compatible changes are always preferable to incompatible ones, it is		backward-compatible changes are always preferable to incompatible ones, it is
	not always possible to produce a design that protects the ability of all current		not always possible to produce a design that protects the ability of all current
	and future protocol participants to interoperate.</t>		and future protocol participants to interoperate.</t>
	<t>Accidentally excluding unexpected participants is not usually a good outcome.		<t>Accidentally excluding unexpected participants is not usually a good outcome.
	When developing and deploying changes, it is best to first understand the extent		When developing and deploying changes, it is best to first understand the extent
	to which the change affects existing deployments. This ensures that any		to which the change affects existing deployments. This ensures that any
	exclusion that occurs is intentional.</t>		exclusion that occurs is intentional.</t>
	<t>In some cases, existing deployments might need to change in order to avoid being		<t>In some cases, existing deployments might need to change in order to avoid being
	excluded. Though it might be preferable to avoid forcing deployments to change,		excluded. Though it might be preferable to avoid forcing deployments to change,
	this might be considered necessary. To avoid unnecessarily excluding		this might be considered necessary. To avoid unnecessarily excluding
	deployments that might take time to change, developing a migration plan can be		deployments that might take time to change, developing a migration plan can be
	prudent.</t>		prudent.</t>
	<t>Exclusion is a direct goal when choosing to be intolerant of errors ( see		<t>Exclusion is a direct goal when choosing to be intolerant of errors ( see
	<xref target="intolerance"/>). Exclusionary actions are employed with the delibe rate intent		<xref target="intolerance"/>). Exclusionary actions are employed with the delibe rate intent
	of protecting future interoperability.</t>		of protecting future interoperability.</t>
	<t>Excluding implementations or deployments can lead to a fracturing of the		<t>Excluding implementations or deployments can lead to a fracturing of the
	protocol system that could be more harmful than any divergence that might arise		protocol system that could be more harmful than any divergence that might arise
	from tolerating the unexpected. The IAB document on Uncoordinated Protocol		from tolerating the unexpected. The IAB document "Uncoordinated Protocol
	Development Considered Harmful <xref target="RFC5704"/> describes how conflict o		Development Considered Harmful" <xref target="RFC5704"/> describes how conflict
	r		or
	competition in the maintenance of protocols can lead to similar problems.</t>		competition in the maintenance of protocols can lead to similar problems.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="security-considerations">		<section anchor="security-considerations">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>Careless implementations, lax interpretations of specifications, and		<t>Careless implementations, lax interpretations of specifications, and
	uncoordinated extrapolation of requirements to cover gaps in specification can		uncoordinated extrapolation of requirements to cover gaps in
	result in security problems. Hiding the consequences of protocol variations		specification can result in security problems. Hiding the consequences
	encourages the hiding of issues, which can conceal bugs and make them difficult		of protocol variations encourages the hiding of issues, which can
	to discover.</t>		conceal bugs and make them difficult to discover.</t>
	<t>The consequences of the problems described in this document are especia		<t>The consequences of the problems described in this document are
	lly acute		especially acute for any protocol where security depends on agreement
	for any protocol where security depends on agreement about semantics of protocol		about semantics of protocol elements. For instance, weak primitives
	elements. For instance, use of unsafe security mechanisms, such as weak		<xref target="RFC6151"/> and obsolete mechanisms <xref
	primitives <xref target="MD5"/> or obsolete mechanisms <xref target="SSL3"/>, ar		target="RFC7568"/> are good examples of the use of unsafe security
	e good		practices where forcing exclusion (<xref target="exclusion"/>) can be
	examples of where forcing exclusion (<xref target="exclusion"/>) can be desirabl		desirable.</t>
	e.</t>
	</section>		</section>
	<section anchor="iana-considerations">		<section anchor="iana-considerations">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document has no IANA actions.</t>		<t>This document has no IANA actions.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<displayreference target="H2" to="HTTP/2"/>		<displayreference target="RFC9113" to="HTTP/2"/>
			<displayreference target="RFC6709" to="EXT"/>
			<displayreference target="RFC6891" to="EDNS0"/>
			<displayreference target="RFC4271" to="BGP"/>
			<displayreference target="RFC7606" to="BGP-REH"/>
			<displayreference target="RFC8446" to="TLS"/>
			<displayreference target="RFC9110" to="HTTP"/>
			<displayreference target="RFC9000" to="QUIC"/>
			<displayreference target="RFC8914" to="EDE"/>
			<displayreference target="RFC6151" to="MD5"/>
			<displayreference target="RFC7568" to="SSL3"/>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="HTML" target="https://html.spec.whatwg.org/">		<reference anchor="HTML" target="https://html.spec.whatwg.org/">
	<front>		<front>
	<title>HTML</title>		<title>HTML - Living Standard</title>
	<author>
	<organization/>
	</author>
	<date year="2019" month="March" day="08"/>
	</front>
	<seriesInfo name="WHATWG" value="Living Standard"/>
	</reference>
	<reference anchor="H2">
	<front>
	<title>HTTP/2</title>
	<author fullname="M. Thomson" initials="M." role="editor" surname="Tho
	mson">
	<organization/>
	</author>
	<author fullname="C. Benfield" initials="C." role="editor" surname="Be
	nfield">
	<organization/>
	</author>
	<date month="June" year="2022"/>
	<abstract>
	<t>This specification describes an optimized expression of the seman
	tics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (H
	TTP/2). HTTP/2 enables a more efficient use of network resources and a reduced l
	atency by introducing field compression and allowing multiple concurrent exchang
	es on the same connection.</t>
	<t>This document obsoletes RFCs 7540 and 8740.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9113"/>
	<seriesInfo name="DOI" value="10.17487/RFC9113"/>
	</reference>
	<reference anchor="RFC1958">
	<front>
	<title>Architectural Principles of the Internet</title>
	<author fullname="B. Carpenter" initials="B." role="editor" surname="C
	arpenter">
	<organization/>
	</author>
	<date month="June" year="1996"/>
	<abstract>
	<t>The Internet and its architecture have grown in evolutionary fash
	ion from modest beginnings, rather than from a Grand Plan. While this process of
	evolution is one of the main reasons for the technology's success, it neverthel
	ess seems useful to record a snapshot of the current principles of the Internet
	architecture. This is intended for general guidance and general interest, and is
	in no way intended to be a formal or invariant reference model. This memo prov
	ides information for the Internet community. This memo does not specify an Inte
	rnet standard of any kind.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="1958"/>
	<seriesInfo name="DOI" value="10.17487/RFC1958"/>
	</reference>
	<reference anchor="RFC0760">
	<front>
	<title>DoD standard Internet Protocol</title>
	<author fullname="J. Postel" initials="J." surname="Postel">
	<organization/>
	</author>
	<date month="January" year="1980"/>
	</front>
	<seriesInfo name="RFC" value="760"/>
	<seriesInfo name="DOI" value="10.17487/RFC0760"/>
	</reference>
	<reference anchor="RFC5218">
	<front>
	<title>What Makes for a Successful Protocol?</title>
	<author fullname="D. Thaler" initials="D." surname="Thaler">
	<organization/>
	</author>
	<author fullname="B. Aboba" initials="B." surname="Aboba">
	<organization/>
	</author>
	<date month="July" year="2008"/>
	<abstract>
	<t>The Internet community has specified a large number of protocols
	to date, and these protocols have achieved varying degrees of success. Based on
	case studies, this document attempts to ascertain factors that contribute to or
	hinder a protocol's success. It is hoped that these observations can serve as g
	uidance for future protocol work. This memo provides information for the Inter
	net community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5218"/>
	<seriesInfo name="DOI" value="10.17487/RFC5218"/>
	</reference>
	<reference anchor="EXT">
	<front>
	<title>Design Considerations for Protocol Extensions</title>
	<author fullname="B. Carpenter" initials="B." surname="Carpenter">
	<organization/>
	</author>
	<author fullname="B. Aboba" initials="B." role="editor" surname="Aboba
	">
	<organization/>
	</author>
	<author fullname="S. Cheshire" initials="S." surname="Cheshire">
	<organization/>
	</author>
	<date month="September" year="2012"/>
	<abstract>
	<t>This document discusses architectural issues related to the exten
	sibility of Internet protocols, with a focus on design considerations. It is in
	tended to assist designers of both base protocols and extensions. Case studies
	are included. A companion document, RFC 4775 (BCP 125), discusses procedures re
	lating to the extensibility of IETF protocols. This document is not an Interne
	t Standards Track specification; it is published for informational purposes.</t
	>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6709"/>
	<seriesInfo name="DOI" value="10.17487/RFC6709"/>
	</reference>
	<reference anchor="EDNS0">
	<front>
	<title>Extension Mechanisms for DNS (EDNS0)</title>
	<author fullname="P. Vixie" initials="P." surname="Vixie">
	<organization/>
	</author>
	<date month="August" year="1999"/>
	<abstract>
	<t>The Domain Name System's wire protocol includes a number of fixed
	fields whose range has been or soon will be exhausted and does not allow client
	s to advertise their capabilities to servers. This document describes backward
	compatible mechanisms for allowing the protocol to grow. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="2671"/>
	<seriesInfo name="DOI" value="10.17487/RFC2671"/>
	</reference>
	<reference anchor="BGP">
	<front>
	<title>A Border Gateway Protocol 4 (BGP-4)</title>
	<author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rek
	hter">
	<organization/>
	</author>
	<author fullname="T. Li" initials="T." role="editor" surname="Li">
	<organization/>
	</author>
	<author fullname="S. Hares" initials="S." role="editor" surname="Hares
	">
	<organization/>
	</author>
	<date month="January" year="2006"/>
	<abstract>
	<t>This document discusses the Border Gateway Protocol (BGP), which
	is an inter-Autonomous System routing protocol.</t>
	<t>The primary function of a BGP speaking system is to exchange netw
	ork reachability information with other BGP systems. This network reachability
	information includes information on the list of Autonomous Systems (ASes) that r
	eachability information traverses. This information is sufficient for constructi
	ng a graph of AS connectivity for this reachability from which routing loops may
	be pruned, and, at the AS level, some policy decisions may be enforced.</t>
	<t>BGP-4 provides a set of mechanisms for supporting Classless Inter
	-Domain Routing (CIDR). These mechanisms include support for advertising a set
	of destinations as an IP prefix, and eliminating the concept of network "class"
	within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes,
	including aggregation of AS paths.</t>
	<t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4271"/>
	<seriesInfo name="DOI" value="10.17487/RFC4271"/>
	</reference>
	<reference anchor="BGP-REH">
	<front>
	<title>Revised Error Handling for BGP UPDATE Messages</title>
	<author fullname="E. Chen" initials="E." role="editor" surname="Chen">
	<organization/>
	</author>
	<author fullname="J. Scudder" initials="J." role="editor" surname="Scu
	dder">
	<organization/>
	</author>
	<author fullname="P. Mohapatra" initials="P." surname="Mohapatra">
	<organization/>
	</author>
	<author fullname="K. Patel" initials="K." surname="Patel">
	<organization/>
	</author>
	<date month="August" year="2015"/>
	<abstract>
	<t>According to the base BGP specification, a BGP speaker that recei
	ves an UPDATE message containing a malformed attribute is required to reset the
	session over which the offending attribute was received. This behavior is undesi
	rable because a session reset would impact not only routes with the offending at
	tribute but also other valid routes exchanged over the session. This document p
	artially revises the error handling for UPDATE messages and provides guidelines
	for the authors of documents defining new attributes. Finally, it revises the e
	rror handling procedures for a number of existing attributes.</t>
	<t>This document updates error handling for RFCs 1997, 4271, 4360, 4
	456, 4760, 5543, 5701, and 6368.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7606"/>
	<seriesInfo name="DOI" value="10.17487/RFC7606"/>
	</reference>
	<reference anchor="TLS">
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla">
	<organization/>
	</author>
	<date month="August" year="2018"/>
	<abstract>
	<t>This document specifies version 1.3 of the Transport Layer Securi
	ty (TLS) protocol. TLS allows client/server applications to communicate over th
	e Internet in a way that is designed to prevent eavesdropping, tampering, and me
	ssage forgery.</t>
	<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077
	, 5246, and 6961. This document also specifies new requirements for TLS 1.2 imp
	lementations.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8446"/>
	<seriesInfo name="DOI" value="10.17487/RFC8446"/>
	</reference>
	<reference anchor="RFC9170">
	<front>
	<title>Long-Term Viability of Protocol Extension Mechanisms</title>
	<author fullname="M. Thomson" initials="M." surname="Thomson">
	<organization/>
	</author>
	<author fullname="T. Pauly" initials="T." surname="Pauly">
	<organization/>
	</author>
	<date month="December" year="2021"/>
	<abstract>
	<t>The ability to change protocols depends on exercising the extensi
	on and version-negotiation mechanisms that support change. This document explor
	es how regular use of new protocol features can ensure that it remains possible
	to deploy changes to a protocol. Examples are given where lack of use caused cha
	nges to be more difficult or costly.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9170"/>
	<seriesInfo name="DOI" value="10.17487/RFC9170"/>
	</reference>
	<reference anchor="HTTP">
	<front>
	<title>HTTP Semantics</title>
	<author fullname="R. Fielding" initials="R." role="editor" surname="Fi
	elding">
	<organization/>
	</author>
	<author fullname="M. Nottingham" initials="M." role="editor" surname="
	Nottingham">
	<organization/>
	</author>
	<author fullname="J. Reschke" initials="J." role="editor" surname="Res
	chke">
	<organization/>
	</author>
	<date month="June" year="2022"/>
	<abstract>
	<t>The Hypertext Transfer Protocol (HTTP) is a stateless application
	-level protocol for distributed, collaborative, hypertext information systems. T
	his document describes the overall architecture of HTTP, establishes common term
	inology, and defines aspects of the protocol that are shared by all versions. In
	this definition are core protocol elements, extensibility mechanisms, and the "
	http" and "https" Uniform Resource Identifier (URI) schemes. </t>
	<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 723
	2, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="97"/>
	<seriesInfo name="RFC" value="9110"/>
	<seriesInfo name="DOI" value="10.17487/RFC9110"/>
	</reference>
	<reference anchor="QUIC">
	<front>
	<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
	<author fullname="J. Iyengar" initials="J." role="editor" surname="Iye
	ngar">
	<organization/>
	</author>
	<author fullname="M. Thomson" initials="M." role="editor" surname="Tho
	mson">
	<organization/>
	</author>
	<date month="May" year="2021"/>
	<abstract>
	<t>This document defines the core of the QUIC transport protocol. Q
	UIC provides applications with flow-controlled streams for structured communicat
	ion, low-latency connection establishment, and network path migration. QUIC incl
	udes security measures that ensure confidentiality, integrity, and availability
	in a range of deployment circumstances. Accompanying documents describe the int
	egration of TLS for key negotiation, loss detection, and an exemplary congestion
	control algorithm.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9000"/>
	<seriesInfo name="DOI" value="10.17487/RFC9000"/>
	</reference>
	<reference anchor="EDE">
	<front>
	<title>Extended DNS Errors</title>
	<author fullname="W. Kumari" initials="W." surname="Kumari">
	<organization/>
	</author>
	<author fullname="E. Hunt" initials="E." surname="Hunt">
	<organization/>
	</author>
	<author fullname="R. Arends" initials="R." surname="Arends">
	<organization/>
	</author>
	<author fullname="W. Hardaker" initials="W." surname="Hardaker">
	<organization/>
	</author>
	<author fullname="D. Lawrence" initials="D." surname="Lawrence">
	<organization/>
	</author>
	<date month="October" year="2020"/>
	<abstract>
	<t>This document defines an extensible method to return additional i
	nformation about the cause of DNS errors. Though created primarily to extend SER
	VFAIL to provide additional information about the cause of DNS and DNSSEC failur
	es, the Extended DNS Errors option defined in this document allows all response
	types to contain extended error information. Extended DNS Error information does
	not change the processing of RCODEs.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8914"/>
	<seriesInfo name="DOI" value="10.17487/RFC8914"/>
	</reference>
	<reference anchor="RFC5704">
	<front>
	<title>Uncoordinated Protocol Development Considered Harmful</title>
	<author fullname="S. Bryant" initials="S." role="editor" surname="Brya
	nt">
	<organization/>
	</author>
	<author fullname="M. Morrow" initials="M." role="editor" surname="Morr
	ow">
	<organization/>
	</author>
	<author>		<author>
	<organization>IAB</organization>		<organization>WHATWG</organization>
	</author>
	<date month="November" year="2009"/>
	<abstract>
	<t>This document identifies problems that may result from the absenc
	e of formal coordination and joint development on protocols of mutual interest b
	etween standards development organizations (SDOs). Some of these problems may c
	ause significant harm to the Internet. The document suggests that a robust proc
	edure is required prevent this from occurring in the future. The IAB has select
	ed a number of case studies, such as Transport MPLS (T-MPLS), as recent examples
	to describe the hazard to the Internet architecture that results from uncoordin
	ated adaptation of a protocol.</t>
	<t>This experience has resulted in a considerable improvement in the
	relationship between the IETF and the ITU-T. In particular, this was achieved
	via the establishment of the "Joint working team on MPLS-TP". In addition, the
	leadership of the two organizations agreed to improve inter-organizational worki
	ng practices so as to avoid conflict in the future between ITU-T Recommendations
	and IETF RFCs.</t>
	<t>Whilst we use ITU-T - IETF interactions in these case studies, th
	e scope of the document extends to all SDOs that have an overlapping protocol in
	terest with the IETF. This memo provides information for the Internet community
	.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5704"/>
	<seriesInfo name="DOI" value="10.17487/RFC5704"/>
	</reference>
	<reference anchor="MD5">
	<front>
	<title>Updated Security Considerations for the MD5 Message-Digest and
	the HMAC-MD5 Algorithms</title>
	<author fullname="S. Turner" initials="S." surname="Turner">
	<organization/>
	</author>
	<author fullname="L. Chen" initials="L." surname="Chen">
	<organization/>
	</author>
	<date month="March" year="2011"/>
	<abstract>
	<t>This document updates the security considerations for the MD5 mes
	sage digest algorithm. It also updates the security considerations for HMAC-MD5
	. This document is not an Internet Standards Track specification; it is publis
	hed for informational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6151"/>
	<seriesInfo name="DOI" value="10.17487/RFC6151"/>
	</reference>
	<reference anchor="SSL3">
	<front>
	<title>Deprecating Secure Sockets Layer Version 3.0</title>
	<author fullname="R. Barnes" initials="R." surname="Barnes">
	<organization/>
	</author>
	<author fullname="M. Thomson" initials="M." surname="Thomson">
	<organization/>
	</author>
	<author fullname="A. Pironti" initials="A." surname="Pironti">
	<organization/>
	</author>
	<author fullname="A. Langley" initials="A." surname="Langley">
	<organization/>
	</author>
	<date month="June" year="2015"/>
	<abstract>
	<t>The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC
	6101, is not sufficiently secure. This document requires that SSLv3 not be use
	d. The replacement versions, in particular, Transport Layer Security (TLS) 1.2
	(RFC 5246), are considerably more secure and capable protocols.</t>
	<t>This document updates the backward compatibility section of RFC 5
	246 and its predecessors to prohibit fallback to SSLv3.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7568"/>
	<seriesInfo name="DOI" value="10.17487/RFC7568"/>
	</reference>
	<reference anchor="RFC3117">
	<front>
	<title>On the Design of Application Protocols</title>
	<author fullname="M. Rose" initials="M." surname="Rose">
	<organization/>
	</author>		</author>
	<date month="November" year="2001"/>
	<abstract>
	<t>This memo describes the design principles for the Blocks eXtensib
	le eXchange Protocol (BXXP). This memo provides information for the Internet co
	mmunity.</t>
	</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="3117"/>
	<seriesInfo name="DOI" value="10.17487/RFC3117"/>
	</reference>		</reference>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.911
			3.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.195
			8.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.076
			0.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.521
			8.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.670
			9.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.689
			1.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.427
			1.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.760
			6.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.844
			6.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.917
			0.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.911
			0.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.900
			0.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.891
			4.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.570
			4.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.615
			1.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.756
			8.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.311
			7.xml"/>
	</references>		</references>
	<section numbered="false" anchor="iab-members-at-the-time-of-approval">		<section numbered="false" anchor="iab-members-at-the-time-of-approval">
	<name>IAB Members at the Time of Approval</name>		<name>IAB Members at the Time of Approval</name>
	<t>Internet Architecture Board members at the time this document was appro ved		<t>Internet Architecture Board members at the time this document was appro ved
	for publication were:</t>		for publication were:</t>
	<ul spacing="normal">		<ul empty="true" spacing="compact" bare="false" indent="3">
	<li>Jari Arkko</li>		<li><t><contact fullname="Jari Arkko"/></t></li>
	<li>Deborah Brungard</li>		<li><t><contact fullname="Deborah Brungard"/></t></li>
	<li>Lars Eggert</li>		<li><t><contact fullname="Lars Eggert"/></t></li>
	<li>Wes Hardaker</li>		<li><t><contact fullname="Wes Hardaker"/></t></li>
	<li>Cullen Jennings</li>		<li><t><contact fullname="Cullen Jennings"/></t></li>
	<li>Mallory Knodel</li>		<li><t><contact fullname="Mallory Knodel"/></t></li>
	<li>Mirja Kuehlewind</li>		<li><t><contact fullname="Mirja Kühlewind"/></t></li>
	<li>Zhenbin Li</li>		<li><t><contact fullname="Zhenbin Li"/></t></li>
	<li>Tommy Pauly</li>		<li><t><contact fullname="Tommy Pauly"/></t></li>
	<li>David Schinazi</li>		<li><t><contact fullname="David Schinazi"/></t></li>
	<li>Russ White</li>		<li><t><contact fullname="Russ White"/></t></li>
	<li>Qin Wu</li>		<li><t><contact fullname="Qin Wu"/></t></li>
	<li>Jiankang Yao</li>		<li><t><contact fullname="Jiankang Yao"/></t></li>
	</ul>		</ul>
	<t>The document had broad but not unanimous approval within the IAB, refle cting		<t>The document had broad but not unanimous approval within the IAB, refle cting
	that while the guidance is valid, concerns were expressed in the IETF community		that while the guidance is valid, concerns were expressed in the IETF community
	about how broadly it applies in all situations.</t>		about how broadly it applies in all situations.</t>
	</section>		</section>
	<section numbered="false" anchor="acknowledgments">		<section numbered="false" anchor="acknowledgments">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>Constructive feedback on this document has been provided by a surprisin		<t>Constructive feedback on this document has been provided by a
	g number		surprising number of people including, but not limited to, the following:
	of people including, but not limited to: <contact fullname="Bernard Aboba"/>,		<contact
	<contact fullname="Brian Carpenter"/>, <contact fullname="Stuart Cheshire"/>, <c		fullname="Bernard Aboba"/>, <contact fullname="Brian Carpenter"/>,
	ontact fullname="Wes Hardaker"/>,		<contact fullname="Stuart Cheshire"/>, <contact fullname="Joel Halpern"/>,
	<contact fullname="Joel Halpern"/>, <contact fullname="Russ Housley"/>, <contact		<contact fullname="Wes
	fullname="Cullen Jennings"/>,		Hardaker"/>, <contact fullname="Russ
	<contact fullname="Mallory Knodel"/>, <contact fullname="Mirja Kühlewind"/>, <co		Housley"/>, <contact fullname="Cullen Jennings"/>, <contact
	ntact fullname="Mark Nottingham"/>,		fullname="Mallory Knodel"/>, <contact fullname="Mirja Kühlewind"/>,
	<contact fullname="Eric Rescorla"/>, <contact fullname="Henning Schulzrinne"/>,		<contact fullname="Mark Nottingham"/>, <contact fullname="Eric
	<contact fullname="Job Snijders"/>,		Rescorla"/>, <contact fullname="Henning Schulzrinne"/>, <contact
	<contact fullname="Robert Sparks"/>, <contact fullname="Dave Thaler"/>, <contact		fullname="Job Snijders"/>, <contact fullname="Robert Sparks"/>, <contact
	fullname="Brian Trammell"/>,		fullname="Dave Thaler"/>, <contact fullname="Brian Trammell"/>, and
	and <contact fullname="Anne van Kesteren"/>.		<contact fullname="Anne van Kesteren"/>. Some of the properties of
	Some of the properties of protocols described in <xref target="decay"/> were obs		protocols described in <xref target="decay"/> were observed by <contact
	erved		fullname="Marshall Rose"/> in <xref section="4.5" sectionFormat="of"
	by <contact fullname="Marshall Rose"/> in <xref section="4.5" sectionFormat="of"		target="RFC3117"/>.</t>
	target="RFC3117"/>.</t>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA619W5fbyJHme/4KHOlhbR8WJfXVXXO841Kr2pLdktuq6tHO
	vuxJEkkSUyBAI4Gi2HXqn+3b/rGNLyLyAoCl9cM+eHrEIhKZkXH54sqLiwvT
	V33tLotn723V9PS/qtkWH9vV4Pvil67t23Vb+2embNeN3dP3ys5u+ovKri4O
	+teLPZ50jW3W7uLVV2Zte7dtu9NlUTWb1vhhta+8r9qmPx1ogXdXr826bbxr
	/OAvi74bnLm/LL42x+1lcf3mvbl3zeAuTVFsu3Y4yGdFER/Grrad3dNn9OL6
	snDl/s+0n2Xbbekz2613l8Wu7w/+8sWL4/G41L+9wLf3tnlRV77Hzl7Qg/RA
	5w5temBb9bthtVy3+xcgBy22am1XvpBjnzsyLVHTiX2fFsmfXOqKVfuFNV58
	marLXb+vjbFDv2s7oswFvbMo5D7e245OU9zu2r1vG/6DE7rs+z/X7dE1fdce
	TsvG9eMH39j7qixu1ruqsb9V+YOl1w+Xles3f97iU1DEGJCt29u+uucLenv7
	/udLfjIwET55xp+URJPL4quXr364ePn1xcs/8ofedZXzWEUeK4pPb69uP/3l
	svi5ugfj3fS2KYlqsqjtto7I+izQFWRY+oNbL4872x+3fK143duvZL0/XRYf
	f/rxh1evvpY9VP5QW2LEt7e3v7z4yhhzcXFR2JXvO7vujbndOfBQU2xbWxft
	pujpAyLUse3usBuvu/EF3craeV9Uvujbgm5lVTv+dt3S93rX7Q1uiyjtOruq
	6qo/Yb1wmX5JF0TPkhQNe7qRonR+3VUr5wvaCFEzftNk174obLF3tuF32jXd
	wIF4d0fvtT1veVm8PhXuvq2ZdiBMtalI/EjWaOGmNBU94fBC+WxRVD2OcGhJ
	HvkELbF/OaxdYferajvwtu9dR/e5d1ihWHeOLrKwZuds3e/odevWn3zv9kuh
	X8eqogFxDl3VrCt644LOTmcoDrvOelcW1hfPVq5gqe/umX1INxS4xOLUDsQW
	TbkweF1NNOnoLvK/0sndoX+2KHa0DtObNlrSsqA/EbLaNrzV8WENkf8droTu
	M7+HtyQSdEImBRZcOdoo392hcz2tSq+2xb0lRpU7PNqTX5pPu4ro5du9S19W
	Qu9cfSigzTphCaFUYKewB6IJ/bPzxdo2pnFbpkJ9Kuxm49Z9MeeecA3L4tPO
	YU/hELhB4Zr6JOxC/3PlIn1BiIKXjeiiby/sfVsx9TzxXdVvbE2EUeHYV2VZ
	O2OeY+NdS7zBxMRV0/Hozdu2LYnn6AKIQ8FAfthuSfsJV5J+PeGFbUeik9Gd
	1DJYZSBVNd410f/UNrybqiMq4KrphUt6fXGAalsPte0gCb76zbHY0aJYn74F
	Gr+7vv3JMDlANciYKyED4I+Wb4CY9Qgh3lUHPOA+s/7fPimcZlN1dB5SHuvB
	exLRnf2NlQA443CoT3i4f4L16aVtsepaW9Ld/s47Zx4e0vceH3+/4Dtp6db5
	egriFeIPkQnoJbKdp4K0LL21KWu8asoahjZOdNjzhkp3qNsTtu35dcXDg/AG
	vYru9F1JzFifMt6YqARmCJLNwFBFdjW+lUsdGveZdAuRFIa7rFS/dHwV8UFw
	RE/6B/JOJ+ycJ73kymVxA6HJ97mvtrueDlvVNUmCXBQTtvBk3/oLqFP6Ul9t
	dY8gR74A74o23rQ99u6sr4iphgNsDsnBaqDVh/WOvoLr41foV4mKxKK0iN45
	rl3vuSw2QwcRJbKaREUIxvOIhBQZ8Z0/PM8u9mllmLTMbtgyoZpNPYBWouf8
	zh4CR6k2azcmVx3L4srDFql24j8RDorGhAThiuBG1dMdDdCev4R3e9VCJmrC
	h4d/Jwv56odv//j4uHiai215X4F2PRlq83D5z6Ht3aP578VrZtKKFNYRSgmK
	G3vHhfdtTSza6F86t3Zs0pdF8W7Ccnt6H9nnTVsTPpmaLVKsa3o10Wn0BpVl
	Nc6L7I09ENjGDjXEvznQ3W+6dp9/m7bAKhTi0g4rUsW4cxLp8WPERLRHEhZa
	70igjbQVHYMo2sgRC9d1xIh7opTdOpKKGjTrlY0698+h6qDQTkzxYnwwtpb0
	Nc/yJ7fJl7e2B3oFgECBu+cH8HHLqjDcd2KMTBtgHTbFpMEIB5LmhYUlOez4
	GYiUvj0Yo3TXJtdYkIyqoYtlfhK2ZM05rBn1TEwZ7PnR1TX+i6PGzRXjzSXt
	D4jlGlj2ZTAllq1l5xSBWVCr9+GezzElcWImfbA8hDKOWKd0sKGevnBZfMg+
	B9RxHf4mDLMhIMu0htKrnWXNk7QbkWFHoLjtyNzT8S7UjJZpQfD+PYsFSEYr
	kULGJbIZJIVDfs7gCGYR67Imof9zMu16PXSBpHW7JvqGBQkU8F/iC1izVbj+
	/X5o2I55ZkYYRJMbREFyBCLpE1oRKjKt0pLvZNduM5DuhygymAhi4Z3u0wQu
	tyvYU2LyoelczXpGAS8EeEp22/d2fSfUvoHFZuVqwQ/rviWr1jYTdqEtrej6
	CagSsRYjhB22DCXtzRm6imwKXTwzWAOOhlWj05PXJPZjbQfvJpbKk0gCpZB4
	/ETkcZ/tnsFpfCkUUUJueENzb+uq1JeWrfPNf+OjtUfWyNBGuFaG4yAHWRy7
	KNZkq0kjyD/oTWA68pPYqEKnhVs9tkNdCg48ko4LRonX52PMaI2XpkMxyd/1
	wWZHGI/Lp4/Gpl3APbSwk/PoPiCxI9VE2lDsI6neA4tNjxXVQvo1OSNdRU7P
	53U9lGD+XUt7F9t6FFkW4owWpT2T9iG38ATxJDxBOIq0vQ06N6jRygvSAVJ4
	RzqIpHJhWKl2jjESX256V4JFnjcti5cgu3yhD0gVYN0kvybotJFWBszkl+EV
	i/P4Xk3oU3ayhZBG0s4vQWwU/y03N+zuBJMTDVLVK16aboJ8lmYMtSMl205P
	2Q4+knXlgggDj5Hv2OVmlCAIGTOGEz0jCFHwwt7q2G1IgfR+bjlyrIt9QMvD
	g7FbCxsSlDEuRDSFAU8NWNn3cB5EyBuHzdnuxN6c4PGIWsDQY+9u4spiW6pG
	oJ+DFYzOnW0mFFSa6XV5w2+QuxHFF42AygqzF7ubJPDBrrKN8DgzRHvNXixJ
	rwlCAjfqNrjOWJG8SChIwrVHFb/g+hW5ghJFN4H5dGvDfoA6znzyajND8JGJ
	xFEecZkIcfAY6E6qbdWwUWFroEoDckoW2A/7Q6KVGBjWC1m4wLG7alTjsa8s
	1BcGIh9tihbUf20bJ69wAb/zEji6iS7Z9GhsGUQzeTnjBmB/BS2e3d6mtkTe
	jXO1J3xEzmkP/EF3waAouksqoxWDtq5UzPFFDj9atTkcb2gN+zSsfyvRVWDl
	levpqMRcZSfytjqFsE4exCuung71gNSqS4PtH0eQkk+/GDn0DGyMOEfQlpAI
	2uhW8UcLNiMaQTfU7Jl3xEvCnvd8lribafgIrA+mn18KPZx7Y0w/mITMob4y
	6RRCdnvnxN8VInR0e0El53TIg2YEfAhUNK1RKQy+YgfvQEHGEz64xjhmURUB
	PuzTPS9+ItGtUrDuZkQAUYKgnvusLsVxV613X+aVktRPTS9kAIUgiS8IUQxg
	R+JMD8eXGYrEvQ9ohgl6GDoSMwd5hUPbEf7xbIb3gT/Ti4Rshvw4DagWvxvh
	reisji2yuH4vv//u5ePj7xkbAx6Uyq8GAiYxHdxXRwexiNsU+5YuTFYIajmH
	5JlzKDEyfCHFU2GHR7uoAnoOAAHoc+h1XeXFIllx/pwVULyoskL0JIZGkpWE
	rxk9DUgGLTSxG6SJgcHORCNxIcHbDI6AuA0pKIn1ep+c28xjEPcOFwaVnflc
	6d7oxFAQCsnJ1/vNzc/3BEZbh23TecSlUXymHDoQbo3L5ZxCREjxuKM9ISgU
	lpiFjNlQs+hY1rE1IvC035UTfC02Yd92LgX5ANoZaohwTug9VhY4XaOr4DHd
	hjUTVHaV9B4chw2IvkUkGhYAopjZVjgxfCsDxOcq6MJyFC+t9nsyHAP80pPs
	n75N7pFsyMadnNeGKViUPDBaB6krkNjxvw47Rql062oQRWPDUJn/h+aovMAK
	T0CVcLAxV9Ak+7aRgGCIKcyiPjfin+McMVWnYv7tV68Q4THRhe+C94sd2tyu
	HIjpiXNtJ4SBnKsjV1d3gVAcM2BiQfG69a5ht5OcAvKUHZs3AB/QYVjlYYfD
	WWXkF4YRLV+eiECvITEoGTboC35/zVEN8rtXAyiRxUhwAwxneSlIwFMBiyCd
	JH57+F0sYxPeZ1uTyxe71y2hZIhayhpsmxaqx0TwXSTwLW4jwvP1vvVwHJE8
	UMSta5GPUQ/BP1OlB3iiNun6M9EhKoOH5y7/96Mxf+Hw+/hLD/9+/T9u/0SX
	/t33L394fGR4sid7C0EDXBIgQKrnwJH2lgzpEddqxK+iIwQspgbZNfdV1zbM
	ZpyJCdybi1SQM3UXgoUFRsT2yknGAq4VECzCvx5ooAlu6zxOddbXItneMMyq
	SbUTDAaghDieSKs1EjmidbueTsbxOj4lwUVE18zKbcDbtmHnW58TjoDLW46c
	5Z6jKxKlXgXUWibNnNR/XGflxLvSECh7J0fOWXuJiwGLk1xz3CwFlsYXuXe4
	h8qTevNAsJXfIVZVk34puiH3i4ITjCSXE3Wr0orXqg/IN0s7tER4goYhy6Hy
	DlvIEhDSGSZ61rTo3tYwZeJXk2SQ01IHzyikBaa4kG2h48AL3bDAdfGP1IGX
	DBGTdZb1EjX7Ybx7k3YvgGDFpgj+MZQF48Dgt5Ervwn0pLNFWgpe5dBtOqEE
	DfUSxjmyMgg9siagZmRi5aWQMkmGhpUYHXujSTGVInV5rUAKVUniP3FgsAC5
	6B6edH9gqhvRftYTU+K8vNQ01OMV6Ce6S0hl5tYa9eispPFG+aYRLy6LX734
	xcHeMCvAJ+U8j83IMbYnEhMuVqR35E/Nk1yOTCgDwZ70suMoyGYD64pwreRm
	zhhB8BLtfCiZux4erg5g6OpzcbX8GvJAuvDxEUiwF8EU3ww8EFVhCCtkdzsl
	AKH1CuaoPglEYP3Qdy1BEd3FIWg8TrsRVm5ZE7/5cPMSuvir775/JTk4djVq
	umS40Jmdfr7hD4NmzzBPBHuRRwUs7YGWi8YSMx8Jq7KeyQKWXsLJvTxvJs/3
	wE/0+BE+Xcfue9BMHuTmhVhHMQzYhB3nSpz/wnUI7jMrXNEgYxG65Oy5MuaF
	cfwlpWQbrG/w7OEmtg39bYDjfMGypTUHERLMSys0I6vhOxgf79R7JG5BiQAt
	4VUwVukwC0BN3mg3P5eiDYnlK65iFRZ1FEIKn8QxCZZe3TzmTjoCO+QI50pY
	It5vyHmSw8HuKZtnKN24C96CRJVlpxndwJ1N21ww6u3lPUuuvimkJgim4OEB
	H5D5r7wIHUe7kxdGaJ2dJ2YJUS2Zp52FTjkyzoETBrvVwcacq5xCHCy6oaCq
	zYrLPBBKtr0VhJ4MbVyCo6tzoiR4B6gcgv/rGEjSchNyCqSAYDu6OlVl2XHD
	WSpvog2P0UY5+Ou//AJhpf9AVL/5CqK6YDeA9hyO54tff3lzdXudLFI8Zvyk
	6hUNhIiaHtvxDf3iQsnFuj2cEA6Vc/qYX2ShY1FZmMjvNcesDnYr0a2QlEAg
	AbkM+P3YMp2ADkAXvkeVEjSkJQbjSjtQ0XH4ID49OQtOqynL4Jj1HMGAUEJF
	1CeTGUWWNGaKLPKzkHNqWiPolwQd9JUVcm3kPSB5RlpH3FB6mDNmyI2f5NmQ
	BBdsQM/jugG/YCjF2VaPoezskVj415oAJR0clhpE+f67l9/ptV58vH6Lq8VH
	RKHMiPXiCGj8lkMvKsJGU8+CtRaA7PXAtlsI3HanmNHhigQOQ+A8khhOtRHL
	sTa3o2wIqwfBvkkNyx1pgCDLOhSe8I/xjnZA+0VmEVgjbJRzH1XakewjoJxR
	iQNRd61hLJuUjoZ6EGwKAbUvZo1zNP5JXTfDtw3XaATm5kAzulpavsF5b4aH
	tAN3j1BC6XpyUv2/iQzTzV8UwpJS+fDwEKvP6FIvpm8MKVYLk2/C+1mxqm2/
	18jhFD6ROsY9w7LRJ7B6JSisd2meF1dCFcUG7PAgbWEj3MuL+6osZoxrSWo2
	mr6IHdWDTcHylB1ndekrcmxlk5knhjqs8HrRcYzquIYGwc90w+XgFByGup1W
	Ql3TfEpeYaPWIcs2j1+ZXS38t+T5SQlOFvSZViAui9fsKdlQfWgPFSql9MEZ
	rJ3Sy6jTHGOdKL7D/TV2y/lktx46bKar/B0XAlWoRbG8QSGoJn9NHsJmJF5X
	pHdO6zp6KrDRMVcsO/SFq1jDd/gMMlyHYDuH2cR4J5jwRD4jlirFMGfTFu0B
	ETWNmYeKKMEIoq3yDEZkNoQS93tcx6xmjs+bHr4IGtcIDgs1qCpaiEqz+7p2
	LFyMytg1EUjEu9OsHAe5JQq1ySBMFscPGYZBHLvrPYgtGj7npEodu41Ensjo
	qP4Bf0zyuWciwZLPwLLj8jCyHNud6SUgFW5OtBmqDGduFkn4W9vtEUj7MU/L
	0SO3Kc2EDfyaKgzML1kdntj9c8V1oYK2yUOrMZdBqozoSniZjh5zxbNsZBaA
	kmx1O3ReInlrCQ+TTwAlDrYP6Y2YBnjj1haxpBL/RaXa03nPLOrBRsuVWoeh
	PpJmWmPU06SoZ7qBZNqP6g2yzxaCFxIuTRpPNELtGrzKBG1KGIFTyeL6w2+O
	ANayDy9x36lnEJN9SIuRtWpRIIPA+AFdA2TCpqTkdyC6z5WxSIZuxM8cFF0Q
	sT3z+ZMFmfGlRPg3ZGM6BjlTXmA3eVIjscd3Z6W+yX0a1w5NMtrssgbAwK6P
	wgS2Y23DEG2qgIu1w12IW6SRzpGTI+prXLJHinQrykvquvNSz3DBg1cgo3sH
	eSGFEu038iAnN1fIQOuWNdIcwg15yLApNHgKYOpEcRo+H7kTWSmk5rTrGG+P
	IVm6eZeFf0J4c5JZSceKjgg7b2FnbyoCzJ3TIJugJDO9is0U46Q8UxQwuead
	GBpO5oMlovokql+PQuKcEogFT17cRinOzUMFHKwCOFtoiJb+Xy5oak3uuoai
	oSyAvkSx3AQH4Fs7eiTlUBV803J9Z0uXv1EdjGmOtVFcSsoXSHhemCSo02q9
	XxYtiAnhpoGNDaYtXvb5IhwtbSfmscRzdbuVijjSsCu7vivYpi+LvwcpuzTm
	D7Oa1KAetCi/LAteJwTW6OhVwwVM7OHCGpGl9Puqhxk3RcHlJCFGMz7RUWvX
	1FFEjOUPxXXkyJmeYE9iM7BUS2404n8puuaXaECukIyErnrL1X3K7XLhIVpK
	jsp6B8hBd7bmKOJZi8WKAfnXLJQtcEFWZdcG6Znzy0MfWJJEEZ/YQEPOu/QF
	TEp4RhGQvIiWw23iiDiN8EBLN32WmpVYl0Q0x2WxyfNZ0SlZ60Sjzq8d2/Rk
	BCXfyzKJzgfR2Y2VqmryUugzq20PIhwbi1DozP8rrlFUiKjMGekQuzPKsXjV
	QFzypucHJau9Fm2R4D4jJcxlS/TfzFN5Rjcyqm5EM9jPN/CD6T/wgf/4zTff
	IbwRg+OcKqWD9XZ7QWZ32+8uOLZQSHMXV6aFtoBSCl+yiAcwP/JeqBRLtlSw
	NcJbM54yqOfnqiPE1kmy1YeuNhIGp1tpB5CJIxjY+49c/fnWkaccC9pYaQDm
	ctUqw5P9oT+lU9GlZwpyRvegVn3YJpfpkjtl2LhIyCP6GYtiLRWoU/ngL+ds
	CiIdxYZIzAnXwzYnqyu1Z4/EPhSXUHFwb3IcY6Cx/kV3PEPRTM6O78oisVch
	GqQwMTROBFD6NHzKMMnYqzDnq+aCWM6S5ERWJHAq5Ec5RsGw8Qw4ynMtHJAG
	je8S1DwLriVWZBBE8MNKZLzPnYGQVg1xg+J6I+WJD89TLIEkiGN3K3CGYMsR
	N6R9cWaQ7oR25LNwaX9kXcfh8paISngnVZuirB55iCPCV5Io1B4KcOHgRaGz
	6QkGUOrdWFkl/SgKWKzXvAqQHilbiBnnfxwaNdexWUNaB20ol5g2J3jOdJ2x
	BpwUz2otYgF9kN2yZe1byBtOITylO84CjJ6Te2deERyhTfU5LFOpa4hSLfat
	Oi26XrlxaD6moEXfi8QF773lJpPcL7QheVGxYYscDoqS24fb4FgiHQ4COdpL
	LOTlSP9TGTsggfzRuf5QvRo5Kz+PkmhWtMSc1kiQQtMbKLtvuHIJPmTwG6GY
	w9YmO5E41f9PSo4RgkQqJ4efVkftIDmcKdZyoqn6yRlmFDqb2RQOkLkelyFA
	Jpf5SSmfNAvFAhtEQmJoIYQ4LgxuhhtL1dfi9N8k1jELHRRFHoQGnAn8PMLe
	LBbxzqe3W40wE8Af7DBay9Omk+r2wwGMWsp181frvJwnhIQVF6gq4/RapsYE
	ZovS8QSXZ2W7HP7yUgF2wd+YYxlsTxziUJYrcW1U0qCtBPbpvqrdFoFQd5Ti
	xuBOr4aqLlOlxgQcShEHqhAR6CCQUhFhteYPxgtBB/U9m2FP4NDMb4fvnV3X
	+Ax52KRDnZxfM6ikmO2dzwrS6QyGs6SzAwfpDXlqTiZXnvtrYjLy2KJ9VBoK
	+GxZIqXTAAvLMi571wJbB+swa3Lk75USU+CGzI3tjGWYnqrTV27mv8coVixj
	mIW8Q6CHDUUpRakN4SGu+JIepi7mKDWm0lV8LZxGeKK2NtBIUsV166WptCFA
	Qj5KxIukXdg0Yblz2+Pt1IR/oXFzsnCEi+MNXIXVKkTIq5OW5+yjWKqRWKLA
	rO85xc0VZCEwOn2UjyuXwNkgjlVm1kN1m+fb1up+WsOu+5BUiVBjXCwhBS/n
	VNudC8VtoYCbyHBfZaMFpqt8UVNydcIkyb2KgVxNU+AaOHJfidANscuHnaIQ
	JjEp6MIRnFAGIl6DVkVUscpfuIG+qIWcUiCm5lMy2ZJPCYqTK9htRy7Bmfrt
	xIo4kcwu8OogBtKYVD0117Usc8i6wSUtYouFwutJ0/EZ7014XHTjTKRA4JFu
	iO6IulQmxRLGRTGphuRcnSc++5lk/eIWndH/kbGBiUHe61j69D6VPkkt6A+v
	vn8ppSg3sQiPgxICZGMD6JO0hq09kXvSYvTHmu2gNBDmkSgtLCiuiknpfyU4
	Uj1Zzqqk3o+R4C7MChjgXrRMKMkpzw+3EFAkqkE8eW5Lk5UXRq5oVLQotUDL
	L8a/Q1sH99+iAD5QYRGShDw3AjhKgWKfJX4WimTx3j2Phek0fyhdD/G23mep
	kofn2mv+hR5yFaMdKW2ge/Zh1F/wduO2g5X+rtCExQW0JsSNZ3GXLM5KFNdq
	hetUcHKUiRMjopMXCXb2RDMhchkKOOWWgC/g55VsU4nJFmOUuhpBRqNBqtTk
	NPE5SwcvnDeCTjStsitTeH1c+m+k1KwizhM/bLR3sfec0UJe4Qv9kjjipMc6
	dizkiDck/9fiokziwWca1jR8liImfLQWygI4c8LfcLQ0Fqe5wpzdz+i1i6xc
	QbJc6j5faGhJQnXGsp/cVz1KK2J47os5odgrdi5iGAubwO8SedXS7lRyU7wO
	HbyQqloim6nqAG78pPcsOjFnxP6MR8WFZEGrn5/QYSbtMyHDVPk0ToRRvJbZ
	5KMoWKZi+D4Ob1Ex5DNsBi5mOAdARyqIQcJx1zJI+4lrQFIxRqsuHm1ZBnBE
	gx/avUcYlYOb/wqFYlf1oeUaiGQEucoFQb5KJSAluQIaaOty0kGnFbwdKlAy
	kR0FIUWBNCPkG4AyjzoIXcWh6W3Skawdw9qPC8VsfSi5X2lrdtb+y5F5ph+X
	vWovNz22GCtAtHLaJlT8mHzggkRA1SAlvMYG6aDt8bwWLB9TBqUH+FQb6WaZ
	JakCgB7FyVFo3qy5WHzD2CZg/unZ+QZnBRqoXMzz6zq1RMpefPBa5wOruNrI
	c7ZlJyUuOnkNhcegGmeZgMniKaYt0jcxsBaS6edaNYl3CB2sd7pQOdVoo5DC
	ubqIvH55ooFlnsy+vddpLjx4Y8Up785H7DrzzTMjaxhbydwun0FqbYgM7v3Y
	i/ggbRIBBHP/AO2MxwtxLtuO29ZS3W6KrRAEi904S5PgWjaiqQtRnfqUgrdl
	1rvpZlBSaJxCgxNaT2YqVTpqRmcraXlOjBNIi7BItQZgzpR5CC6b3WueVuCU
	DBsJo+UiUjyH8K/VYjPZOdtMhlhdr4n86eW9a/ibochE0B1pzvTNrMxofA0c
	T4mTMRCNjlWwKhYLI7GDU1AFqmQEa1fdrL+M9cvkHQipoMe49WfGd0WVqX5n
	IKyg23FrlDRqnO/D5Ur46aATydJyME0GA7C6nYku8u5DE9uTREUDHspwOQ4B
	YfMJTsq0uWmRhTXyXvVrc+tfNaFqNvK+8q1dj4qFiCeCAeIEnVTnx6YzxzhI
	+404Rx7m6gVEjXafyrcynQSpsHErITacUuej3nqUBJNPKS4lvM3rs+mE0YWw
	IbYql3Q6ukx1DPl8GtaQCUYzE+yViWJOhMPo2vIySVWc4XuT2eOZtLFPcT5O
	v3JhMN7qxP5daiwZxW55SsBSC5s0I5oKJJxmbdIDXB/ve5NCB3STcHDF+5PK
	lyeajkOciZ176Svo5OQmSkLJmdIzL+bJH1IlGpP50v3JX5X7hHIYVS5+cNsa
	hIaMkMyt76Scmqcccrjw/ACG8+MZl+Yj2UcusB/LPxK0MsVJIUwVYx3ZBLWq
	UXXHI+VMQEDZaijor2Jx2ggoCm+njCTBc5kpZJtx4ly+i1qrUAsDQsaS59Ao
	PI1dwkkBdLsAIQZkmhfj1F012ZOEuEJ4SKKn8wLPG679igAE2+JOqNTzh2mc
	CE3gv3+SeZ0vHx8LzPLpjM28SNpThej2aIpCuhBeZ1pb3IZqYk7Tt3cjkCdV
	ZDwYYjR6YaIGMWRDSzYCZtZkMU9A1EbkWKe+OjGSCrWsCQ5olGOS8xE9nDfg
	jmK+JiQNSDQ0wMvFQhyDR+ReKwZPuVZTVRQYyx8qMn9fnFxzpjWC9wVBWOS4
	yOcDqtQbzdvr8jx3n+L7UuCjQZ/YX4rhb0RFzDsSTjbKuSGEaz3G3aWZiJqP
	m9yyUjS4xqxY6H0lV1FCPkZdClpVHmQskS3eTJSVxdiN5tFmnUQ69lMZBYSO
	OkWjIfmVpAA962EtSaytFuszoA0Xlp7ThPV/VF3PPcXvUllu8fA8L9KN7aRK
	nFHLe6PDmlLfaMLXRd7pGQprTF6+IuUzMdHC17qzzfop/M72h21meguXkYxx
	fP7eoRk8WrZHXRM/Ih2iPBO7jLIaGznJ0KQTZ4XtIXRHSgkdAIgnwKxwbY7O
	QJMMTs6x7FPG2iy06Ei5naLijN4xBme7Rsa8pOm5XKbZRbgRi5XONXSmBfsW
	c0nJy2/rhEEmCE7k0GcGULydWQVFlVdpxJmxZzJrsdzGB+jGWkeaFrIIVxh4
	yLGH2OSk+ee4HSlvESezT93sOsktGDwilppiDjVxWWTQtov8vU9VB7BPFTAi
	1xlwh1Jqo1Dtc2J3Kq8oIix0Lr8kqJ50IO9YUfvS6EgNQFlpcuBuL5QCc+Ro
	mlOKwedQZ7Fz6zu95i8lLrJj7VFTede0Rx0IwAkoRtUkCSEqo6OFOKw8L/PX
	mmw50rDHjAY2IW2XdVkh1XKxsSj9M1LbBN8CwEVGxOrwCan17+SLMWhZ/J2h
	R3hThuloc3CR2SMvKx5wEJ0IDZir5PIZQ7Ysxm/w5RCv6f9VRJpDdbOzsUJc
	pzlpOu9cqfay+HsTs2owohqqigHHWe5PhpRyE359ylTtuNfqfI617cykaRwb
	Eiw6tlrF5BBf2JEuJENvueynAgr5tyJrQx5PjXjkKtzTiMKRDUN4MIYg1HUX
	0Zm6H3F2oUmlewhXEC63GD6bdbpnUZE4z4phD8qfu5CKMJnFlCNg9xok5p2/
	m6vgQbWvjiZy0/qmQsd+zaqQlmbuAr/7cPXm+h+/Xt1e/6+b6x9//fju9j9j
	QWcpsSfrfbuuGGqMKlSqxshkedr0268IwopjJOXKUwglFQfanqTILOovdJZy
	aS3JRNL+0iSY15jGSTEc//BpiNJoNm1IrBlIQUjDsaJhHsNXl1KBnPW2anqW
	HazVqEkLzSUnY7tVxSJTxF8BCOF6rWnAHPRpuHU0WTAcezR2N41JkBmtkj3T
	OGsVAjIBgC6Lf/z67kc97gbTIbwhVwIfsivx8iW7Ep2b9ECPyZhmEEiVBe3c
	lXmw2sdRaTH28s/B6oAm7i6azqxK7WNLc1PtK3ahFpKWhU/+5sNNKPrmMQHX
	XJr7w6tvaLtQYbCwbNrQ5WpGGT6JUUkHLE8zEPf0EDED1uZ520OWapJARaVF
	kDdwVWtxAUI9YVNKseK0rbt0TWXri3ZzwfWQaxdGvoayP8wKK2cTkb302rHH
	JLMCGXGNCnizMviQVUKIakByq9ex7TqFUovZz9etBAM6HaBppMI37CgO1QlZ
	JwzUCcpFlGIkR9aqHveauXjRhxkVweS/AxI9Kp2UWsYqSZmrFZLgjGCDbKVo
	ZuzADG8ysftRRHecK0evkZPJZL2+MosrAmtwrv5crVmTTejnzi4GgFNkHDuO
	Jr9pYXPNKhlh5Km4JRgD4AxwIQPbrJ02Ec+FqUgHLnaPdGiyb7eNC79VYWS2
	sDyRzaEMER0bhnnks0inFSEyg4YRurglmq47d/eTWZw88+EqTj3hlsjgIGaJ
	0tECOmSF/RuYdplQQAoDGdilJIU0LBqGpyckmRJzfdT2HAJFUVmmK1mTf2ZH
	C0UzcUSTTua0mps8FwIkPDev8iSTaRIX8Ufs1fjJ2GXpDebEHOdFFmdfMRHT
	NC40VqBK/wQbGhMEhjcWmsaiOI0ZRfsutIllGi7k9+j84LhANr01C3agXUAW
	G5rwcZXfr5lV48mKPc/uQEgmvXF0n/ieAhy4+2Fe0KEbSglRJn0kpZ+Cm3lo
	IqPRdeYGC2bM/DLV7vrbEqOu3d8vk6qz2bQC9on2+bQiicxH9SH3axRXO4nb
	hJz2FELr/stzWcDJDzXkc9btHCNmCawwQ9b2KZPAAHmnfbkyqA8DKLQEJEyq
	zNLRRkacP9XdI/Wn0+KqX0nz8HRkNj4hjE3KNWW/fkwMFNqEdcre9y9hv9Ov
	+SAOiALeGt4gwX8oNddXIVciVbdPTDvNieUFQeSdpeZ5cRPgY9iQ1r6YH20n
	xn32gz+1/TwtlZl3K8oQ2WFECExlsoc21caNkC8neZD739qDBAjH0yotjyDR
	JEFEvSlb8LYKIbZZribyRNYGm/W04JFdFUZqpYH7Ff/eRxMKt7RllRRlGLWz
	T6Fvk5ftxkGvo11ksQw/7pQfZwpYtFLhlF0PPU/EGLsgkiKIdMjnJ4TW0lmr
	X0YKE2a8TVN42nQ7NCgCS+un6GzWiu3sHYpgUOKIQA4x8Ps33/LUwFffviIm
	Ru52RRjSjcO79L2bm5+/5mEq337HvxqCM8OkGcXXPk3dCXo5WZLfjfy536dg
	uK9CsTJ+bOjqw9WMq8c/mbXjSSDyTVVs4UeLgDhkldfFe4dqcLp6QTC32md7
	dQCKtrV5uJR6cVf+6dmGvGD37NGkn0fJfkfFFa/x+21Ei9GCovhHO0P82vL6
	5ERw10I2AhMNY9yz81diZ1r/7q6lf7xxq7azu+J1NzRb4NY/FD+jpeh6u3Vd
	T//6RFQlXVMS83ZoTxkwZbP4q2vwYySePnmPoBvp+L815KXW+KDq/ssWf/s/
	/3tXu2PVYMn/ScZkRSz7c4XeUHLDT8Uv5HqdsIHxr7/9ofg4kPr4hMPTP/5B
	D30asGlyqu/IwhX/aVsRlOw+SvmhIy7IYcBDSq3aI2htldpsbNJP1qDse1OL
	eRF0e0wjg7OREDwNZ6EFAqHpTnvds9/Aub79KQUXjMgPl7Tozy9JqxaXmekc
	wjRNZSlVmQhK1a7csnSd540fuWR3EG8sxj3bqSKIv/KTTwRDtR1pXnEYUp/C
	wbVSiKZmdBFJGCre+/aSJO/hNdIgxINXq3ZlHzHPFR+SWmwKUvkHdlXxMb57
	Q0fryFaRA7QjPR0+zhkprPDX1tX0ITm9XRO+x/f/FmPC3Sl8NuG68PiY9cKX
	p/wXP7fdXfGh7XHpO7sPi1x35J18JMXadrUN330rbwJfDvVvhBSaeI6/tqvi
	pqn+CwA4rPGxXaGA5IbQ950PX3yDNMTtztaJNEKx287u967mDbMXQH+5ojcQ
	uzXF3whno57zETEn/gWGZASyHG2y1pPpKTJb41FYVRoJSRmsTkoBvwP7fWw9
	ziNP3EgfbPHN8lusDDjx9atX3+P9/xeH4pkvl3MAAA==
	</rfc>		</rfc>
End of changes. 64 change blocks.
	851 lines changed or deleted		212 lines changed or added
This html diff was produced by rfcdiff 1.48.