rfc999.txt

RFC 的详细文档！

   and servers.  NTP is built on the User Datagram Protocol (UDP), which
   provides a connectionless transport mechanism.  It is evolved from the
   Time Protocol and the ICMP Timestamp message and is a suitable
   replacement for both.  This RFC suggests a proposed protocol for the



Westine & Postel                                                [Page 9]

RFC 999                                                       March 1987


   ARPA-Internet community, and requests discussion and suggestions for
   improvements.

957     Mills        Sep 85      Experiments in Network Clock
                                 Synchronization

   This RFC discusses some experiments in clock synchronization in the
   ARPA-Internet community, and requests discussion and suggestions for
   improvements.  One of the services frequently neglected in computer
   network design is a high-quality, time-of-day clock capable of
   generating accurate timestamps with small errors compared to one-way
   network delays.  Such a service would be useful for tracing the progress
   of complex transactions, synchronizing cached data bases, monitoring
   network performance and isolating problems.  In this memo one such clock
   service design will be described and its performance assessed.  This
   design has been incorporated as an integral part of the network routing
   and control protocols of the Distributed Computer Network (DCnet)
   architecture.

956     Mills        Sep 85      Algorithms for Synchronizing Network
                                 Clocks

   This RFC discussed clock synchronization algorithms for the
   ARPA-Internet community, and requests discussion and suggestions for
   improvements.  The recent interest within the Internet community in
   determining accurate time from a set of mutually suspicious network
   clocks has been prompted by several occasions in which errors were found
   in usually reliable, accurate clock servers after thunderstorms which
   disrupted their power supply.  To these sources of error should be added
   those due to malfunctioning hardware, defective software and operator
   mistakes, as well as random errors in the mechanism used to set and
   synchronize clocks.  This report suggests a stochastic model and
   algorithms for computing a good estimator from time-offset samples
   measured between clocks connected via network links.  Included in this
   report are descriptions of certain experiments which give an indication
   of the effectiveness of the algorithms.

955     Braden       Sep 85      Towards a Transport Service for
                                 Transaction Processing Applications

   The DoD Internet protocol suite includes two alternative transport
   service protocols, TCP and UDP, which provide virtual circuit and
   datagram service, respectively.  These two protocols represent points in
   the space of possible transport service attributes which are quite "far
   apart".  We want to examine an important class of applications, those
   which perform what is often called "transaction processing".  We will
   see that the communication needs for these applications fall into the
   gap "between" TCP and UDP -- neither protocol is very appropriate.
   This RFC is concerned with the possible design of one or more new
   protocols for the ARPA-Internet, to support kinds of applications which
   are not well supported at present.  The RFC is intended to spur



Westine & Postel                                               [Page 10]

RFC 999                                                       March 1987


   discussion in the Internet research community towards the development of
   new protocols and/or concepts, in order to meet these unmet application
   requirements.  It does not represent a standard, nor even a concrete
   protocol proposal.

954     Harrenstien  Oct 85      NICNAME/WHOIS

   This RFC is the official specification of the NICNAME/WHOIS protocol.
   This memo describes the protocol and the service.  This is an update of
   RFC-812.

953     Harrenstien  Oct 85      Hostname Server

   This RFC is the official specification of the Hostname Server Protocol.
   This edition of the specification includes minor revisions to RFC-811
   which brings it up to date.

952     Harrenstien  Oct 85      DoD Internet Host Table Specification

   This RFC is the official specification of the format of the Internet
   Host Table.  This edition of the specification includes minor revisions
   to RFC-810 which brings it up to date.

