The Harmful Consequences of the Robustness Principle
draft-iab-protocol-maintenance-03

The information below is for an old version of the document
Document Type Active Internet-Draft
Last updated 2019-05-06
Replaces draft-thomson-postel-was-wrong
Stream IAB
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream IAB state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
Network Working Group                                         M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Informational                              May 07, 2019
Expires: November 8, 2019

          The Harmful Consequences of the Robustness Principle
                   draft-iab-protocol-maintenance-03

Abstract

   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
   the design and implementation of Internet protocols.  The posture
   this statement advocates promotes interoperability in the short term,
   but can negatively affect the protocol ecosystem over time.  For a
   protocol that is actively maintained, the robustness principle can,
   and should, be avoided.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 8, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Thomson                 Expires November 8, 2019                [Page 1]
Internet-Draft            Protocol Maintenance                  May 2019

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Fallibility of Specifications . . . . . . . . . . . . . . . .   3
   3.  Protocol Decay  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Active Protocol Maintenance . . . . . . . . . . . . . . . . .   6
   6.  Extensibility . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  The Role of Feedback  . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Feedback from Implementations . . . . . . . . . . . . . .   8
     7.2.  Virtuous Intolerance  . . . . . . . . . . . . . . . . . .   8
   8.  Risk of Exclusion . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   11. Informative References  . . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Jon Postel's robustness principle has been hugely influential in
   shaping the design of the Internet.  As stated in IAB RFC 1958
   [PRINCIPLES], the robustness principle advises to:

      Be strict when sending and tolerant when receiving.
      Implementations must follow specifications precisely when sending
      to the network, and tolerate faulty input from the network.  When
      in doubt, discard faulty input silently, without returning an
      error message unless this is required by the specification.

   This simple statement captures a significant concept in the design of
   interoperable systems.  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.

   Time and experience shows that negative consequences to
   interoperability accumulate over time if an implementations apply the
   robustness principle.  This problem originates from an assumption
   implicit in the principle that it is not possible to affect change in
   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 problems that might lead to applications of the robustness
   principle are avoided for protocols under active maintenance.  Active

Thomson                 Expires November 8, 2019                [Page 2]
Show full document text