summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1140.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1140.txt')
-rw-r--r--doc/rfc/rfc1140.txt1515
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