< draft-iab-protocol-maintenance-02.txt   draft-iab-protocol-maintenance-03.txt >
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational March 11, 2019 Intended status: Informational May 07, 2019
Expires: September 12, 2019 Expires: November 8, 2019
The Harmful Consequences of the Robustness Principle The Harmful Consequences of the Robustness Principle
draft-iab-protocol-maintenance-02 draft-iab-protocol-maintenance-03
Abstract Abstract
Jon Postel's famous statement of "Be liberal in what you accept, and Jon Postel's famous statement of "Be liberal in what you accept, and
conservative in what you send" is a principle that has long guided conservative in what you send" is a principle that has long guided
the design and implementation of Internet protocols. The posture the design and implementation of Internet protocols. The posture
this statement advocates promotes interoperability in the short term, this statement advocates promotes interoperability in the short term,
but can negatively affect the protocol ecosystem. For a protocol but can negatively affect the protocol ecosystem over time. For a
that is actively maintained, the Postel's robustness principle can, protocol that is actively maintained, the robustness principle can,
and should, be avoided. and should, be avoided.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on November 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Fallibility of Specifications . . . . . . . . . . . . . . . . 3 2. Fallibility of Specifications . . . . . . . . . . . . . . . . 3
3. Protocol Decay . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Decay . . . . . . . . . . . . . . . . . . . . . . . 4
4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 5 4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 5
5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 6 5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 6
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7
7. The Role of Feedback . . . . . . . . . . . . . . . . . . . . 8 7. The Role of Feedback . . . . . . . . . . . . . . . . . . . . 8
7.1. Feedback from Implementations . . . . . . . . . . . . . . 8 7.1. Feedback from Implementations . . . . . . . . . . . . . . 8
7.2. Virtuous Intolerance . . . . . . . . . . . . . . . . . . 8 7.2. Virtuous Intolerance . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Risk of Exclusion . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Informative References . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Informative References . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Of the great many contributions Jon Postel made to the Internet, his Jon Postel's robustness principle has been hugely influential in
remarkable technical achievements are often shadowed by his shaping the design of the Internet. As stated in IAB RFC 1958
contribution of a design and implementation philosophy known as the [PRINCIPLES], the robustness principle advises to:
robustness principle:
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 being the version of the text that appears in IAB RFC 1958 This simple statement captures a significant concept in the design of
[PRINCIPLES]. interoperable systems. Many consider the application of the
robustness principle to be instrumental in the success of the
Postel's robustness principle has been hugely influential in shaping Internet as well as the design of interoperable protocols in general.
the Internet and the systems that use Internet protocols. Many
consider the application of the robustness principle to be
instrumental in the success of the Internet as well as the design of
interoperable protocols in general.
Over time, considerable experience has been accumulated with
protocols that were designed by the application of Postel's maxim.
That experience shows that there are negative long-term consequences
to interoperability if an implementation applies Postel's advice.
The flaw in Postel's logic originates from the presumption of an Time and experience shows that negative consequences to
inability to affect change in a system the size of the Internet. interoperability accumulate over time if an implementations apply the
That is, once a protocol specification is published, changes that robustness principle. This problem originates from an assumption
might be different to the practice of existing implementations are implicit in the principle that it is not possible to affect change in
not feasible. a system the size of the Internet. That is, the idea that once a
protocol specification is published, changes that might require
existing implementations to change are not feasible.
Many of the shortcomings that lead to applications of the robustness Many problems that might lead to applications of the robustness
principle are avoided for protocols under active maintenance. Active principle are avoided for protocols under active maintenance. Active
protocol maintenance is where a community of protocol designers, protocol maintenance is where a community of protocol designers,
implementers, and deployers continuously improve and evolve implementers, and deployers work together to continuously improve and
protocols. A community that takes an active role in the maintenance evolve protocols. A community that takes an active role in the
of protocols can greatly reduce and even eliminate opportunities to maintenance of protocols can greatly reduce and even eliminate
apply Postel's guidance. opportunities to apply the robustness principle.
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. This document serves routinely maintained beyond their inception. This document serves
primarily as a record of the hazards inherent in applying the primarily as a record of the hazards inherent in applying the
robustness principle and to offer an alternative strategy for robustness principle and to offer an alternative strategy for
handling interoperability problems in deployments. handling interoperability problems in deployments.
Ideally, protocol implementations never have to apply the robustness Ideally, protocol implementations never have to apply the robustness
principle. Or, where it is unavoidable, any application can be principle. Or, where it is unavoidable, use of the robustness
principle is viewed as a short term workaround that needs to be
quickly reverted. quickly reverted.
2. Fallibility of Specifications 2. 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 (in RFC 760 [IP]) is preceded form of the principle in the RFC series (in RFC 760 [IP]) is preceded
by a sentence that reveals the motivation for the principle: by a sentence that reveals the 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.
Here Postel recognizes the possibility that the specification could Here Postel recognizes the possibility that the specification could
be imperfect. As a frank admission of fallibility it is a be imperfect. This contextualizes the principle in an important way.
significant statement. However, the same statement is inexplicably However, that context is inexplicably absent from the later versions
absent from the later versions in [HOSTS] and [PRINCIPLES]. in [HOSTS] and [PRINCIPLES].
An imperfect specification is natural, largely because it is more An imperfect specification is natural, 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, like any complex system, perfect a specification. A protocol, like any complex system,
benefits greatly from experience with its use. A deployed protocol benefits greatly from experience with its use. A deployed protocol
is immeasurably more useful than a perfect protocol. is immeasurably more useful than a perfect protocol. The robustness
principle is a tool that is suited to early phases of system design.
As [SUCCESS] demonstrates, success or failure of a protocol depends As [SUCCESS] demonstrates, success or failure of a protocol depends
far more on factors like usefulness than on on technical excellence. far more on factors like usefulness than on on technical excellence.
Postel's timely publication of protocol specifications, even with the Timely publication of protocol specifications, even with the
potential for flaws, likely had a significant effect in the eventual potential for flaws, likely contributed significantly to the eventual
success of the Internet. success of the Internet.
The problem is therefore not with the premise, but with its The problem is therefore not with the premise, but with its
conclusion: the robustness principle itself. conclusion: the robustness principle itself.
3. Protocol Decay 3. Protocol Decay
The application of the robustness principle to the early Internet, or
any system that is in early phases of deployment, is expedient. The
consequence of applying the principle is deferring the effort of
dealing with interoperability problems, which can amplify the
ultimate cost of handling those 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. Application of a though it is often a combination of factors. Application of a
protocol to new and unanticipated uses, and ambiguities or errors in protocol to uses that were not anticipated in the original design, or
the specification are often confounding factors. Situations where ambiguities and errors in the specification are often confounding
two peers disagree on interpretation should be expected over the factors. Disagreements on the interpretation of specifications
lifetime of a protocol. should be expected over the lifetime of a protocol.
Even with the best intentions, the pressure to interoperate can be Even with the best intentions, the pressure to interoperate can be
significant. No implementation can hope to avoid having to trade significant. No implementation can hope to avoid having to trade
correctness for interoperability indefinitely. correctness for interoperability indefinitely.
An implementation that reacts to variations in the manner advised by An implementation that reacts to variations in the manner recommended
Postel sets up a feedback cycle: in the robustness principle sets up a feedback cycle. Over time:
o Over time, implementations progressively add new code to constrain o Implementations progressively add logic to constrain how data is
how data is transmitted, or to permit variations in what is transmitted, or to permit variations in what is received.
received.
o Errors in implementations, or confusion about semantics can o Errors in implementations or confusion about semantics are
thereby be masked. permitted or ignored.
o These errors can become entrenched, forcing other implementations o 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
applying Postel's advice, and a product of a natural reluctance to applying the robustness principle, and a product of a natural
avoid fatal error conditions. Ensuring interoperability in this reluctance to avoid fatal error conditions. Ensuring
environment is often colloquially referred to as aiming to be "bug interoperability in this environment is often referred to as aiming
for bug compatible". to be "bug for bug 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 they can be added to messages in any order. However, some server and they can be added to messages in any order. However, some server
implementations terminate connections if they encounter a TLS implementations terminate connections if they encounter a TLS
ClientHello message that ends with an empty extension. To maintain ClientHello message that ends with an empty extension. To maintain
interoperability, client implementations are required to be aware of interoperability, client implementations are required to be aware of
this bug and ensure that a ClientHello message ends in a non-empty this bug and ensure that a ClientHello message ends in a non-empty
extension. extension.
The original JSON specification [JSON] demonstrates the effect of The original JSON specification [JSON] demonstrates the effect of
skipping to change at page 5, line 43 skipping to change at page 5, line 40
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 increases privileged few. The cost of building a new implementation increases
as the number of implementations and bugs increases. Worse, the set as the number of implementations and bugs increases. Worse, the set
of tweaks necessary for wide interoperability can be difficult to of tweaks necessary for wide interoperability can be difficult to
discover. discover.
Consequently, new implementations can be restricted to niche uses, Consequently, new implementations can be restricted to niche uses,
where the problems arising from interoperability issues can be more where the problems arising from interoperability issues can be more
closely managed. Restricting new implementations to narrow contexts closely managed. However, restricting new implementations into
also risks causing forks in the protocol. If implementations do not limited deployments risks causing forks in the protocol. If
interoperate, little prevents those implementations from diverging implementations do not interoperate, little prevents those
more over time. implementations from diverging more over time.
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 important in ensuring the continued viability of implementations are important in ensuring the continued viability of
a protocol. New protocol implementations are also more likely to be a protocol. New protocol implementations are also more likely to be
developed for new and diverse use cases and often are the origin of developed for new and diverse use cases and often are the origin of
features and capabilities that can be of benefit to existing users. features and 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. For instance, an ability of established implementations to change. An accumulation of
accumulation of mitigations for interoperability issues makes mitigations for interoperability issues makes implementations more
implementations more difficult to maintain. difficult to maintain and can constrain extensibility (see also
[USE-IT]).
Sometimes what appear to be interoperability problems are symptomatic Sometimes what appear to be interoperability problems are symptomatic
of issues in protocol design. A community that is willing to make of issues in protocol design. A community that is willing to make
changes to the protocol, by revising or extending it, makes the changes to the protocol, by revising or extending it, makes the
protocol better in the process. Applying the robustness principle protocol better in the process. Applying the robustness principle
might conceal the problem. That can make it harder, or even instead conceals problems, making it harder, or even impossible, to
impossible, to fix later. fix them later.
A similar class of problems is described in RFC 5704 [UNCOORDINATED],
which addresses conflict or competition in the maintenance of
protocols. This document concerns itself primarily with the absence
of maintenance, though the problems are similar.
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, the inclination to be tolerant accumulates over time. period of time, the inclination to be tolerant accumulates over time.
Indeed, when faced with divergent interpretations of an immutable Indeed, when faced with divergent interpretations of an immutable
specification, the best way for an implementation to remain specification, the best 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
an occasional outright implementation error. implementation errors.
From this perspective, application of Postel's advice to the From this perspective, application of the robustness principle to the
implementation of a protocol specification that does not change is implementation of a protocol specification that does not change is
logical, even necessary. But that suggests that the problem is with logical, even necessary. But that suggests that the problem is with
the assumption that the situation - existing specifications and the assumption that the situation - existing specifications and
implementations - are unable to change. implementations - are unable to change.
As already established, this is not sustainable. For a protocol to As established, this is not sustainable. For a protocol to be
be viable, it is necessary for both specifications and viable, it is necessary for both specifications and implementations
implementations to be responsive to changes, in addition to handling to be responsive to changes, in addition to handling new and old
new and old problems that might arise over time. problems that might arise over time.
Active maintenance of a protocol is critical in ensuring that Active maintenance of a protocol is critical in ensuring that
specifications correctly reflect the requirements for specifications correctly reflect the requirements for
interoperability. Maintenance enables both new implementations and interoperability. Maintenance enables both new implementations and
the continued improvement of the protocol. New use cases are an the continued improvement of the protocol. New use cases are an
indicator that the protocol could be successful [SUCCESS]. indicator that the protocol could be successful [SUCCESS].
Protocol designers are strongly encouraged to continue to maintain Protocol designers are strongly encouraged to continue to maintain
and evolve protocols beyond their initial inception and definition. and evolve protocols beyond their initial inception and definition.
Involvement of protocol implementers is a critical part of this Involvement of those who implement and deploy the protocol is a
process, as they provide input on their experience with critical part of this process, as they provide input on their
implementation and deployment of the protocol. 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. For instance, the most effective means or protocol specifications. For instance, the most effective means
of dealing with a defective implementation in a peer could be to of dealing with a defective implementation in a peer could be to
email the developer of the stack. It is far more efficient in the email the developer responsible. It is far more efficient in the
long term to fix one isolated bug than it is to deal with the long term to fix one isolated bug than it is to deal with the
consequences of workarounds. consequences of workarounds.
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.
skipping to change at page 7, line 37 skipping to change at page 7, line 35
deployed. deployed.
Extensibility is sometimes mistaken for an application of the Extensibility is sometimes mistaken for an application of the
robustness principle. After all, if one party wants to start using a robustness principle. After all, if one party wants to start using a
new feature before another party is prepared to receive it, it might new feature before another party is prepared to receive it, it might
be assumed that the receiving party is being tolerant of unexpected be assumed that the receiving party is being tolerant of unexpected
inputs. inputs.
A well-designed extensibility mechanism establishes clear rules for A well-designed extensibility mechanism establishes clear rules for
the handling of things like new messages or parameters. If an the handling of things like new messages or parameters. If an
extension mechanism is designed and implemented correctly, the user extension mechanism is designed and implemented correctly, new
of a new protocol feature can confidently predict the effect that protocol features can be deployed with confidence in the
feature will have on existing implementations. understanding of the effect they have on existing implementations.
Relying on implementations consistently applying the robustness In contrast, relying on implementations to consistently apply the
principle is not a good strategy for extensibility. Using robustness principle is not a good strategy for extensibility. Using
undocumented or accidental features of a protocol as the basis of an undocumented or accidental features of a protocol as the basis of an
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]. demonstrated by the case study in Appendix A.3 of [EXT].
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 allow a wide range of inputs as a core feature (see for or it could allow a wide range of inputs as a core feature (see for
example [HTML]). Specifying and implementing a more flexible example [HTML]). Specifying and implementing a more flexible
protocol is more difficult; allowing less variation is preferable in protocol is more difficult; allowing less variability is preferable
the absence of strong reasons to be flexible. in the absence of strong reasons to be flexible.
7. The Role of Feedback 7. The Role of Feedback
Protocol maintenance is only possible if there is sufficient Protocol maintenance is only possible if there is sufficient
information about the deployment of the protocol. Feedback from information about the deployment of the protocol. Feedback from
deployment is critical to effective protocol maintenance. deployment is critical to effective protocol maintenance.
For a protocol specification, the primary and most effective form of For a protocol specification, the primary and most effective form of
feedback comes from people who implement and deploy the protocol. feedback comes from people who implement and deploy the protocol.
This comes in the form of new requirements, or in experience with the This comes in the form of new requirements, or in experience with the
skipping to change at page 8, line 25 skipping to change at page 8, line 25
Managing and deploying changes to implementations can be expensive. Managing and deploying changes to implementations can be expensive.
However, it is widely recognized that regular updates are a vital However, it is widely recognized that regular updates are a vital
part of the deployment of computer systems for security reasons (see part of the deployment of computer systems for security reasons (see
for example [IOTSU]). for example [IOTSU]).
7.1. Feedback from Implementations 7.1. Feedback from Implementations
Automated error reporting mechanisms in protocol implementations Automated error reporting mechanisms in protocol implementations
allows for better feedback from deployments. Exposing faults through allows for better feedback from deployments. Exposing faults through
operations and management systems is highly valuable, but it might be operations and management interfaces is highly valuable, but it might
necessary to ensure that the information is propagated further. be necessary to ensure that the information is propagated further.
Building telemetry and error logging systems that report faults to Building telemetry and error logging systems that report faults to
the developers of the implementation is superior in many respects. the developers of the implementation is superior in many respects.
However, this is only possible in deployments that are conducive to However, this is only possible in deployments that are conducive to
the collection of this type of information. Giving due consideration the collection of this type of information. Giving due consideration
to protection of the privacy of protocol participants is critical to protection of the privacy of protocol participants is critical
prior to deploying any such system. prior to deploying any such system.
7.2. Virtuous Intolerance 7.2. Virtuous Intolerance
skipping to change at page 8, line 49 skipping to change at page 8, line 49
have interoperable handling of unusual conditions. have interoperable handling of unusual conditions.
Intolerance of any deviation from specification, where Intolerance of any deviation from specification, where
implementations generate fatal errors in response to observing implementations generate fatal errors in response to observing
undefined or unusal behaviour, can be harnessed to reduce occurrences undefined or unusal behaviour, can be harnessed to reduce occurrences
of aberrant implementations. Choosing to generate fatal errors for of aberrant implementations. Choosing to generate fatal errors for
unspecified conditions instead of attempting error recovery can unspecified conditions instead of attempting error recovery can
ensure that faults receive attention. ensure that faults receive attention.
This improves feedback for new implementations in particular. When a This improves feedback for new implementations in particular. When a
new implementation encounters a virtuously intolerant implementation, new implementation encounters an intolerant implementation, it
it receives strong feedback that allows problems to be discovered receives strong feedback that allows problems to be discovered
quickly. quickly.
To be effective, virtuously intolerant implementations need to be To be effective, intolerant implementations need to be sufficiently
sufficiently widely deployed that they are encountered by new widely deployed that they are encountered by new implementations with
implementations with high probability. This could depend on multiple high probability. This could depend on multiple implementations
implementations of strict checks. Any intolerance also needs to be deploying strict checks.
strongly supported by specifications, otherwise they encourage
fracturing of the protocol community or proliferation of workarounds.
Virtuous intolerance can be used to motivate compliance with any Any intolerance also needs to be strongly supported by
protocol requirement. For instance, the INADEQUATE_SECURITY error specifications, otherwise they encourage fracturing of the protocol
code and associated requirements in HTTP/2 [HTTP2] resulted in community or proliferation of workarounds (see Section 8).
improvements in the security of the deployed base.
8. Security Considerations Intolerance can be used to motivate compliance with any protocol
requirement. For instance, the INADEQUATE_SECURITY error code and
associated requirements in HTTP/2 [HTTP2] resulted in improvements in
the security of the deployed base.
8. Risk of Exclusion
Any protocol participant that is affected by changes arising from
maintenance might be excluded if they are unwilling or unable to
implement or deploy changes that are made to the protocol. RFC 5704
[UNCOORDINATED] describes how conflict or competition in the
maintenance of protocols can lead to the same sorts of problems.
The effect on existing systems is an important design criterion when
considering changes to a protocol. While compatible changes are
always preferable to incompatible ones, it is not always possible to
produce a design that allow all current protocol participants to
continue to participate.
Excluding implementations or deployments can lead to a fracturing of
the protocol system that could be more harmful than any divergence
resulting from following the robustness principle. Any change to a
protocol carries a risk of exclusion, but exclusion is a direct goal
when choosing to be intolerant of errors (see Section 7.2). Any
change that excludes implementations needs extraordinary care to
ensure that the effect on existing deployments is understood and
accepted.
9. Security Considerations
Sloppy implementations, lax interpretations of specifications, and Sloppy 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. about semantics of protocol elements.
9. IANA Considerations 10. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. Informative References 11. Informative References
[ECMA262] "ECMAScript(R) 2018 Language Specification", ECMA-262 9th [ECMA262] "ECMAScript(R) 2018 Language Specification", ECMA-262 9th
Edition, June 2018, <https://www.ecma- Edition, June 2018, <https://www.ecma-
international.org/publications/standards/Ecma-262.htm>. international.org/publications/standards/Ecma-262.htm>.
[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/info/rfc6709>. <https://www.rfc-editor.org/info/rfc6709>.
skipping to change at page 10, line 47 skipping to change at page 11, line 24
[PRINCIPLES] [PRINCIPLES]
Carpenter, B., Ed., "Architectural Principles of the 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/info/rfc1958>. <https://www.rfc-editor.org/info/rfc1958>.
[SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful [SUCCESS] 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/info/rfc5218>. <https://www.rfc-editor.org/info/rfc5218>.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
(TLS) Protocol Version 1.2", RFC 5246, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc8446>.
<https://www.rfc-editor.org/info/rfc5246>.
[UNCOORDINATED] [UNCOORDINATED]
Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated 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/info/rfc5704>. <https://www.rfc-editor.org/info/rfc5704>.
[USE-IT] Thomson, M., "Long-term Viability of Protocol Extension
Mechanisms", draft-thomson-use-it-or-lose-it-03 (work in
progress), January 2019.
Appendix A. Acknowledgments Appendix A. 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 Bernard Aboba, Brian Carpenter, surprising number of people including Bernard Aboba, Brian Carpenter,
Mark Nottingham, Russ Housley, Henning Schulzrinne, Robert Sparks, Mark Nottingham, Russ Housley, Henning Schulzrinne, Robert Sparks,
Brian Trammell, and Anne Van Kesteren. Please excuse any omission. Brian Trammell, and Anne Van Kesteren. Please excuse any omission.
Author's Address Author's Address
Martin Thomson Martin Thomson
 End of changes. 40 change blocks. 
110 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/