951     Croft        Sep 85      Bootstrap Protocol (BOOTP)

   This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a
   diskless client machine to discover its own IP address, the address of a
   server host, and the name of a file to be loaded into memory and
   executed.  The bootstrap operation can be thought of as consisting of
   TWO PHASES.  This RFC describes the first phase, which could be labeled
   `address determination and bootfile selection'.  After this address and
   filename information is obtained, control passes to the second phase of
   the bootstrap where a file transfer occurs.  The file transfer will
   typically use the TFTP protocol, since it is intended that both phases
   reside in PROM on the client.  However BOOTP could also work with other
   protocols such as SFTP or FTP.  This RFC suggests a proposed protocol
   for the ARPA-Internet community, and requests discussion and suggestions
   for improvements.

950     Mogul        Aug 85      Internet Standard Subnetting Procedure

   This memo discusses the utility of "subnets" of Internet networks, which
   are logically visible sub-sections of a single Internet network.  For
   administrative or technical reasons, many organizations have chosen to
   divide one Internet network into several subnets, instead of acquiring a
   set of Internet network numbers.  This memo specifies procedures for the
   use of subnets.  These procedures are for hosts (e.g., workstations).
   The procedures used in and between subnet gateways are not fully
   described.  Important motivation and background information for a
   subnetting standard is provided in RFC-940.  This RFC specifies a
   protocol for the ARPA-Internet community.  If subnetting is implemented
   it is strongly recommended that these procedures be followed.


9Westine & Postel                                               [Page 11]

RFC 999                                                       March 1987


949     Padlipsky    Jul 85      FTP Unique-Named Store Command

   There are various contexts in which it would be desirable to have an FTP
   command that had the effect of the present STOR but rather than
   requiring the sender to specify a file name istead caused the resultant
   file to have a unique name relative to the current directory.  This
   RFC proposes an extension to the File Transfer Protocol for the
   ARPA-Internet community, and requests discussion and suggestions for
   improvements.  See RFC-959.

948     Winston      Jun 85      Two Methods for the Transmission of IP
                                 Datagrams Over IEEE 802.3 Networks

   This RFC describes two methods of encapsulating Internet Protocol (IP)
   datagrams on an IEEE 802.3 network.  This RFC suggests a proposed protocol
   for the ARPA-Internet community, and requests discussion and suggestions
   for improvements.

947     Lebowitz     Jun 85      Multi-Network Broadcasting Within the
                                 Internet

   This RFC describes the extension of a network's broadcast domain to
   include more than one physical network through the use of a broadcast
   packet repeater.

946     Nedved       May 85      Telnet Terminal Location Number Option

   Many systems provide a mechanism for finding out where a user is logged
   in from usually including information about telephone extension and
   office occupants names.  The information is useful for physically
   locating people and/or calling them on the phone.  In 1982 CMU designed
   and implemented a terminal location database and modified existing
   network software to handle a 64-bit number called the Terminal Location
   Number (or TTYLOC).  It now seems appropriate to incorporate this
   mechanism into the TCP-based network protocol family.  The mechanism is
   not viewed as a replacement for the Terminal Location Telnet Option
   (SEND-LOCATION) but as a shorthand mechansim for communicating terminal
   location information between hosts in a localized community.  This RFC
   proposes a new option for Telnet for the ARPA-Internet community, and
   requests discussion and suggestions for improvements.

945     Postel       May 85      A DoD Statement on the NRC Report

   In May 1983 the National Research Council (NRC) was asked jointly by DoD
   and NBS to study the issues and recommend a course of action.  The final
   report of the NRC committee was published in February 1985 (see
   RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA
   transmitting the NRC report and requesting specific actions relative to
   the recommendations of the report.  This RFC reproduces a letter from the
   Assistant Secretary of Defense for Command, Control, Communications, and
   Intelligence (ASDC3I) to the Director of the Defense Communications Agency
   (DCA).  This letter is distributed for information only.


9Westine & Postel                                               [Page 12]

RFC 999                                                       March 1987


944     Reynolds    Apr 85      Official ARPA-Internet Protocols

   This RFC identifies the documents specifying the official protocols used
   in the Internet.  This edition of Official ARPA-Internet Protocols
   obsoletes RFC-924 and earlier editions.  This RFC will be updated
   periodically, and current information can be obtained from Joyce Reynolds.
   This memo is an official status report on the protocols used in the
   ARPA-Internet community.  See RFC-991.

943     Reynolds     Apr 85      Assigned Network Numbers

   This Network Working Group Request for Comments documents the currently
   assigned values from several series of numbers used in network protocol
   implementations.  This RFC will be updated periodically, and in any case
   current information can be obtained from Joyce Reynolds.  The assignment
   of numbers is also handled by Joyce.  If you are developing a protocol
   or application that will require the use of a link, socket, port,
   protocol, network number, etc., please contact Joyce to receive a number
   assignment.  This memo is an official status report on the numbers used
   in protocols in the ARPA-Internet community. See RFC-990 and 997.

942     NRC          Feb 85      Transport Protocols for Department of
                                 Defense Data Networks

   This RFC reproduces the National Research Council report resulting from
   a study of the DoD Internet Protocol (IP) and Transmission Control
   Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and
   Transport Protocol level 4 (TP-4).

941     ISO          Apr 85      Addendum to the Network Service
                                 Definition Covering Network Layer
                                 Addressing

   This Addendum to the Network Service Definition Standard, ISO 8348,
   defines the abstract syntax and semantics of the Network Address
   (Network Service Access Point Address).  The Network Address defined in
   this Addendum is the address that appears in the primitives of the
   connection-mode Network Service as the calling address, called address,
   and responding address parameters, and in the primitives of the
   connectionless-mode  Network  Service  as  the source address and
   destination address parameters.  This document is distributed as an RFC
   for information only.  It does not specify a standard for the ARPA-Internet.









9

9Westine & Postel                                               [Page 13]

RFC 999                                                       March 1987


940     GADS         Apr 85      Toward an Internet Standard Scheme for
                                 Subnetting

   Several sites now contain a complex of local links connected to the
   Internet via a gateway.  The details of the internal connectivity are of
   little interest to the rest of the Internet.  One way of organizing
   these local complexes of links is to use the same strategy as the
   Internet uses to organize networks, that is, to declare each link to be
   an entity (like a network) and to interconnect the links with devices
   that perform routing functions (like gateways).  This general scheme is
   called subnetting, the individual links are called subnets, and the
   connecting devices are called subgateways (or bridges, or gateways).