rfc9413.original   rfc9413.txt 
EDM M. Thomson Internet Architecture Board (IAB) M. Thomson
Internet-Draft Request for Comments: 9413
Intended status: Informational D. Schinazi Category: Informational D. Schinazi
Expires: 6 August 2023 2 February 2023 ISSN: 2070-1721 June 2023
Maintaining Robust Protocols Maintaining Robust Protocols
draft-iab-protocol-maintenance-12
Abstract Abstract
The main goal of the networking standards process is to enable the The main goal of the networking standards process is to enable the
long term interoperability of protocols. This document describes long-term interoperability of protocols. This document describes
active protocol maintenance, a means to accomplish that goal. By active protocol maintenance, a means to accomplish that goal. By
evolving specifications and implementations, it is possible to reduce evolving specifications and implementations, it is possible to reduce
ambiguity over time and create a healthy ecosystem. ambiguity over time and create a healthy ecosystem.
The robustness principle, often phrased as "be conservative in what The robustness principle, often phrased as "be conservative in what
you send, and liberal in what you accept", has long guided the design you send, and liberal in what you accept", has long guided the design
and implementation of Internet protocols. However, it has been and implementation of Internet protocols. However, it has been
interpreted in a variety of ways. While some interpretations help interpreted in a variety of ways. While some interpretations help
ensure the health of the Internet, others can negatively affect ensure the health of the Internet, others can negatively affect
interoperability over time. When a protocol is actively maintained, interoperability over time. When a protocol is actively maintained,
protocol designers and implementers can avoid these pitfalls. protocol designers and implementers can avoid these pitfalls.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://intarchboard.github.io/draft-protocol-maintenance/draft-iab-
protocol-maintenance.html. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-iab-protocol-
maintenance/.
Discussion of this document takes place on the EDM IAB Program
mailing list (mailto:edm@iab.org), which is archived at
https://www.iab.org/mailman/listinfo/edm. Subscribe at
https://www.ietf.org/mailman/listinfo/edm/.
Source for this draft and an issue tracker can be found at
https://github.com/intarchboard/draft-protocol-maintenance.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Architecture Board (IAB)
and may be updated, replaced, or obsoleted by other documents at any and represents information that the IAB has deemed valuable to
time. It is inappropriate to use Internet-Drafts as reference provide for permanent record. It represents the consensus of the
material or to cite them other than as "work in progress." Internet Architecture Board (IAB). Documents approved for
publication by the IAB are not candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 6 August 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9413.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Protocol Robustness . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Robustness
2.1. Fallibility of Specifications . . . . . . . . . . . . . . 5 2.1. Fallibility of Specifications
2.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Extensibility
2.3. Flexible Protocols . . . . . . . . . . . . . . . . . . . 6 2.3. Flexible Protocols
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Applicability
4. Harmful Consequences of Tolerating the Unexpected . . . . . . 7 4. Harmful Consequences of Tolerating the Unexpected
4.1. Protocol Decay . . . . . . . . . . . . . . . . . . . . . 7 4.1. Protocol Decay
4.2. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . 9 4.2. Ecosystem Effects
5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 10 5. Active Protocol Maintenance
5.1. Virtuous Intolerance . . . . . . . . . . . . . . . . . . 12 5.1. Virtuous Intolerance
5.2. Exclusion . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Exclusion
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations
8. Informative References . . . . . . . . . . . . . . . . . . . 14 8. Informative References
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 16 IAB Members at the Time of Approval
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses
1. Introduction 1. Introduction
There is good evidence to suggest that many important protocols are There is good evidence to suggest that many important protocols are
routinely maintained beyond their inception. In particular, a routinely maintained beyond their inception. In particular, a
sizeable proportion of IETF activity is dedicated to the stewardship sizable proportion of IETF activity is dedicated to the stewardship
of existing protocols. This document first discusses hazards in of existing protocols. This document first discusses hazards in
applying the robustness principle too broadly (see Section 2), and applying the robustness principle too broadly (see Section 2) and
offers an alternative strategy for handling interoperability problems offers an alternative strategy for handling interoperability problems
in deployments (see Section 5). in deployments (see Section 5).
Ideally, protocol implementations can be actively maintained so that Ideally, protocol implementations can be actively maintained so that
unexpected conditions are proactively identified and resolved. Some unexpected conditions are proactively identified and resolved. Some
deployments might still need to apply short-term mitigations for deployments might still need to apply short-term mitigations for
deployments that cannot be easily updated, but such cases need not be deployments that cannot be easily updated, but such cases need not be
permanent. This is discussed further in Section 5. permanent. This is discussed further in Section 5.
2. Protocol Robustness 2. Protocol Robustness
The robustness principle has been hugely influential in shaping the The robustness principle has been hugely influential in shaping the
design of the Internet. As stated in the IAB document on design of the Internet. As stated in the IAB document "Architectural
Architectural Principles of the Internet [RFC1958], the robustness Principles of the Internet" [RFC1958], the robustness principle
principle advises to: advises to:
| Be strict when sending and tolerant when receiving. | Be strict when sending and tolerant when receiving.
| Implementations must follow specifications precisely when sending | Implementations must follow specifications precisely when sending
| to the network, and tolerate faulty input from the network. When | to the network, and tolerate faulty input from the network. When
| in doubt, discard faulty input silently, without returning an | in doubt, discard faulty input silently, without returning an
| error message unless this is required by the specification. | error message unless this is required by the specification.
This simple statement captures a significant concept in the design of This simple statement captures a significant concept in the design of
interoperable systems. Many consider the application of the interoperable systems. Many consider the application of the
robustness principle to be instrumental in the success of the robustness principle to be instrumental in the success of the
Internet as well as the design of interoperable protocols in general. Internet as well as the design of interoperable protocols in general.
There are three main aspects to the robustness principle: There are three main aspects to the robustness principle:
Robustness to software defects: No software is perfect, and failures Robustness to software defects: No software is perfect, and failures
can lead to unexpected behavior. Well-designed software strives can lead to unexpected behavior. Well-designed software strives
to be resilient to such issues, whether they occur in the local to be resilient to such issues, whether they occur in the local
software, or in software that it communicates with. In software or in software that it communicates with. In particular,
particular, it is critical for software to gracefully recover from it is critical for software to gracefully recover from these
these issues without aborting unrelated processing. issues without aborting unrelated processing.
Robustness to attacks: Since not all actors on the Internet are Robustness to attacks: Since not all actors on the Internet are
benevolent, networking software needs to be resilient to input benevolent, networking software needs to be resilient to input
that is intentionally crafted to cause unexpected consequences. that is intentionally crafted to cause unexpected consequences.
For example, software must ensure that invalid input doesn't allow For example, software must ensure that invalid input doesn't allow
the sender to access data, change data, or perform actions that it the sender to access data, change data, or perform actions that it
would otherwise not be allowed to. would otherwise not be allowed to.
Robustness to the unexpected: It can be possible for an Robustness to the unexpected: It can be possible for an
implementation to receive inputs that the specification did not implementation to receive inputs that the specification did not
skipping to change at page 4, line 23 skipping to change at line 137
specification explicitly defines how a faulty message is handled. specification explicitly defines how a faulty message is handled.
Instead, this refers to cases where handling is not defined or Instead, this refers to cases where handling is not defined or
where there is some ambiguity in the specification. In this case, where there is some ambiguity in the specification. In this case,
some interpretations of the robustness principle advocate that the some interpretations of the robustness principle advocate that the
implementation tolerate the faulty input and silently discard it. implementation tolerate the faulty input and silently discard it.
Some interpretations even suggest that a faulty or ambiguous Some interpretations even suggest that a faulty or ambiguous
message be processed according to the inferred intent of the message be processed according to the inferred intent of the
sender. sender.
The facets of the robustness principle that protect against defects The facets of the robustness principle that protect against defects
or attack are understood to be necessary guiding principles for the or attacks are understood to be necessary guiding principles for the
design and implementation of networked systems. However, an design and implementation of networked systems. However, an
interpretation that advocates for tolerating unexpected inputs is no interpretation that advocates for tolerating unexpected inputs is no
longer considered best practice in all scenarios. longer considered best practice in all scenarios.
Time and experience shows that negative consequences to Time and experience show that negative consequences to
interoperability accumulate over time if implementations silently interoperability accumulate over time if implementations silently
accept faulty input. This problem originates from an implicit accept faulty input. This problem originates from an implicit
assumption that it is not possible to effect change in a system the assumption that it is not possible to effect change in a system the
size of the Internet. When one assumes that changes to existing size of the Internet. When one assumes that changes to existing
implementations are not presently feasible, tolerating flaws feels implementations are not presently feasible, tolerating flaws feels
inevitable. inevitable.
Many problems that this third aspect of the robustness principle was Many problems that this third aspect of the robustness principle was
intended to solve can instead be better addressed by active intended to solve can instead be better addressed by active
maintenance. Active protocol maintenance is where a community of maintenance. Active protocol maintenance is where a community of
skipping to change at page 5, line 9 skipping to change at line 164
continuously improve and evolve protocol specifications alongside continuously improve and evolve protocol specifications alongside
implementations and deployments of those protocols. A community that implementations and deployments of those protocols. A community that
takes an active role in the maintenance of protocols will no longer takes an active role in the maintenance of protocols will no longer
need to rely on the robustness principle to avoid interoperability need to rely on the robustness principle to avoid interoperability
issues. issues.
2.1. Fallibility of Specifications 2.1. Fallibility of Specifications
The context from which the robustness principle was developed The context from which the robustness principle was developed
provides valuable insights into its intent and purpose. The earliest provides valuable insights into its intent and purpose. The earliest
form of the principle in the RFC series (the Internet Protocol form of the principle in the RFC Series (the Internet Protocol
specification [RFC0760]) is preceded by a sentence that reveals a specification [RFC0760]) is preceded by a sentence that reveals a
motivation for the principle: motivation for the principle:
| While the goal of this specification is to be explicit about the | While the goal of this specification is to be explicit about the
| protocol there is the possibility of differing interpretations. | protocol there is the possibility of differing interpretations.
| In general, an implementation should be conservative in its | In general, an implementation should be conservative in its
| sending behavior, and liberal in its receiving behavior. | sending behavior, and liberal in its receiving behavior.
This formulation of the principle expressly recognizes the This formulation of the principle expressly recognizes the
possibility that the specification could be imperfect. This possibility that the specification could be imperfect. This
contextualizes the principle in an important way. contextualizes the principle in an important way.
Imperfect specifications are unavoidable, largely because it is more Imperfect specifications are unavoidable, largely because it is more
important to proceed to implementation and deployment than it is to important to proceed to implementation and deployment than it is to
perfect a specification. A protocol benefits greatly from experience perfect a specification. A protocol benefits greatly from experience
with its use. A deployed protocol is immeasurably more useful than a with its use. A deployed protocol is immeasurably more useful than a
perfect protocol specification. This is particularly true in early perfect protocol specification. This is particularly true in early
phases of system design, to which the robustness principle is best phases of system design, to which the robustness principle is best
suited. suited.
As demonstrated by the IAB document on Successful Protocols As demonstrated by the IAB document "What Makes for a Successful
[RFC5218], success or failure of a protocol depends far more on Protocol?" [RFC5218], success or failure of a protocol depends far
factors like usefulness than on technical excellence. Timely more on factors like usefulness than on technical excellence. Timely
publication of protocol specifications, even with the potential for publication of protocol specifications, even with the potential for
flaws, likely contributed significantly to the eventual success of flaws, likely contributed significantly to the eventual success of
the Internet. the Internet.
This premise that specifications will be imperfect is correct. This premise that specifications will be imperfect is correct.
However, ignoring faulty or ambiguous input is almost always the However, ignoring faulty or ambiguous input is almost always the
incorrect solution to the problem. incorrect solution to the problem.
2.2. Extensibility 2.2. Extensibility
skipping to change at page 6, line 28 skipping to change at line 231
extensibility mechanism can be extremely difficult, as is extensibility mechanism can be extremely difficult, as is
demonstrated by the case study in Appendix A.3 of [EXT]. It is demonstrated by the case study in Appendix A.3 of [EXT]. It is
better and easier to design a protocol for extensibility initially better and easier to design a protocol for extensibility initially
than to retrofit the capability (see also [EDNS0]). than to retrofit the capability (see also [EDNS0]).
2.3. Flexible Protocols 2.3. Flexible Protocols
A protocol could be designed to permit a narrow set of valid inputs, A protocol could be designed to permit a narrow set of valid inputs,
or it could be designed to treat a wide range of inputs as valid. or it could be designed to treat a wide range of inputs as valid.
A more flexible protocol is more complex to specify and implement: A more flexible protocol is more complex to specify and implement;
variations - especially those that are not commonly used - can create variations, especially those that are not commonly used, can create
potential interoperability hazards. In the absence of strong reasons potential interoperability hazards. In the absence of strong reasons
to be flexible, a simpler protocol is more likely to successfully to be flexible, a simpler protocol is more likely to successfully
interoperate. interoperate.
Where input is provided by users, allowing flexibility might serve to Where input is provided by users, allowing flexibility might serve to
make the protocol more accessible, especially for non-expert users. make the protocol more accessible, especially for non-expert users.
HTML authoring [HTML] is an example of this sort of design. HTML authoring [HTML] is an example of this sort of design.
In protocols where there are many participants that might generate In protocols where there are many participants that might generate
messages based on data from other participants some flexibility might messages based on data from other participants, some flexibility
contribute to resilience of the system. A routing protocol is a good might contribute to resilience of the system. A routing protocol is
example of where this might be necessary. a good example of where this might be necessary.
In BGP [BGP], a peer generates UPDATE messages based on messages it In BGP [BGP], a peer generates UPDATE messages based on messages it
receives from other peers. Peers can copy attributes without receives from other peers. Peers can copy attributes without
validation, potentially propagating invalid values. RFC 4271 [BGP] validation, potentially propagating invalid values. RFC 4271 [BGP]
mandated a session reset for invalid UPDATE messages, a requirement mandated a session reset for invalid UPDATE messages, a requirement
that was not widely implemented. In many deployments, peers would that was not widely implemented. In many deployments, peers would
treat a malformed UPDATE in less stringent ways, such as by treating treat a malformed UPDATE in less stringent ways, such as by treating
the affected route as having been withdrawn. Ultimately, RFC 7606 the affected route as having been withdrawn. Ultimately, RFC 7606
[BGP-REH] documented this practice and provided precise rules, [BGP-REH] documented this practice and provided precise rules,
including mandatory actions for different error conditions. including mandatory actions for different error conditions.
A protocol can explicitly allow for a range of valid expressions of A protocol can explicitly allow for a range of valid expressions of
the same semantics, with precise definitions for error handling. the same semantics, with precise definitions for error handling.
This is distinct from a protocol that relies on the application of This is distinct from a protocol that relies on the application of
the robustness principle. With the former, interoperation depends on the robustness principle. With the former, interoperation depends on
specifications that capture all relevant details; whereas - as noted specifications that capture all relevant details, whereas
in Section 4.2 - interoperation in the latter depends more interoperation in the latter depends more extensively on
extensively on implementations making compatible decisions. implementations making compatible decisions, as noted in Section 4.2.
3. Applicability 3. Applicability
The guidance in this document is intended for protocols that are The guidance in this document is intended for protocols that are
deployed to the Internet. There are some situations in which this deployed to the Internet. There are some situations in which this
guidance might not apply to a protocol due to conditions on its guidance might not apply to a protocol due to conditions on its
implementation or deployment. implementation or deployment.
In particular, this guidance depends on an ability to update and In particular, this guidance depends on an ability to update and
deploy implementations. Being able to rapidly update implementations deploy implementations. Being able to rapidly update implementations
that are deployed to the Internet helps managing security risk but in that are deployed to the Internet helps manage security risks, but in
reality some software deployments have lifecycles that make software reality, some software deployments have lifecycles that make software
updates either rare or altogether impossible. updates either rare or altogether impossible.
Where implementations are not updated, there is no opportunity to Where implementations are not updated, there is no opportunity to
apply the practices that this document recommends. In particular, apply the practices that this document recommends. In particular,
some practices - such as those described in Section 5.1 - only exist some practices -- such as those described in Section 5.1 -- only
to support the development of protocol maintenance and evolution. exist to support the development of protocol maintenance and
Employing this guidance is therefore only applicable where there is evolution. Employing this guidance is therefore only applicable
the possibility of improving deployments through timely updates of where there is the possibility of improving deployments through
their implementations. timely updates of their implementations.
4. Harmful Consequences of Tolerating the Unexpected 4. Harmful Consequences of Tolerating the Unexpected
Problems in other implementations can create an unavoidable need to Problems in other implementations can create an unavoidable need to
temporarily tolerate unexpected inputs. However, this course of temporarily tolerate unexpected inputs. However, this course of
action carries risks. action carries risks.
4.1. Protocol Decay 4.1. Protocol Decay
Tolerating unexpected input might be an expedient tool for systems in Tolerating unexpected input might be an expedient tool for systems in
early phases of deployment, such as was the case for the early early phases of deployment, which was the case for the early
Internet. Being lenient in this way defers the effort of dealing Internet. Being lenient in this way defers the effort of dealing
with interoperability problems and prioritizes progress. However, with interoperability problems and prioritizes progress. However,
this deferral can amplify the ultimate cost of handling this deferral can amplify the ultimate cost of handling
interoperability problems. interoperability problems.
Divergent implementations of a specification emerge over time. When Divergent implementations of a specification emerge over time. When
variations occur in the interpretation or expression of semantic variations occur in the interpretation or expression of semantic
components, implementations cease to be perfectly interoperable. components, implementations cease to be perfectly interoperable.
Implementation bugs are often identified as the cause of variation, Implementation bugs are often identified as the cause of variation,
though it is often a combination of factors. Using a protocol in though it is often a combination of factors. Using a protocol in
ways that were not anticipated in the original design, or ambiguities ways that were not anticipated in the original design or ambiguities
and errors in the specification are often contributing factors. and errors in the specification are often contributing factors.
Disagreements on the interpretation of specifications should be Disagreements on the interpretation of specifications should be
expected over the lifetime of a protocol. expected over the lifetime of a protocol.
Even with the best intentions to maintain protocol correctness, the Even with the best intentions to maintain protocol correctness, the
pressure to interoperate can be significant. No implementation can pressure to interoperate can be significant. No implementation can
hope to avoid having to trade correctness for interoperability hope to avoid having to trade correctness for interoperability
indefinitely. indefinitely.
An implementation that reacts to variations in the manner recommended An implementation that reacts to variations in the manner recommended
in the robustness principle enters a pathological feedback cycle. in the robustness principle enters a pathological feedback cycle.
Over time: Over time:
* Implementations progressively add logic to constrain how data is * Implementations progressively add logic to constrain how data is
transmitted, or to permit variations in what is received. transmitted or to permit variations in what is received.
* Errors in implementations or confusion about semantics are * Errors in implementations or confusion about semantics are
permitted or ignored. permitted or ignored.
* These errors can become entrenched, forcing other implementations * These errors can become entrenched, forcing other implementations
to be tolerant of those errors. to be tolerant of those errors.
A flaw can become entrenched as a de facto standard. Any A flaw can become entrenched as a de facto standard. Any
implementation of the protocol is required to replicate the aberrant implementation of the protocol is required to replicate the aberrant
behavior, or it is not interoperable. This is both a consequence of behavior, or it is not interoperable. This is both a consequence of
tolerating the unexpected, and a product of a natural reluctance to tolerating the unexpected and a product of a natural reluctance to
avoid fatal error conditions. Ensuring interoperability in this avoid fatal error conditions. Ensuring interoperability in this
environment is often referred to as aiming to be "bug for bug environment is often referred to as aiming to be "bug-for-bug
compatible". compatible".
For example, in TLS [TLS], extensions use a tag-length-value format For example, in TLS [TLS], extensions use a tag-length-value format
and can be added to messages in any order. However, some server and can be added to messages in any order. However, some server
implementations terminated connections if they encountered a TLS implementations terminated connections if they encountered a TLS
ClientHello message that ends with an empty extension. To maintain ClientHello message that ends with an empty extension. To maintain
interoperability with these servers, which were widely deployed, interoperability with these servers, which were widely deployed,
client implementations were required to be aware of this bug and client implementations were required to be aware of this bug and
ensure that a ClientHello message ends in a non-empty extension. ensure that a ClientHello message ends in a non-empty extension.
Overapplication of the robustness principle therefore encourages a Overapplication of the robustness principle therefore encourages a
chain reaction that can create interoperability problems over time. chain reaction that can create interoperability problems over time.
In particular, tolerating unexpected behavior is particularly In particular, tolerating unexpected behavior is particularly
deleterious for early implementations of new protocols as quirks in deleterious for early implementations of new protocols, as quirks in
early implementations can affect all subsequent deployments. early implementations can affect all subsequent deployments.
4.2. Ecosystem Effects 4.2. Ecosystem Effects
From observing widely deployed protocols, it appears there are two From observing widely deployed protocols, it appears there are two
stable points on the spectrum between being strict versus permissive stable points on the spectrum between being strict versus permissive
in the presence of protocol errors: in the presence of protocol errors:
* If implementations predominantly enforce strict compliance with * If implementations predominantly enforce strict compliance with
specifications, newer implementations will experience failures if specifications, newer implementations will experience failures if
they do not comply with protocol requirements. Newer they do not comply with protocol requirements. Newer
implementations need to fix compliance issues in order to be implementations need to fix compliance issues in order to be
successfully deployed. This ensures that most deployments are successfully deployed. This ensures that most deployments are
compliant over time. compliant over time.
* Conversely, if non-compliance is tolerated by existing * Conversely, if non-compliance is tolerated by existing
implementations, non-compliant implementations can be deployed implementations, non-compliant implementations can be deployed
successfully. Newer implementations then have strong incentive to successfully. Newer implementations then have a strong incentive
tolerate any existing non-compliance in order to be successfully to tolerate any existing non-compliance in order to be
deployed. This ensures that most deployments are tolerant of the successfully deployed. This ensures that most deployments are
same non-compliant behavior. tolerant of the same non-compliant behavior.
This happens because interoperability requirements for protocol This happens because interoperability requirements for protocol
implementations are set by other deployments. Specifications and implementations are set by other deployments. Specifications and
test suites - where they exist - can guide the initial development of test suites -- where they exist -- can guide the initial development
implementations. Ultimately, the need to interoperate with deployed of implementations. Ultimately, the need to interoperate with
implementations is a de facto conformance test suite that can deployed implementations is a de facto conformance test suite that
supersede any formal protocol definition. can supersede any formal protocol definition.
For widely used protocols, the massive scale of the Internet makes For widely used protocols, the massive scale of the Internet makes
large-scale interoperability testing infeasible for all but a large-scale interoperability testing infeasible for all but a
privileged few. The cost of building a new implementation using privileged few. The cost of building a new implementation using
reverse engineering increases as the number of implementations and reverse engineering increases as the number of implementations and
bugs increases. Worse, the set of tweaks necessary for wide bugs increases. Worse, the set of tweaks necessary for wide
interoperability can be difficult to discover. In the worst case, a interoperability can be difficult to discover. In the worst case, a
new implementer might have to choose between deployments that have new implementer might have to choose between deployments that have
diverged so far as to no longer be interoperable. diverged so far as to no longer be interoperable.
skipping to change at page 10, line 9 skipping to change at line 404
This has a negative impact on the ecosystem of a protocol. New This has a negative impact on the ecosystem of a protocol. New
implementations are key to the continued viability of a protocol. implementations are key to the continued viability of a protocol.
New protocol implementations are also more likely to be developed for New protocol implementations are also more likely to be developed for
new and diverse use cases and are often the origin of features and new and diverse use cases and are often the origin of features and
capabilities that can be of benefit to existing users. capabilities that can be of benefit to existing users.
The need to work around interoperability problems also reduces the The need to work around interoperability problems also reduces the
ability of established implementations to change. An accumulation of ability of established implementations to change. An accumulation of
mitigations for interoperability issues makes implementations more mitigations for interoperability issues makes implementations more
difficult to maintain and can constrain extensibility (see also the difficult to maintain and can constrain extensibility (see also the
IAB document on the Long-Term Viability of Protocol Extension IAB document "Long-Term Viability of Protocol Extension Mechanisms"
Mechanisms [RFC9170]). [RFC9170]).
Sometimes what appear to be interoperability problems are symptomatic Sometimes, what appear to be interoperability problems are
of issues in protocol design. A community that is willing to make symptomatic of issues in protocol design. A community that is
changes to the protocol, by revising or extending specifications and willing to make changes to the protocol, by revising or extending
then deploying those changes, makes the protocol better. Tolerating specifications and then deploying those changes, makes the protocol
unexpected input instead conceals problems, making it harder, if not better. Tolerating unexpected input instead conceals problems,
impossible, to fix them later. making it harder, if not impossible, to fix them later.
5. Active Protocol Maintenance 5. Active Protocol Maintenance
The robustness principle can be highly effective in safeguarding The robustness principle can be highly effective in safeguarding
against flaws in the implementation of a protocol by peers. against flaws in the implementation of a protocol by peers.
Especially when a specification remains unchanged for an extended Especially when a specification remains unchanged for an extended
period of time, incentive to be tolerant of errors accumulates over period of time, the incentive to be tolerant of errors accumulates
time. Indeed, when faced with divergent interpretations of an over time. Indeed, when faced with divergent interpretations of an
immutable specification, the only way for an implementation to remain 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 implementation errors. However, when official specifications fail to
be updated then deployed implementations - including their quirks - be updated, then deployed implementations -- including their quirks
often become a substitute standard. -- often become a substitute standard.
Tolerating unexpected inputs from another implementation might seem Tolerating unexpected inputs from another implementation might seem
logical, even necessary. But that conclusion relies on an assumption logical, even necessary. However, that conclusion relies on an
that existing specifications and implementations cannot change. assumption that existing specifications and implementations cannot
Applying the robustness principle in this way disproportionately change. Applying the robustness principle in this way
values short-term gains over the negative effects on future disproportionately values short-term gains over the negative effects
implementations and the protocol as a whole. on future implementations and the protocol as a whole.
For a protocol to have sustained viability, it is necessary for both For a protocol to have sustained viability, it is necessary for both
specifications and implementations to be responsive to changes, in specifications and implementations to be responsive to changes, in
addition to handling new and old problems that might arise over time. addition to handling new and old problems that might arise over time.
For example, when an implementer discovers a scenario where a For example, when an implementer discovers a scenario where a
specification defines some input as faulty but does not define how to specification defines some input as faulty but does not define how to
handle that input, the implementer can provide significant value to handle that input, the implementer can provide significant value to
the ecosystem by reporting the issue and helping evolve the the ecosystem by reporting the issue and helping to evolve the
specification. specification.
When a discrepancy is found between a specification and its When a discrepancy is found between a specification and its
implementation, a maintenance discussion inside the standards process implementation, a maintenance discussion inside the standards process
allows reaching consensus on how best to evolve the specification. allows reaching consensus on how best to evolve the specification.
Subsequently updating implementations to match evolved specifications Subsequently, updating implementations to match evolved
ensures that implementations are consistently interoperable and specifications ensures that implementations are consistently
removes needless barriers for new implementations. Maintenance also interoperable and removes needless barriers for new implementations.
enables continued improvement of the protocol. New use cases are an Maintenance also enables continued improvement of the protocol. New
indicator that the protocol could be successful [RFC5218]. use cases are an indicator that the protocol could be successful
[RFC5218].
Protocol designers are strongly encouraged to continue to maintain Protocol designers are strongly encouraged to continue to maintain
and evolve protocol specifications beyond their initial inception and and evolve protocol specifications beyond their initial inception and
definition. This might require the development of revised definition. This might require the development of revised
specifications, extensions, or other supporting material that evolves specifications, extensions, or other supporting material that evolves
in concert with implementations. Involvement of those who implement in concert with implementations. Involvement of those who implement
and deploy the protocol is a critical part of this process, as they and deploy the protocol is a critical part of this process, as they
provide input on their experience with how the protocol is used. provide input on their experience with how the protocol is used.
Most interoperability problems do not require revision of protocols Most interoperability problems do not require revision of protocols
or protocol specifications, as software defects can happen even when or protocol specifications, as software defects can happen even when
the specification is unambiguous. For instance, the most effective the specification is unambiguous. For instance, the most effective
means of dealing with a defective implementation in a peer could be means of dealing with a defective implementation in a peer could be
to contact the developer responsible. It is far more efficient in to contact the developer responsible. It is far more efficient in
the long term to fix one isolated bug than it is to deal with the the long term to fix one isolated bug than it is to deal with the
consequences of workarounds. consequences of workarounds.
Early implementations of protocols have a stronger obligation to Early implementations of protocols have a stronger obligation to
closely follow specifications as their behavior will affect all closely follow specifications, as their behavior will affect all
subsequent implementations. In addition to specifications, later subsequent implementations. In addition to specifications, later
implementations will be guided by what existing deployments accept. implementations will be guided by what existing deployments accept.
Tolerance of errors in early deployments is most likely to result in Tolerance of errors in early deployments is most likely to result in
problems. Protocol specifications might need more frequent revision problems. Protocol specifications might need more frequent revision
during early deployments to capture feedback from early rounds of during early deployments to capture feedback from early rounds of
deployment. deployment.
Neglect can quickly produce the negative consequences this document Neglect can quickly produce the negative consequences this document
describes. Restoring the protocol to a state where it can be describes. Restoring the protocol to a state where it can be
maintained involves first discovering the properties of the protocol maintained involves first discovering the properties of the protocol
as it is deployed, rather than the protocol as it was originally as it is deployed rather than the protocol as it was originally
documented. This can be difficult and time-consuming, particularly documented. This can be difficult and time-consuming, particularly
if the protocol has a diverse set of implementations. Such a process if the protocol has a diverse set of implementations. Such a process
was undertaken for HTTP [HTTP] after a period of minimal maintenance. was undertaken for HTTP [HTTP] after a period of minimal maintenance.
Restoring HTTP specifications to relevance took significant effort. Restoring HTTP specifications to relevance took significant effort.
Maintenance is most effective if it is responsive, which is greatly Maintenance is most effective if it is responsive, which is greatly
affected by how rapidly protocol changes can be deployed. For affected by how rapidly protocol changes can be deployed. For
protocol deployments that operate on longer time scales, temporary protocol deployments that operate on longer time scales, temporary
workarounds following the spirit of the robustness principle might be workarounds following the spirit of the robustness principle might be
necessary. For this, improvements in software update mechanisms necessary. For this, improvements in software update mechanisms
skipping to change at page 12, line 35 skipping to change at line 517
of attempting error recovery can ensure that faults receive of attempting error recovery can ensure that faults receive
attention. This intolerance can be harnessed to reduce occurrences attention. This intolerance can be harnessed to reduce occurrences
of aberrant implementations. of aberrant implementations.
Intolerance toward violations of specification improves feedback for Intolerance toward violations of specification improves feedback for
new implementations in particular. When a new implementation new implementations in particular. When a new implementation
encounters a peer that is intolerant of an error, it receives strong encounters a peer that is intolerant of an error, it receives strong
feedback that allows the problem to be discovered quickly. feedback that allows the problem to be discovered quickly.
To be effective, intolerant implementations need to be sufficiently To be effective, intolerant implementations need to be sufficiently
widely deployed that they are encountered by new implementations with widely deployed so that they are encountered by new implementations
high probability. This could depend on multiple implementations with high probability. This could depend on multiple implementations
deploying strict checks. deploying strict checks.
Interoperability problems also need to be made known to those in a Interoperability problems also need to be made known to those in a
position to address them. In particular, systems with human position to address them. In particular, systems with human
operators, such as user-facing clients, are ideally suited to operators, such as user-facing clients, are ideally suited to
surfacing errors. Other systems might need to use less direct means surfacing errors. Other systems might need to use less direct means
of making errors known. of making errors known.
This does not mean that intolerance of errors in early deployments of This does not mean that intolerance of errors in early deployments of
protocols has the effect of preventing interoperability. On the protocols has the effect of preventing interoperability. On the
contrary, when existing implementations follow clearly-specified contrary, when existing implementations follow clearly specified
error handling, new implementations or features can be introduced error handling, new implementations or features can be introduced
more readily as the effect on existing implementations can be easily more readily, as the effect on existing implementations can be easily
predicted; see also Section 2.2. predicted; see also Section 2.2.
Any intolerance also needs to be strongly supported by Any intolerance also needs to be strongly supported by
specifications, otherwise they encourage fracturing of the protocol specifications; otherwise, they encourage fracturing of the protocol
community or proliferation of workarounds; see Section 5.2. community or proliferation of workarounds. See Section 5.2.
Intolerance can be used to motivate compliance with any protocol Intolerance can be used to motivate compliance with any protocol
requirement. For instance, the INADEQUATE_SECURITY error code and requirement. For instance, the INADEQUATE_SECURITY error code and
associated requirements in HTTP/2 [HTTP/2] resulted in improvements associated requirements in HTTP/2 [HTTP/2] resulted in improvements
in the security of the deployed base. in the security of the deployed base.
A notification for a fatal error is best sent as explicit error A notification for a fatal error is best sent as explicit error
messages to the entity that made the error. Error messages benefit messages to the entity that made the error. Error messages benefit
from being able to carry arbitrary information that might help the from being able to carry arbitrary information that might help the
implementer of the sender of the faulty input understand and fix the implementer of the sender of the faulty input understand and fix the
issue in their software. QUIC error frames [QUIC] are an example of issue in their software. QUIC error frames [QUIC] are an example of
a fatal error mechanism that helped implementers improve software a fatal error mechanism that helped implementers improve software
quality throughout the protocol lifecycle. Similarly, Extended DNS quality throughout the protocol lifecycle. Similarly, the use of
Errors [EDE] has recently been effective in providing better Extended DNS Errors [EDE] has been effective in providing better
descriptions of DNS resolution errors to clients. descriptions of DNS resolution errors to clients.
Stateless protocol endpoints might generate denial-of-service attacks Stateless protocol endpoints might generate denial-of-service attacks
if they send an error messages in response to every message that is if they send an error message in response to every message that is
received from an unauthenticated sender. These implementations might received from an unauthenticated sender. These implementations might
need to silently discard these messages. need to silently discard these messages.
5.2. Exclusion 5.2. Exclusion
Any protocol participant that is affected by changes arising from Any protocol participant that is affected by changes arising from
maintenance might be excluded if they are unwilling or unable to maintenance might be excluded if they are unwilling or unable to
implement or deploy changes that are made to the protocol. implement or deploy changes that are made to the protocol.
Deliberate exclusion of problematic implementations is an important Deliberate exclusion of problematic implementations is an important
tool that can ensure that the interoperability of a protocol remains tool that can ensure that the interoperability of a protocol remains
viable. While backward compatible changes are always preferable to viable. While backward-compatible changes are always preferable to
incompatible ones, it is not always possible to produce a design that incompatible ones, it is not always possible to produce a design that
protects the ability of all current and future protocol participants protects the ability of all current and future protocol participants
to interoperate. to interoperate.
Accidentally excluding unexpected participants is not usually a good Accidentally excluding unexpected participants is not usually a good
outcome. When developing and deploying changes, it is best to first outcome. When developing and deploying changes, it is best to first
understand the extent to which the change affects existing understand the extent to which the change affects existing
deployments. This ensures that any exclusion that occurs is deployments. This ensures that any exclusion that occurs is
intentional. intentional.
skipping to change at page 14, line 11 skipping to change at line 589
deployments to change, this might be considered necessary. To avoid deployments to change, this might be considered necessary. To avoid
unnecessarily excluding deployments that might take time to change, unnecessarily excluding deployments that might take time to change,
developing a migration plan can be prudent. developing a migration plan can be prudent.
Exclusion is a direct goal when choosing to be intolerant of errors Exclusion is a direct goal when choosing to be intolerant of errors
(see Section 5.1). Exclusionary actions are employed with the (see Section 5.1). Exclusionary actions are employed with the
deliberate intent of protecting future interoperability. deliberate intent of protecting future interoperability.
Excluding implementations or deployments can lead to a fracturing of Excluding implementations or deployments can lead to a fracturing of
the protocol system that could be more harmful than any divergence the protocol system that could be more harmful than any divergence
that might arise from tolerating the unexpected. The IAB document on that might arise from tolerating the unexpected. The IAB document
Uncoordinated Protocol Development Considered Harmful [RFC5704] "Uncoordinated Protocol Development Considered Harmful" [RFC5704]
describes how conflict or competition in the maintenance of protocols describes how conflict or competition in the maintenance of protocols
can lead to similar problems. can lead to similar problems.
6. Security Considerations 6. Security Considerations
Careless implementations, lax interpretations of specifications, and Careless implementations, lax interpretations of specifications, and
uncoordinated extrapolation of requirements to cover gaps in uncoordinated extrapolation of requirements to cover gaps in
specification can result in security problems. Hiding the specification can result in security problems. Hiding the
consequences of protocol variations encourages the hiding of issues, consequences of protocol variations encourages the hiding of issues,
which can conceal bugs and make them difficult to discover. which can conceal bugs and make them difficult to discover.
The consequences of the problems described in this document are The consequences of the problems described in this document are
especially acute for any protocol where security depends on agreement especially acute for any protocol where security depends on agreement
about semantics of protocol elements. For instance, use of unsafe about semantics of protocol elements. For instance, weak primitives
security mechanisms, such as weak primitives [MD5] or obsolete [MD5] and obsolete mechanisms [SSL3] are good examples of the use of
mechanisms [SSL3], are good examples of where forcing exclusion unsafe security practices where forcing exclusion (Section 5.2) can
(Section 5.2) can be desirable. be desirable.
7. IANA Considerations 7. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
8. Informative References 8. Informative References
[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/rfc/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[BGP-REH] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [BGP-REH] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/rfc/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[EDE] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. [EDE] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914, Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020, DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/rfc/rfc8914>. <https://www.rfc-editor.org/info/rfc8914>.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [EDNS0] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
RFC 2671, DOI 10.17487/RFC2671, August 1999, for DNS (EDNS(0))", STD 75, RFC 6891,
<https://www.rfc-editor.org/rfc/rfc2671>. DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design [EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012, DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/rfc/rfc6709>. <https://www.rfc-editor.org/info/rfc6709>.
[HTML] "HTML", WHATWG Living Standard, 8 March 2019, [HTML] WHATWG, "HTML - Living Standard",
<https://html.spec.whatwg.org/>. <https://html.spec.whatwg.org/>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, [HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022, DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>. <https://www.rfc-editor.org/info/rfc9113>.
[MD5] Turner, S. and L. Chen, "Updated Security Considerations [MD5] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/rfc/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760, [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760,
DOI 10.17487/RFC0760, January 1980, DOI 10.17487/RFC0760, January 1980,
<https://www.rfc-editor.org/rfc/rfc760>. <https://www.rfc-editor.org/info/rfc760>.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
<https://www.rfc-editor.org/rfc/rfc1958>. <https://www.rfc-editor.org/info/rfc1958>.
[RFC3117] Rose, M., "On the Design of Application Protocols", [RFC3117] Rose, M., "On the Design of Application Protocols",
RFC 3117, DOI 10.17487/RFC3117, November 2001, RFC 3117, DOI 10.17487/RFC3117, November 2001,
<https://www.rfc-editor.org/rfc/rfc3117>. <https://www.rfc-editor.org/info/rfc3117>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/rfc/rfc5218>. <https://www.rfc-editor.org/info/rfc5218>.
[RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated [RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated
Protocol Development Considered Harmful", RFC 5704, Protocol Development Considered Harmful", RFC 5704,
DOI 10.17487/RFC5704, November 2009, DOI 10.17487/RFC5704, November 2009,
<https://www.rfc-editor.org/rfc/rfc5704>. <https://www.rfc-editor.org/info/rfc5704>.
[RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol [RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170, Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
December 2021, <https://www.rfc-editor.org/rfc/rfc9170>. December 2021, <https://www.rfc-editor.org/info/rfc9170>.
[SSL3] Barnes, R., Thomson, M., Pironti, A., and A. Langley, [SSL3] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", RFC 7568, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
DOI 10.17487/RFC7568, June 2015, DOI 10.17487/RFC7568, June 2015,
<https://www.rfc-editor.org/rfc/rfc7568>. <https://www.rfc-editor.org/info/rfc7568>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
IAB Members at the Time of Approval IAB Members at the Time of Approval
Internet Architecture Board members at the time this document was Internet Architecture Board members at the time this document was
approved for publication were: approved for publication were:
* Jari Arkko Jari Arkko
Deborah Brungard
* Deborah Brungard Lars Eggert
Wes Hardaker
* Lars Eggert Cullen Jennings
Mallory Knodel
* Wes Hardaker Mirja Kühlewind
Zhenbin Li
* Cullen Jennings Tommy Pauly
David Schinazi
* Mallory Knodel Russ White
Qin Wu
* Mirja Kuehlewind Jiankang Yao
* Zhenbin Li
* Tommy Pauly
* David Schinazi
* Russ White
* Qin Wu
* Jiankang Yao
The document had broad but not unanimous approval within the IAB, The document had broad but not unanimous approval within the IAB,
reflecting that while the guidance is valid, concerns were expressed reflecting that while the guidance is valid, concerns were expressed
in the IETF community about how broadly it applies in all situations. in the IETF community about how broadly it applies in all situations.
Acknowledgments Acknowledgments
Constructive feedback on this document has been provided by a Constructive feedback on this document has been provided by a
surprising number of people including, but not limited to: Bernard surprising number of people including, but not limited to, the
Aboba, Brian Carpenter, Stuart Cheshire, Wes Hardaker, Joel Halpern, following: Bernard Aboba, Brian Carpenter, Stuart Cheshire, Joel
Russ Housley, Cullen Jennings, Mallory Knodel, Mirja Kühlewind, Mark Halpern, Wes Hardaker, Russ Housley, Cullen Jennings, Mallory Knodel,
Nottingham, Eric Rescorla, Henning Schulzrinne, Job Snijders, Robert Mirja Kühlewind, Mark Nottingham, Eric Rescorla, Henning Schulzrinne,
Sparks, Dave Thaler, Brian Trammell, and Anne van Kesteren. Some of Job Snijders, Robert Sparks, Dave Thaler, Brian Trammell, and Anne
the properties of protocols described in Section 4.1 were observed by van Kesteren. Some of the properties of protocols described in
Marshall Rose in Section 4.5 of [RFC3117]. Section 4.1 were observed by Marshall Rose in Section 4.5 of
[RFC3117].
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Email: mt@lowentropy.net Email: mt@lowentropy.net
David Schinazi David Schinazi
Email: dschinazi.ietf@gmail.com Email: dschinazi.ietf@gmail.com
 End of changes. 69 change blocks. 
193 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.48.