[RFCs/IDs] [Plain Text]


Network Working Group                                       R. Braden
Request for Comments: 1127                                        ISI
                                                         October 1989

              A Perspective on the Host Requirements RFCs

Status of This Memo

   This RFC is for information only; it does not constitute a standard,
   draft standard, or proposed standard, and it does not define a
   protocol.  Distribution of this memo is unlimited.


   This RFC contains an informal summary of the discussions and
   conclusions of the IETF Working Group on Host Requirements while it
   was preparing the Host Requirements RFCs.  This summary has several
   purposes: (1) to inform the community of host protocol issues that
   need further work; (2) to preserve some history and context as a
   starting point for future revision efforts; and (3) to provide some
   insight into the results of the Host Requirements effort.


   A working group of the Internet Engineering Task Force (IETF) has
   recently completed and published a monumental standards document on
   software requirements for Internet hosts [RFC-1122, RFC-1123].  This
   document has been published as two RFC's: "Requirements for Internet
   Hosts -- Communication Layers", referred to here as "HR-CL", and
   "Requirements for Internet Hosts -- Application and Support",
   referred to here as "HR-AS".  Together, we refer to them as the Host
   Requirements RFCs, or "HR RFCs".

   Creation of the Host Requirements document required the dedicated
   efforts of about 20 Internet experts, with significant contributions
   from another 20.  The Host Requirements working group held 7 formal
   meetings over the past 20 months, and exchanged about 3 megabytes of
   electronic mail.  The HR RFCs went through approximate 20 distinct

   This group of people struggled with a broad range of issues in host
   implementations of the Internet protocols, attempting to reconcile
   theoretical and architectural concerns with the sometimes conflicting
   imperatives of the real world.  The present RFC recaps the results of
   this struggle, with the issues that were settled and those that
   remain for future work.  This exegesis has several goals:

Braden                                                          [Page 1]

RFC 1127           Perspective on Host Requirements         October 1989

   (1)  to give the Internet technical community some insight into the
        results of the host requirements effort;

   (2)  to inform the community of areas that need further work; and

   (3)  to preserve some history and context of the effort as a starting
        point for a future revision.


   The basic purpose of the Host Requirements RFCs is to define the
   requirements for Internet host software.  However, the document goes
   far beyond a simple prescription of requirements, to include:

   (a)  a bibliography of the documents essential to an implementor;

   (b)  corrections and updates to the original standards RFC's;

   (c)  material to fill gaps in the previous specifications;

   (d)  limitations on implementation choices, where appropriate;

   (e)  clarification of important issues and the intent of the
        protocols; and

   (f)  documentation of known solutions to recurring problems as well
        as implementation hints.

   Broadly speaking, the Host Requirements working group started from
   the following goals for Internet host software:

   (1)  Interoperability

   (2)  Extensibility

   (3)  Functionality

   (4)  Efficiency

   (5)  Architectural Purity

   Of these, interoperability was clearly preeminent, while
   architectural purity had the lowest priority.  It is more difficult
   to assign relative importance to extensibility, functionality, and
   efficiency, as it varied from one topic to another.

   At a more technical level, the working group pursued a set of general
   goals that included the following:

Braden                                                          [Page 2]

RFC 1127           Perspective on Host Requirements         October 1989

   *    Discourage hosts from unexpectedly acting as gateways.

   *    Discourage the use of bad IP addresses.

   *    Eliminate broadcast storms.

   *    Discourage gratuitous Address Mask Reply messages.

   *    Facilitate the use IP Type-of-Service for routing and queueing.

   *    Encourage implementations of IP multicasting.

   *    Encourage TCP connection robustness.

   *    Encourage (mandate!) implementation of known TCP performance

   *    Encourage user interfaces that support the full capabilities of
        the protocols.

   *    Encourage more complete implementations of FTP.

   *    Encourage robust mail delivery

   *    Discourage the sour