doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc1140.txt b/doc/rfc/rfc1140.txt
new file mode 100644
index 0000000..b7ab120
--- /dev/null
+++ b/doc/rfc/rfc1140.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                          Internet Activities Board
+Request for Comments: 1140                             J. Postel, Editor
+Obsoletes: RFCs 1130,                                           May 1990
+          1100, 1083
+
+
+
+                    IAB OFFICIAL PROTOCOL STANDARDS
+
+
+Status of this Memo
+
+   This memo describes the state of standardization of protocols used in
+   the Internet as determined by the Internet Activities Board (IAB).
+   Distribution of this memo is unlimited.
+
+Table of Contents
+
+   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   1.  The Standardization Process  . . . . . . . . . . . . . . . . 2
+   2.  The Request for Comments Documents . . . . . . . . . . . . . 5
+   3.  Other Reference Documents  . . . . . . . . . . . . . . . . . 6
+   3.1.  Assigned Numbers . . . . . . . . . . . . . . . . . . . . . 6
+   3.2.  Annotated Internet Protocols . . . . . . . . . . . . . . . 6
+   3.3.  Gateway Requirements . . . . . . . . . . . . . . . . . . . 6
+   3.4.  Host Requirements  . . . . . . . . . . . . . . . . . . . . 6
+   3.5.  The MIL-STD Documents  . . . . . . . . . . . . . . . . . . 7
+   4.  Explanation of Terms . . . . . . . . . . . . . . . . . . . . 7
+   4.1.  Definitions of Protocol State  . . . . . . . . . . . . . . 8
+   4.1.1.  Standard Protocol  . . . . . . . . . . . . . . . . . . . 8
+   4.1.2.  Draft Standard Protocol  . . . . . . . . . . . . . . . . 9
+   4.1.3.  Proposed Standard Protocol . . . . . . . . . . . . . . . 9
+   4.1.4.  Experimental Protocol  . . . . . . . . . . . . . . . . . 9
+   4.1.5.  Historic Protocol  . . . . . . . . . . . . . . . . . . . 9
+   4.2.  Definitions of Protocol Status . . . . . . . . . . . . . . 9
+   4.2.1.  Required Protocol  . . . . . . . . . . . . . . . . . . . 9
+   4.2.2.  Recommended Protocol . . . . . . . . . . . . . . . . .  10
+   4.2.3.  Elective Protocol  . . . . . . . . . . . . . . . . . .  10
+   4.2.4.  Limited Use Protocol . . . . . . . . . . . . . . . . .  10
+   4.2.5.  Not Recommended Protocol . . . . . . . . . . . . . . .  10
+   5.  The Standards Track  . . . . . . . . . . . . . . . . . . .  10
+   5.1.  The RFC Processing Decision Table  . . . . . . . . . . .  10
+   5.2.  The Standards Track Diagram  . . . . . . . . . . . . . .  12
+   6.  The Protocols  . . . . . . . . . . . . . . . . . . . . . .  14
+   6.1.  Recent Changes . . . . . . . . . . . . . . . . . . . . .  14
+   6.1.1.  New RFCs . . . . . . . . . . . . . . . . . . . . . . .  14
+   6.1.2.  Other Changes  . . . . . . . . . . . . . . . . . . . .  17
+   6.2.  Standard Protocols . . . . . . . . . . . . . . . . . . .  18
+
+
+
+Internet Activities Board                                       [Page 1]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   6.3.  Network-Specific Standard Protocols  . . . . . . . . . .  19
+   6.4.  Draft Standard Protocol  . . . . . . . . . . . . . . . .  20
+   6.5.  Proposed Standard Protocol . . . . . . . . . . . . . . .  21
+   6.6.  Experimental Protocol  . . . . . . . . . . . . . . . . .  22
+   6.7.  Historic Protocol  . . . . . . . . . . . . . . . . . . .  22
+   7.  Contacts . . . . . . . . . . . . . . . . . . . . . . . . .  23
+   7.1.  IAB, IETF, and IRTF Contacts . . . . . . . . . . . . . .  23
+   7.1.1.  Internet Activities Board (IAB) Contact  . . . . . . .  23
+   7.1.2.  Internet Engineering Task Force (IETF) Contact . . . .  23
+   7.1.3.  Internet Research  Task Force (IETF) Contact . . . . .  24
+   7.2.  Internet Assigned Numbers Authority (IANA) Contact . . .  24
+   7.3.  Request for Comments Editor Contact  . . . . . . . . . .  25
+   7.4.  Network Information Center Contact . . . . . . . . . . .  25
+   7.5.  Other Sources for Requests for Comments  . . . . . . . .  26
+   7.5.1.  NSF Network Service Center (NNSC)  . . . . . . . . . .  26
+   7.5.2.  NSF Network Information Service (NIS)  . . . . . . . .  26
+   7.5.3.  CSNET Coordination and Information Center (CIC)  . . .  26
+   8.  Security Considerations  . . . . . . . . . . . . . . . . .  27
+   9.  Author's Address . . . . . . . . . . . . . . . . . . . . .  27
+
+Introduction
+
+   Discussion of the standardization process and the RFC document series
+   is presented first, then the explanation of the terms is presented,
+   the lists of protocols in each stage of standardization follows and
+   finally come pointers to references and contacts for further
+   information.
+
+   This memo is issued quarterly, please be sure the copy you are
+   reading is dated within the last three months.  Current copies may be
+   obtained from the Network Information Center or from the Internet
+   Assigned Numbers Authority (see the contact information at the end of
+   this memo).  Do not use this edition after 31-Aug-90.
+
+   See Section 6.1 for a description of recent changes.
+
+1.  The Standardization Process
+
+   The Internet Activities Board maintains this list of documents that
+   define standards for the Internet protocol suite (see RFC-1120 for an
+   explanation of the role and organization of the IAB and its
+   subsidiary groups, the Internet Engineering Task Force (IETF) and the
+   Internet Research Task Force (IRTF)).  The IAB provides these
+   standards with the goal of co-ordinating the evolution of the
+   Internet protocols; this co-ordination has become quite important as
+   the Internet protocols are increasingly in general commercial use.
+
+   The majority of Internet protocol development and standardization
+
+
+
+Internet Activities Board                                       [Page 2]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   activity takes place in the working groups of the Internet
+   Engineering Task Force.
+
+   Protocols which are to become standards in the Internet go through a
+   series of states (proposed standard, draft standard, and standard)
+   involving increasing amounts of scrutiny and experimental testing.
+   At each step, the Internet Engineering Steering Group (IESG) of the
+   IETF must make a recommendation for advancement of the protocol and
+   the IAB must ratify it.  If a recommendation is not ratified, the
+   protocol is remanded to the IETF for further work.
+
+   To allow time for the Internet community to consider and react to
+   standardization proposals, the IAB imposes a minimum delay of 4
+   months before a proposed standard can be advanced to a draft standard
+   and 6 months before a draft standard can be promoted to standard.
+
+   It is general IAB practice that no proposed standard can be promoted
+   to draft standard without at least two independent implementations
+   (and the recommendation of the IESG).  Promotion from draft standard
+   to standard generally requires operational experience and
+   demonstrated interoperability of two or more implementations (and the
+   recommendation of the IESG).
+
+   In cases where there is uncertainty as to the proper decision
+   concerning a protocol the IAB may convene a special review committee
+   consisting of experts from the IETF, IRTF and the IAB with the
+   purpose of recommending an explicit action to the IAB.
+
+   Advancement of a protocol to proposed standard is an important step
+   since it marks a protocol as a candidate for eventual standardization
+   (it puts the protocol "on the standards track").  Advancement to
+   draft standard is a major step which warns the community that, unless
+   major objections are raised or flaws are discovered, the protocol is
+   likely to be advanced to standard in six months.
+
+   Some protocols have been superseded by better ones or are otherwise
+   unused.  Such protocols are still documented in this memorandum with
+   the designation "historic".
+
+   Because the IAB believes it is useful to document the results of
+   early protocol research and development work, some of the RFCs
+   document protocols which are still in an experimental condition.  The
+   protocols are designated "experimental" in this memorandum.  They
+   appear in this report as a convenience to the community and not as
+   evidence of their standardization.
+
+   In addition to the working groups of the IETF, protocol development
+   and experimentation may take place as a result of the work of the
+
+
+
+Internet Activities Board                                       [Page 3]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   research groups of the Internet Research Task Force, or the work of
+   other individuals interested in Internet protocol development.  The
+   IAB encourages the documentation of such experimental work in the RFC
+   series, but none of this work is considered to be on the track for
+   standardization until the IESG has made a recommendation to advance
+   the protocol to the proposed standard state, and the IAB has approved
+   this step.
+
+   A few protocols have achieved widespread implementation without the
+   approval of the IESG and the IAB.  For example, some vendor protocols
+   have become very important to the Internet community even though they
+   have not been recommended by the IESG or ratified by the IAB.
+   However, the IAB strongly recommends that the IAB standards process
+   be used in the evolution of the protocol suite to maximize
+   interoperability (and to prevent incompatible protocol requirements
+   from arising).  The IAB reserves the use of the terms "standard",
+   "draft standard", and "proposed standard" in any RFC or other
+   publication of Internet protocols to only those protocols which the
+   IAB has approved.
+
+   In addition to a state (like "proposed standard") a protocol is also
+   assigned a status, or requirement level.  A protocol can be required,
+   meaning that all systems in the Internet must implement it.  For
+   example, the Internet Protocol (IP) is required.  A protocol may be
+   recommended, meaning that systems should implement this protocol.  A
+   protocol may be elective, meaning that systems may implement this
+   protocol; that is, if (and only if) the functionality of this
+   protocol is needed or useful for a system it must use this protocol
+   to provide the functionality.  A protocol may be termed limited use
+   or even not recommended if it is not intended to be generally
+   implemented; for example, experimental or historic protocols.
+
+   When a protocol is on the standards track, that is in the proposed
+   standard, draft standard, or standard state (see Section 5), the
+   status is the current status.  However, the IAB will also endeavor to
+   indicate the eventual status this protocol will have when the
+   standardization is completed.
+
+   The IAB realizes that a one word label is not sufficient to
+   characterize the implementation requirements for a protocol in all
+   situations.  In many cases, an additional paragraph about the status
+   will be provided, and in some cases reference will be made to
+   separate requirements documents.
+
+   Few protocols are required to be implemented in all systems.  This is
+   because there is such a variety of possible systems; for example,
+   gateways, terminal servers, workstations, multi-user hosts.  It is
+   not necessary for a gateway to implement TCP or the protocols that
+
+
+
+Internet Activities Board                                       [Page 4]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   use TCP (though it may be useful).  It is expected that general
+   purpose hosts will implement at least IP (including ICMP and IGMP),
+   TCP and UDP, Telnet, FTP, NTP, SMTP, Mail, and the Domain Name System
+   (DNS).
+
+2.  The Request for Comments Documents
+
+   The documents called Request for Comments (or RFCs) are the working
+   notes of the "Network Working Group", that is the Internet research
+   and development community.  A document in this series may be on
+   essentially any topic related to computer communication, and may be
+   anything from a meeting report to the specification of a standard.
+
+   Notice:
+
+      All standards are published as RFCs, but not all RFCs specify
+      standards.
+
+   Anyone can submit a document for publication as an RFC.  Submissions
+   must be made via electronic mail to the RFC Editor (see the contact
+   information at the end of this memo).
+
+   While RFCs are not refereed publications, they do receive technical
+   review from the task forces, individual technical experts, or the RFC
+   Editor, as appropriate.
+
+   The RFC series comprises a wide range of documents such as
+   informational documents of general interests to specifications of
+   standard Internet protocols.  In cases where submission is intended
+   to document a proposed standard, draft standard, or standard
+   protocol, the RFC Editor will publish the document only with the
+   approval of both the IESG and the IAB.  For documents describing
+   experimental work, the RFC Editor will typically request review
+   comments from the relevant IETF working group or IRTF research group
+   and provide those comments to the author prior to committing to
+   publication.  See Section 5.1 for more detail.
+
+   Once a document is assigned an RFC number and published, that RFC is
+   never revised or re-issued with the same number.  There is never a
+   question of having the most recent version of a particular RFC.
+   However, a protocol (such as File Transfer Protocol (FTP)) may be
+   improved and re-documented many times in several different RFCs.  It
+   is important to verify that you have the most recent RFC on a
+   particular protocol.  This "IAB Official Protocol Standards" memo is
+   the reference for determining the correct RFC to refer to for the
+   current specification of each protocol.
+
+   The RFCs are available from the Network Information Center at SRI
+
+
+
+Internet Activities Board                                       [Page 5]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   International, and a number of other sites.  For more information
+   about obtaining RFCs, see Sections 7.4 and 7.5.
+
+3.  Other Reference Documents
+
+   There are four other reference documents of interest in checking the
+   current status of protocol specifications and standardization.  These
+   are the Assigned Numbers, the Annotated Internet Protocols, the
+   Gateway Requirements, and the Host Requirements.  Note that these
+   documents are revised and updated at different times; in case of
+   differences between these documents, the most recent must prevail.
+
+   Also, one should be aware of the MIL-STD publications on IP, TCP,
+   Telnet, FTP, and SMTP.  These are described in Section 3.5.
+
+3.1.  Assigned Numbers
+
+   This document lists the assigned values of the parameters used in the
+   various protocols.  For example, IP protocol codes, TCP port numbers,
+   Telnet Option Codes, ARP hardware types, and Terminal Type names.
+   Assigned Numbers was most recently issued as RFC-1060.
+
+   Another document, Internet Numbers, lists the assigned IP network
+   numbers, and the autonomous system numbers.  Internet Numbers was
+   most recently issued as RFC-1117.
+
+3.2.  Annotated Internet Protocols
+
+   This document lists the protocols and describes any known problems
+   and ongoing experiments.  This document was most recently issued as
+   RFC-1011 under the title "Official Internet Protocols".
+
+3.3.  Gateway Requirements
+
+   This document reviews the specifications that apply to gateways and
+   supplies guidance and clarification for any ambiguities.  Gateway
+   Requirements is RFC-1009.  A working group of the IETF is actively
+   preparing a revision.
+
+3.4.  Host Requirements
+
+   This pair of documents reviews the specifications that apply to hosts
+   and supplies guidance and clarification for any ambiguities.  Host
+   Requirements was recently issued as RFC-1122 and RFC-1123.
+
+
+
+
+
+
+
+Internet Activities Board                                       [Page 6]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+3.5.  The MIL-STD Documents
+
+   The Internet community specifications for IP (RFC-791) and TCP (RFC-
+   793) and the DoD MIL-STD specifications are intended to describe
+   exactly the same protocols.  Any difference in the protocols
+   specified by these sets of documents should be reported to DCA and to
+   the IAB.  The RFCs and the MIL-STDs for IP and TCP differ in style
+   and level of detail.  It is strongly advised that the two sets of
+   documents be used together.
+
+   The IAB and the DoD MIL-STD specifications for the FTP, SMTP, and
+   Telnet protocols are essentially the same documents (RFCs 765, 821,
+   854).  The MIL-STD versions have been edited slightly.  Note that the
+   current Internet specification for FTP is RFC-959.
+
+          Internet Protocol (IP)                      MIL-STD-1777
+          Transmission Control Protocol (TCP)         MIL-STD-1778
+          File Transfer Protocol (FTP)                MIL-STD-1780
+          Simple Mail Transfer Protocol (SMTP)        MIL-STD-1781
+          Telnet Protocol and Options (TELNET)        MIL-STD-1782
+
+   These documents are available from the Naval Publications and Forms
+   Center.  Requests can be initiated by telephone, telegraph, or mail;
+   however, it is preferred that private industry use form DD1425, if
+   possible.  These five documents are included in the 1985 DDN Protocol
+   Handbook (available from the Network Information Center, see Section
+   7.4).
+
+          Naval Publications and Forms Center, Code 3015
+          5801 Tabor Ave
+          Philadelphia, PA 19120
+          Phone: 1-215-697-3321 (order tape)
+                 1-215-697-4834 (conversation)
+
+4.  Explanation of Terms
+
+   There are two independent categorization of protocols.  The first is
+   the STATE of standardization which is one of "standard", "draft
+   standard", "proposed standard", "experimental", or "historic".  The
+   second is the STATUS of this protocol which is one of "required",
+   "recommended", "elective", "limited use", or "not recommended".
+
+   The IAB notes that the status or requirement level is difficult to
+   portray in a one word label.  These status labels should be
+   considered only as an indication, and a further description should be
+   consulted.
+
+   When a protocol is advanced to proposed standard or draft standard,
+
+
+
+Internet Activities Board                                       [Page 7]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   it is labeled with a current status and when possible, the IAB also
+   notes the status that that protocol is expected to have when it
+   reaches the standard state.
+
+   At any given time a protocol is a cell of the following matrix.
+   Protocols are likely to be in cells in about the following
+   proportions (indicated by the relative number of Xs).  A new protocol
+   is most likely to start in the (proposed standard, elective) cell, or
+   the (experimental, not recommended) cell.
+
+                             S T A T U S
+                     Req   Rec   Ele   Lim   Not
+       S           +-----+-----+-----+-----+-----+
+           Std     |  X  | XXX | XXX |     |     |
+       T           +-----+-----+-----+-----+-----+
+           Draft   |  X  |  X  | XXX |     |     |
+       A           +-----+-----+-----+-----+-----+
+           Prop    |     |  X  | XXX |  X  |     |
+       T           +-----+-----+-----+-----+-----+
+           Expr    |     |     |  X  | XXX |  X  |
+       E           +-----+-----+-----+-----+-----+
+           Hist    |     |     |     |  X  | XXX |
+                   +-----+-----+-----+-----+-----+
+
+
+   What is a "system"?
+
+      Some protocols are particular to hosts and some to gateways; a few
+      protocols are used in both.  The definitions of the terms below
+      will refer to a "system" which is either a host or a gateway (or
+      both).  It should be clear from the context of the particular
+      protocol which types of systems are intended.
+
+4.1.  Definitions of Protocol State
+
+   There are two independent categorizations of protocols.  The first is
+   the STATE of standardization, which is one of "standard", "draft
+   standard", "proposed standard", "experimental", or "historic".
+
+   4.1.1.  Standard Protocol
+
+      The IAB has established this as an official standard protocol for
+      the Internet.  These are separated into two groups: (1) IP
+      protocol and above, protocols that apply to the whole Internet;
+      and (2) network-specific protocols, generally specifications of
+      how to do IP on particular types of networks.
+
+
+
+
+
+Internet Activities Board                                       [Page 8]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   4.1.2.  Draft Standard Protocol
+
+      The IAB is actively considering this protocol as a possible
+      Standard Protocol.  Substantial and widespread testing and comment
+      are desired.  Comments and test results should be submitted to the
+      IAB.  There is a possibility that changes will be made in a Draft
+      Standard Protocol before it becomes a Standard Protocol.
+
+   4.1.3.  Proposed Standard Protocol
+
+      These are protocol proposals that may be considered by the IAB for
+      standardization in the future.  Implementation and testing by
+      several groups is desirable.  Revision of the protocol
+      specification is likely.
+
+   4.1.4.  Experimental Protocol
+
+      A system should not implement an experimental protocol unless it
+      is participating in the experiment and has coordinated its use of
+      the protocol with the developer of the protocol.
+
+      Typically, experimental protocols are those that are developed as
+      part of an ongoing research project not related to an operational
+      service offering.  While they may be proposed as a service
+      protocol at a later stage, and thus become proposed standard,
+      draft standard, and then standard protocols, the designation of a
+      protocol as experimental may sometimes be meant to suggest that
+      the protocol, although perhaps mature, is not intended for
+      operational use.
+
+   4.1.5.  Historic Protocol
+
+      These are protocols that are unlikely to ever become standards in
+      the Internet either because they have been superseded by later
+      developments or due to lack of interest.
+
+4.2.  Definitions of Protocol Status
+
+      There are two independent categorizations of protocols.  The
+      second is the STATUS of this protocol which is one of "required",
+      "recommended", "elective", "limited use", or "not recommended".
+
+   4.2.1.  Required Protocol
+
+      A system must implement the required protocols.
+
+
+
+
+
+
+Internet Activities Board                                       [Page 9]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   4.2.2.  Recommended Protocol
+
+      A system should implement the recommended protocols.
+
+   4.2.3.  Elective Protocol
+
+      A system may or may not implement an elective protocol. The
+      general notion is that if you are going to do something like this,
+      you must do exactly this.  There may be several elective protocols
+      in a general area, for example, there are several electronic mail
+      protocols, and several routing protocols.
+
+   4.2.4.  Limited Use Protocol
+
+      These protocols are for use in limited circumstances.  This may be
+      because of their experimental state, specialized nature, limited
+      functionality, or historic state.
+
+   4.2.5.  Not Recommended Protocol
+
+      These protocols are not recommended for general use.  This may be
+      because of their limited functionality, specialized nature, or
+      experimental or historic state.
+
+5.  The Standards Track
+
+   This section discusses in more detail the procedures used by the RFC
+   Editor and the IAB in making decisions about the labeling and
+   publishing of protocols as standards.
+
+5.1.  The RFC Processing Decision Table
+
+   Here is the current decision table for processing submissions by RFC
+   Editor.  The processing depends on who submitted it, and the status
+   they want it to have.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                      [Page 10]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+      +==========================================================+
+      |++++++++++++++|               S O U R C E                 |
+      +==========================================================+
+      | Desired      |    IAB   |   IESG   |   IRSG   |  Other   |
+      | Status       |          |          |  or RG   |          |
+      +==========================================================+
+      |              |          |          |          |          |
+      | Full or      |  Publish |  Vote    |  Bogus   |  Bogus   |
+      | Draft        |   (1)    |   (3)    |   (2)    |   (2)    |
+      | Standard     |          |          |          |          |
+      |              |          |          |          |          |
+      +--------------+----------+----------+----------+----------+
+      |              |          |          |          |          |
+      |              |  Publish |  Vote    |  Refer   |  Refer   |
+      | Proposed     |   (1)    |   (3)    |   (4)    |   (4)    |
+      | Standard     |          |          |          |          |
+      |              |          |          |          |          |
+      +--------------+----------+----------+----------+----------+
+      |              |          |          |          |          |
+      |              |  Publish |  Notify  |  Notify  |  Notify  |
+      | Experimental |   (1)    |   (5)    |   (5)    |   (5)    |
+      | Protocol     |          |          |          |          |
+      |              |          |          |          |          |
+      +--------------+----------+----------+----------+----------+
+      |              |          |          |          |          |
+      | Information  |  Publish |Discretion|Discretion|Discretion|
+      | or Opinion   |   (1)    |   (6)    |   (6)    |   (6)    |
+      | Paper        |          |          |          |          |
+      |              |          |          |          |          |
+      +==========================================================+
+
+      (1) Publish.
+
+      (2) Bogus.  Inform the source of the rules.  RFCs specifying
+          Standard, or Draft Standard must come from the IAB, only.
+
+      (3) Vote by the IAB.  If approved then do Publish (1), else do
+          Refer (4).
+
+      (4) Refer to an Area Director for review by a WG.  Expect to see
+          the document again only after approval by the IESG and the
+          IAB.
+
+      (5) Notify both the IESG and IRSG.  If no protest in 1 week then
+          do Discretion (6), else do undefined.
+
+      (6) RFC Editor's discretion.  The RFC Editor decides if a review
+          is needed and if so by whom.  RFC Editor decides to publish or
+
+
+
+Internet Activities Board                                      [Page 11]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+          not.
+
+   Of course, in all cases the RFC Editor can request or make minor
+   changes for style, format, and presentation purposes.
+
+   The IESG has designated Greg Vaudreuil as its agent for forwarding
+   documents with IESG approval and for registering protest in response
+   to notifications (5) to the RFC Editor.  Documents from Area
+   Directors or Working Group Chairs may be considered in the same way
+   as documents from "other".
+
+5.2.  The Standards Track Diagram
+
+   There is a part of the STATUS and STATE categorization that is called
+   the standards track.  Actually, only the changes of state are
+   significant to the progression along the standards track, though the
+   status assignments may be changed as well.
+
+   The states illustrated by single line boxes are temporary states,
+   those illustrated by double line boxes are long term states.  A
+   protocol will normally be expected to remain in a temporary state for
+   several months (minimum four months for proposed standard, minimum
+   six months for draft standard).  A protocol may be in a long term
+   state for many years.
+
+   A protocol may enter the standards track only on the recommendation
+   of the IESG and by action of the IAB; and may move from one state to
+   another along the track only on the recommendation of the IESG and by
+   action of the IAB.  That is, it takes both the IESG and the IAB to
+   either start a protocol on the track or to move it along.
+
+   Generally, as the protocol enters the standards track a decision is
+   made as to the eventual STATUS (elective, recommended, or required)
+   the protocol will have, although a somewhat less stringent current
+   status may be assigned, and it then is placed in the the proposed
+   standard STATE with that status.  So the initial placement of a
+   protocol is into state 1.  At any time the STATUS decision may be
+   revisited.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                      [Page 12]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+         |
+         +<----------------------------------------------+
+         |                                               ^
+         V    0                                          |    4
+   +-----------+                                   +===========+
+   |   enter   |-->----------------+-------------->|experiment |
+   +-----------+                   |               +=====+=====+
+                                   |                     |
+                                   V    1                |
+                             +-----------+               V
+                             | proposed  |-------------->+
+                        +--->+-----+-----+               |
+                        |          |                     |
+                        |          V    2                |
+                        +<---+-----+-----+               V
+                             | draft std |-------------->+
+                        +--->+-----+-----+               |
+                        |          |                     |
+                        |          V    3                |
+                        +<---+=====+=====+               V
+                             | standard  |-------------->+
+                             +=====+=====+               |
+                                                         |
+                                                         V    5
+                                                   +=====+=====+
+                                                   | historic  |
+                                                   +===========+
+
+   The transition from proposed standard (1) to draft standard (2) can
+   only be by action of the IAB on the recommendation of the IESG and
+   only after the protocol has been proposed standard (1) for at least
+   four months.
+
+   The transition from draft standard (2) to standard (3) can only be by
+   action of the IAB on the recommendation of the IESG and only after
+   the protocol has been draft standard (2) for at least six months.
+
+   Occasionally, the decision may be that the protocol is not ready for
+   standardization and will be assigned to the experimental state (4).
+   This is off the standards track, and the protocol may be resubmitted
+   to enter the standards track after further work.  There are other
+   paths into the experimental and historic states that do not involve
+   IAB action.
+
+   Sometimes one protocol is replaced by another and thus becomes
+   historic, it may happen that a protocol on the standards track is in
+   a sense overtaken by another protocol (or other events) and becomes
+   historic (state 5).
+
+
+
+Internet Activities Board                                      [Page 13]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+6.  The Protocols
+
+   This section lists the standards in groups by protocol state.
+
+6.1.  Recent Changes
+
+6.1.1.  New RFCs:
+
+      1157 - Simple Network Management Protocol (SNMP)
+
+             Advanced to Recommended Standard protocol.  Replaces 1098.
+
+      1156 - Management Information Base (MIB)
+
+             Advanced to Recommended Standard protocol.  Replaces 1066.
+
+      1155 - Structure of Management Information (SMI)
+
+             Advanced to Recommended Standard protocol.  Replaces 1065.
+
+      1154 - Encoding Header Field for Internet Messages
+
+             This is a new Elective Experimental protocol.
+
+      1153 - Digest Message Format
+
+             This is a new Elective Experimental protocol.
+
+      1152 - Workshop Report: Internet Research Steering Group Workshop
+             on Very-High-Speed Networks
+
+             This is an information document and does not specify any
+             level of standard.
+
+      1151 - Version 2 of the Reliable Data Protocol (RDP)
+
+             This is an update to a Not-recommended Experimental
+             protocol.
+
+      1150 - FYI on FYI
+
+             This is an information document and does not specify any
+             level of standard.
+
+      1149 - A Standard for the Transmission of IP Datagrams on Avian
+             Carriers
+
+             This describes an implementation technique, and does not
+
+
+
+Internet Activities Board                                      [Page 14]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+             specify any level of standard.
+
+      1148 - Mapping between X.400(88) and RFC 822
+
+             This is a new Elective Experimental protocol (corrects
+             editing errors in 1138).
+
+      1147 - FYI on a Network Management Tool Catalog
+
+             This is an information document and does not specify any
+             level of standard.
+
+      1146 - TCP Alternative Checksum Options
+
+             This is a new Not-recommended Experimental protocol
+             (corrects editing errors in 1145).
+
+      1145 - TCP Alternate Checksum Options
+
+             This is a new Not-recommended Experimental protocol.
+
+      1144 - Compressing TCP/IP Headers for Low-Speed Serial Links
+
+             This is a new Elective Proposed Standard protocol.
+
+      1143 - The Q Method of Implementing TELNET Option Negotiation
+
+             This describes an implementation technique.
+
+      1142 - < not issued yet >
+
+      1141 - Incremental Updating of the Internet Checksum
+
+             This describes an implementation technique.
+
+      1140 - IAB Official Protocol Standards
+
+             This memo.
+
+      1139 - An Echo Function for ISO 8473
+
+             This is a new Elective Proposed Standard protocol.
+
+      1138 - Mapping between X.400(88) and RFC 822
+
+             This is a new Elective Experimental protocol (replaced by
+             1148).
+
+
+
+
+Internet Activities Board                                      [Page 15]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+      1137 - Mapping Between Full RFC 822 and RFC 822 with Restricted
+             Encoding
+
+             This is a new Elective Experimental protocol.
+
+      1136 - Administrative Domains and Routing Domains: A Model for
+             Routing in the Internet
+
+             This is a discussion document and does not specify any
+             level of standard.
+
+      1135 - The Helminthiasis of the Internet
+
+             This is a discussion document and does not specify any
+             level of standard.
+
+      1134 - The Point-to-Point Protocol: A Proposal for Multi-Protocol
+             Transmission of Datagrams Over Point-to-Point Links
+
+             This is a new Elective Proposed Standard protocol.
+
+      1133 - Routing between the NSFNET and the DDN
+
+             This is a discussion document and does not specify any
+             level of standard.
+
+      1132 - A Standard for the Transmission of 802.2 Packets over IPX
+             Networks
+
+             This is a new Elective Network-Specific Standard protocol,
+             that is, a full Standard for a network-specific situation.
+
+      1131 - The OSPF Specification
+
+             This is a new Elective Proposed Standard protocol.
+
+      1060 - Assigned Numbers
+
+             The status report on assigned numbers and protocol
+             parameters.
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                      [Page 16]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+6.1.2.  Other Changes:
+
+   The following are changes to protocols listed in the previous
+   edition.
+
+      1058 - Routing Information Protocol (RIP)
+
+             Advanced to Elective Draft Standard protocol.
+
+      1045 - Versatile Message Transaction Protocol (VMTP)
+
+             Moved to Elective Experimental protocol.
+
+      1006 - ISO Transport Service on top of the TCP (TP-TCP)
+
+             Advanced to Elective Draft Standard protocol.
+
+       996 - Statistics Server (STATSRV)
+
+             Moved to Not Recommended Historic protocol.
+
+       954 - WhoIs Protocol (NICNAME)
+
+             Advanced to Elective Draft Standard protocol.
+
+       937 - Post Office Protocol, Version 2 (POP2)
+
+             Moved to Not Recommended Historic protocol.
+
+       916 - Reliable Asynchronous Transfer Protocol (RATP)
+
+             Moved to Not Recommended Historic protocol.
+
+       914 - Thinwire Protocol (THINWIRE)
+
+             Moved to Not Recommended Historic protocol.
+
+       818 - Remote Telnet Service (RTELNET)
+
+             Moved to Not Recommended Historic protocol.
+
+       569 - Network Standard Text Editor (NETED)
+
+             Moved to Not Recommended Historic protocol.
+
+       407 - Remote Job Entry (RJE)
+
+             Moved to Not Recommended Historic protocol.
+
+
+
+Internet Activities Board                                      [Page 17]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+6.2.  Standard Protocols
+
+Protocol   Name                                      Status          RFC
+========   =====================================     ============== ====
+--------   Assigned Numbers                          Required       1060
+--------   Gateway Requirements                      Required       1009
+--------   Host Requirements - Communications        Required       1122
+--------   Host Requirements - Applications          Required       1123
+IP         Internet Protocol                         Required        791
+            as amended by:
+--------     IP Subnet Extension                     Required        950
+--------     IP Broadcast Datagrams                  Required        919
+--------     IP Broadcast Datagrams with Subnets     Required        922
+ICMP       Internet Control Message Protocol         Required        792
+IGMP       Internet Group Multicast Protocol         Recommended    1112
+UDP        User Datagram Protocol                    Recommended     768
+TCP        Transmission Control Protocol             Recommended     793
+SMI        Structure of Management Information       Recommended    1155
+MIB        Management Information Base               Recommended    1156
+SNMP       Simple Network Management Protocol        Recommended    1157
+DOMAIN     Domain Name System                     Recommended  1034,1035
+TELNET     Telnet Protocol                           Recommended     854
+FTP        File Transfer Protocol                    Recommended     959
+SMTP       Simple Mail Transfer Protocol             Recommended     821
+MAIL       Format of Electronic Mail Messages        Recommended     822
+CONTENT    Content Type Header Field                 Recommended    1049
+EGP        Exterior Gateway Protocol                 Recommended     904
+ECHO       Echo Protocol                             Recommended     862
+NTP        Network Time Protocol                     Recommended    1119
+NETBIOS    NetBIOS Service Protocols                 Elective  1001,1002
+DISCARD    Discard Protocol                          Elective        863
+CHARGEN    Character Generator Protocol              Elective        864
+QUOTE      Quote of the Day Protocol                 Elective        865
+USERS      Active Users Protocol                     Elective        866
+DAYTIME    Daytime Protocol                          Elective        867
+TIME       Time Server Protocol                      Elective        868
+
+Notes:
+
+   IGMP -- The Internet Activities Board intends to move towards general
+   adoption of IP multicasting, as a more efficient solution than
+   broadcasting for many applications.  The host interface has been
+   standardized in RFC-1112; however, multicast-routing gateways are in
+   the experimental stage and are not widely available.  An Internet
+   host should support all of RFC-1112, except for the IGMP protocol
+   itself which is optional; see RFC-1122 for more details.  Even
+   without IGMP, implementation of RFC-1112 will provide an important
+   advance: IP-layer access to local network multicast addressing.  It
+
+
+
+Internet Activities Board                                      [Page 18]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   is expected that IGMP will become recommended for all hosts and
+   gateways at some future date.
+
+   SMI, MIB, SNMP -- The Internet Activities Board recommends that all
+   IP and TCP implementations be network manageable.  This implies
+   implementation of the Internet MIB (RFC-1156) and at least one of the
+   two recommended management protocols SNMP (RFC-1157) or CMOT (RFC-
+   1095).  It should be noted that, at this time, SNMP is a full
+   Internet standard and CMOT is a draft standard.  See also the Host
+   and Gateway Requirements RFCs for more specific information on the
+   applicability of this standard.
+
+6.3.  Network-Specific Standard Protocols
+
+Protocol   Name                                     Status           RFC
+========   =====================================    =============== ====
+ARP        Address Resolution Protocol              Elective         826
+RARP       A Reverse Address Resolution Protocol    Elective         903
+IP-ARPA    Internet Protocol on ARPANET             Elective    BBN 1822
+IP-WB      Internet Protocol on Wideband Network    Elective         907
+IP-X25     Internet Protocol on X.25 Networks       Elective         877
+IP-E       Internet Protocol on Ethernet Networks   Elective         894
+IP-EE      Internet Protocol on Exp. Ethernet Nets  Elective         895
+IP-IEEE    Internet Protocol on IEEE 802            Elective        1042
+IP-DC      Internet Protocol on DC Networks         Elective         891
+IP-HC      Internet Protocol on Hyperchannel        Elective        1044
+IP-ARC     Internet Protocol on ARCNET              Elective        1051
+IP-SLIP    Transmission of IP over Serial Lines     Elective        1055
+IP-NETBIOS Transmission of IP over NETBIOS          Elective        1088
+IP-FDDI    Transmission of IP over FDDI             Elective        1103
+IP-IPX     Transmission of 802.2 over IPX Networks  Elective        1132
+
+Notes:
+
+   It is expected that a system will support one or more physical
+   networks and for each physical network supported the appropriate
+   protocols from the above list must be supported.  That is, it is
+   elective to support any particular type of physical network, and for
+   the physical networks actually supported it is required that they be
+   supported exactly according to the protocols in the above list.  See
+   also the Host and Gateway Requirements RFCs for more specific
+   information on network-specific ("link layer") protocols.
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                      [Page 19]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+6.4.  Draft Standard Protocols
+
+Protocol   Name                                     Status           RFC
+========   =====================================    =============== ====
+--------   Mail Privacy: Procedures                 Elective        1113
+--------   Mail Privacy: Key Management             Elective        1114
+--------   Mail Privacy: Algorithms                 Elective        1115
+CMOT       Common Management Information Services   Recommended     1095
+           and Protocol over TCP/IP
+BOOTP      Bootstrap Protocol                  Recommended 951,1048,1084
+RIP        Routing Information Protocol             Elective        1058
+TP-TCP     ISO Transport Service on top of the TCP  Elective        1006
+NICNAME    WhoIs Protocol                           Elective         954
+TFTP       Trivial File Transfer Protocol           Elective         783
+
+Notes:
+
+   CMOT -- The Internet Activities Board recommends that all IP and TCP
+   implementations be network manageable.  This implies implementation
+   of the Internet MIB (RFC-1156) and at least one of the two
+   recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
+   It should be noted that, at this time, SNMP is a full Internet
+   standard and CMOT is a draft standard.  See also the Host and Router
+   Requirements RFCs for more specific information on the applicability
+   of this standard.
+
+   RIP -- The Routing Information Protocol (RIP) is widely implemented
+   and used in the Internet.  However, both implementors and users
+   should be aware that RIP has some serious technical limitations as a
+   routing protocol.  The IETF is currently developing several
+   candidates for a new standard "open" routing protocol with better
+   properties than RIP.  The IAB urges the Internet community to track
+   these developments, and to implement the new protocol when it is
+   standardized; improved Internet service will result for many users.
+
+   TP-TCP -- As OSI protocols become more widely implemented and used,
+   there will be an increasing need to support interoperation with the
+   TCP/IP protocols.  The Internet Engineering Task Force is formulating
+   strategies for interoperation.  RFC-1006 provides one interoperation
+   mode, in which TCP/IP is used to emulate TP0 in order to support OSI
+   applications.  Hosts that wish to run OSI connection-oriented
+   applications in this mode should use the procedure described in RFC-
+   1006.  In the future, the IAB expects that a major portion of the
+   Internet will support both TCP/IP and OSI (inter-)network protocols
+   in parallel, and it will then be possible to run OSI applications
+   across the Internet using full OSI protocol "stacks".
+
+
+
+
+
+Internet Activities Board                                      [Page 20]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+6.5.  Proposed Standard Protocols
+
+Protocol   Name                                     Status           RFC
+========   =====================================    =============== ====
+MIB-II     MIB-II                                   Elective        xxxx
+IP-CMPRS   Compressing TCP/IP Headers               Elective        1144
+--------   Echo for ISO-8473                        Elective        1139
+PPP        Point to Point Protocol                  Elective        1134
+OSPF       Open Shortest Path First Routing         Elective        1131
+SUN-NFS    Network File System Protocol             Elective        1094
+POP3       Post Office Protocol, Version 3          Elective   1081,1082
+SUN-RPC    Remote Procedure Call Protocol           Elective        1057
+PCMAIL     Pcmail Transport Protocol                Elective        1056
+NFILE      A File Access Protocol                   Elective        1037
+--------   Mapping between X.400(84) and RFC-822    Elective    987,1026
+NNTP       Network News Transfer Protocol           Elective         977
+HOSTNAME   HOSTNAME Protocol                        Elective         953
+SFTP       Simple File Transfer Protocol            Elective         913
+RLP        Resource Location Protocol               Elective         887
+FINGER     Finger Protocol                          Elective         742
+SUPDUP     SUPDUP Protocol                          Elective         734
+
+Notes:
+
+   This section is being reviewed by the IESG, which will recommend that
+   some of these protocols be moved to either the draft standard, or the
+   experimental or historic categories.
+
+   MIB-II -- This memo defines a mandatory extension to the base MIB
+   (RFC-1156) and is a Proposed Standard for the Internet community.
+   The extensions described here are currently Elective, but when they
+   become a standard, they will have the same status as RFC-1156, that
+   is, Recommended.  The Internet Activities Board recommends that all
+   IP and TCP implementations be network manageable.  This implies
+   implementation of the Internet MIB (RFC-1156 and the extensions in
+   RFC-xxxx) and at least one of the two recommended management
+   protocols SNMP (RFC-1157) or CMOT (RFC-1095).
+
+   PPP -- Point to Point Protocol is a method of sending IP over serial
+   lines, which are a type of physical network.  It is expected that a
+   system will support one or more physical networks and for each
+   physical network supported the appropriate protocols from the
+   network-specific standard protocols (Section 6.3) must be supported.
+   That is, it is elective to support any particular type of physical
+   network, and for the physical networks actually supported it is
+   required that they be supported exactly according to the protocols
+   listed.  It is anticipated that PPP will be advanced to the network-
+   specific standard protocol state in the future.
+
+
+
+Internet Activities Board                                      [Page 21]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+6.6.  Experimental Protocols
+
+Protocol   Name                                     Status           RFC
+========   =====================================    =============== ====
+EHF-MAIL   Encoding Header Field for Mail           Elective        1154
+DMF-MAIL   Digest Message Format for Mail           Elective        1153
+RDP        Reliable Data Protocol                  Limited Use  908,1151
+--------   Mapping between X.400(88) and RFC-822    Elective        1148
+TCP-ACO    TCP Alternate Checksum Option            Not Recommended 1146
+--------   Mapping full 822 to Restricted 822       Elective        1137
+BGP        Border Gateway Protocol                  Limited Use     1105
+IP-DVMRP   IP Distance Vector Multicast Routing     Not Recommended 1075
+TCP-LDP    TCP Extensions for Long Delay Paths      Limited Use     1072
+IMAP2      Interactive Mail Access Protocol         Limited Use     1064
+IP-MTU     IP MTU Discovery Options                 Not Recommended 1063
+VMTP       Versatile Message Transaction Protocol   Elective        1045
+COOKIE-JAR Authentication Scheme                    Not Recommended 1004
+NETBLT     Bulk Data Transfer Protocol              Not Recommended  998
+IRTP       Internet Reliable Transaction Protocol   Not Recommended  938
+AUTH       Authentication Service                   Not Recommended  931
+LDP        Loader Debugger Protocol                 Not Recommended  909
+ST         Stream Protocol                          Limited Use  IEN-119
+NVP-II     Network Voice Protocol                   Limited Use ISI-memo
+PVP        Packet Video Protocol                    Limited Use ISI-memo
+
+6.7.  Historic Protocols
+
+Protocol   Name                                     Status           RFC
+=======    =====================================    =============== ====
+SGMP       Simple Gateway Monitoring Protocol       Not Recommended 1028
+HEMS       High Level Entity Management Protocol    Not Recommended 1021
+STATSRV    Statistics Server                        Not Recommended  996
+POP2       Post Office Protocol, Version 2          Not Recommended  937
+RATP       Reliable Asynchronous Transfer Protocol  Not Recommended  916
+THINWIRE   Thinwire Protocol                        Not Recommended  914
+HMP        Host Monitoring Protocol                 Not Recommended  869
+GGP        Gateway Gateway Protocol                 Not Recommended  823
+RTELNET    Remote Telnet Service                    Not Recommended  818
+CLOCK      DCNET Time Server Protocol               Not Recommended  778
+MPM        Internet Message Protocol                Not Recommended  759
+NETRJS     Remote Job Service                       Not Recommended  740
+NETED      Network Standard Text Editor             Not Recommended  569
+RJE        Remote Job Entry                         Not Recommended  407
+XNET       Cross Net Debugger                    Not Recommended IEN-158
+NAMESERVER Host Name Server Protocol             Not Recommended IEN-116
+MUX        Multiplexing Protocol                  Not Recommended IEN-90
+GRAPHICS   Graphics Protocol                   Not Recommended NIC-24308
+
+
+
+
+Internet Activities Board                                      [Page 22]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+7.  Contacts
+
+7.1.  IAB, IETF, and IRTF Contacts
+
+   7.1.1.  Internet Activities Board (IAB) Contact
+
+      Contact:
+
+         Bob Braden
+         Executive Director of the IAB
+         USC/Information Sciences Institute
+         4676 Admiralty Way
+         Marina del Rey, CA  90292-6695
+
+         1-213-822-1511
+
+         Braden@ISI.EDU
+
+   Please send your comments about this list of protocols and especially
+   about the Draft Standard Protocols to the Internet Activities Board
+   care of Bob Braden, IAB Executive Director.
+
+   7.1.2.  Internet Engineering Task Force (IETF) Contact
+
+      Contact:
+
+         Phill Gross
+         Chair of the IETF
+         Corporation for National Research Initiatives (NRI)
+         1895 Preston White Drive, Suite 100
+         Reston, VA 22091
+
+         1-703-620-8990
+
+         PGross@NRI.RESTON.VA.US
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                      [Page 23]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   7.1.3.  Internet Research Task Force (IRTF) Contact
+
+      Contact:
+
+         David D. Clark
+         Chair of the IRTF
+         Massachusetts Institute of Technology
+         Laboratory for Computer Science
+         545 Main Street
+         Cambridge, MA 02139
+
+         1-617-253-6003
+
+         ddc@LCS.MIT.EDU
+
+7.2.  Internet Assigned Numbers Authority Contact
+
+      Contact:
+
+         Joyce K. Reynolds
+         Internet Assigned Numbers Authority
+         USC/Information Sciences Institute
+         4676 Admiralty Way
+         Marina del Rey, CA  90292-6695
+
+         1-213-822-1511
+
+         IANA@ISI.EDU
+
+   The protocol standards are managed for the IAB by the Internet
+   Assigned Numbers Authority.
+
+   Please refer to the documents "Assigned Numbers" (RFC-1060) and
+   "Official Internet Protocols" (RFC-1011) for further information
+   about the status of protocol documents.  There are two documents that
+   summarize the requirements for host and gateways in the Internet,
+   "Host Requirements" (RFC-1122 and RFC-1123) and "Gateway
+   Requirements" (RFC-1009).
+
+      How to obtain the most recent edition of this "IAB Official
+      Protocol Standards" memo:
+
+         The file "in-notes/iab-standards.txt" may be copied via FTP
+         from the VENERA.ISI.EDU computer using the FTP username
+         "anonymous" and FTP password "guest".
+
+
+
+
+
+
+Internet Activities Board                                      [Page 24]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+7.3.  Request for Comments Editor Contact
+
+      Contact:
+
+         Jon Postel
+         RFC Editor
+         USC/Information Sciences Institute
+         4676 Admiralty Way
+         Marina del Rey, CA  90292-6695
+
+         1-213-822-1511
+
+         Postel@ISI.EDU
+
+   Documents may be submitted via electronic mail to the RFC Editor for
+   consideration for publication as RFC.  If you are not familiar with
+   the format or style requirements please request the "Instructions for
+   RFC Authors".  In general, the style of any recent RFC may be used as
+   a guide.
+
+7.4.  The Network Information Center and
+      Requests for Comments Distribution Contact
+
+      Contact:
+
+         DDN Network Information Center
+         SRI International
+         Room EJ291
+         333 Ravenswood Avenue
+         Menlo Park, CA  94025
+
+         1-800-235-3155
+         1-415-859-3695
+
+         NIC@NIC.DDN.MIL
+
+   The Network Information Center (NIC) provides many information
+   services for the Internet community.  Among them is maintaining the
+   Requests for Comments (RFC) library.
+
+   RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
+   RFC:RFCnnnn.TXT where "nnnn" refers to the number of the RFC.  A list
+   of all RFCs may be obtained by copying the file RFC:RFC-INDEX.TXT.
+   Log in with FTP username ANONYMOUS and password GUEST.
+
+   The NIC also provides an automatic mail service for those sites which
+   cannot use FTP.  Address the request to SERVICE@NIC.DDN.MIL and in
+   the subject field of the message indicate the file name, as in
+
+
+
+Internet Activities Board                                      [Page 25]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+   "Subject: SEND RFC:RFCnnnn.TXT".
+
+   Some RFCs are now available in PostScript, these may be obtained from
+   the NIC in a similar fashion by substituting ".PS" for ".TXT".
+
+      How to obtain the most recent edition of this "IAB Official
+      Protocol Standards" memo:
+
+         The file RFC:IAB-STANDARDS.TXT may be copied via FTP from the
+         NIC.DDN.MIL computer following the same procedures used to
+         obtain RFCs.
+
+7.5.  Other Sources for Requests for Comments
+
+   7.5.1.  NSF Network Service Center (NNSC)
+
+         NSF Network Service Center (NNSC)
+         BBN Laboratories, Inc.
+         10 Moulton St.
+         Cambridge, MA 02238
+
+         617-873-3400
+
+         NNSC@NNSC.NSF.NET
+
+   7.5.2.  NSF Network Information Service (NIS)
+
+         NSF Network Information Service
+         Merit Computer Network
+         University of Michigan
+         1075 Beal Avenue
+         Ann Arbor, MI 48109
+
+         313-763-4897
+
+         INFO@NIS.NSF.NET
+
+   7.5.3.  CSNET Coordination and Information Center (CIC)
+
+         CSNET Coordination and Information Center
+         BBN Systems and Technologies Corporation
+         10 Moulton Street
+         Cambridge, MA 02238
+
+         617-873-2777
+
+         INFO@SH.CS.NET
+
+
+
+
+Internet Activities Board                                      [Page 26]
+
+RFC 1140                     IAB Standards                      May 1990
+
+
+8.  Security Considerations
+
+   Security issues are not addressed in this memo.
+
+9.  Author's Address
+
+   Jon Postel
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292
+
+   Phone: (213) 822-1511
+
+   Email: Postel@ISI.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                      [Page 27]
+
\ No newline at end of file