Index Journeys
RFC 214 UNKNOWN ARPANET · TESTING

Network checkpoint

A 1971 status table of which ARPANET hosts had passed basic protocol checks.

On rfc-editor.org ↗
PUBLISHED
August 1971
AUTHORS
E. Harslem
STREAM
Legacy
BUILDS ON
RFC 198 — Site Certification - Lincoln Labs 360/67
REPORT DATE
August 21, 1971
HOSTS LISTED
11
PLANNED UPDATE
in about one month
DOI
10.17487/RFC0214
LINEAGE · FROM THE RFC INDEXOpen full graph →
'71RFC 198Site Certification - Lincoln Labs 360/67'71RFC 214Network checkpoint

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
Network Working Group                              21 August 1971
Request for Comments 214                           E. Harslem-Rand
NIC 7195
Category: F
Obsoletes: 193, 198


                            NETWORK CHECKOUT


      As of August 21 we had performed the following verifications
with the sites listed below.  These verifications were done on an
arranged basis and do not indicate any degree of continuous
availability.

      In the category "NCP-107" the heading is somewhat misleading.
It does not indicate a thorough checkout of all the NCP functions
described in Document 1 and RFC-107.  It only indicates that the NCP
in question functioned to the extent required to respond to a RESET (a
necessary condition for the Rand NCP to consider the remote host "up")
and that the NCP performed the functions necessary for an ICP.  Thus,
this column really indicates only a small degree of NCP completeness.
Such function as ECHO, Give Back, error message generation and so on
were not checked.  We have checked some of these functions with UCSB
and SDC but not exhaustively.  This is mainly due to the tedium of
such a process.  BBN is currently writing a protocol certifier for
their DDP-516 host that will do this automatically.

                                  User   Server          Access
               NCP-107  ICP-156  Telnet  Telnet  Logger  Service
UCLA Sigma7      x        x        x       x       x       x
UCLA /91         x        x        x       x       na      x
SRI NIC          x        x                ?       ?       ?
UCSB             x        x        x       x       na      x
BBN A10          x        x                x       x       x
BBN TIP          x        x        x       x               na
MIT Multics      x        ?
MIT DMCG         x        x        x       x       x       x
SDC              x        x        x       x       ?
LINCOLN /67      x        x        x       x       x       x
UTAH             TENEX being installed


LEGEND:

 --- the function has not been verified for the host

x--- the function has been verified for the host

na-- the function is not applicable to the host due to its
     operating system or intended network use

?--- a comment follows for that function in that host


COMMENTS:

SRI NIC -- both a server telnet and logger exist; however, they
           do not process the telnet messages correctly

MIT Multics  -- we were only able to connect to an interim
          logger that sent a 'ts' message

SDC  -- the logger causes the system to crash following login


      Any discrepancies should be noted via phone call.  This
RFC will be updated in about one month.




       [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Brian Court 6/97 ]

AI ELI5

On this page
PROBLEMSites joining the ARPANET needed to know which other hosts actually worked with the early protocols.
MECHANISMRand tabulated, per host, whether the NCP, the initial connection protocol, user and server Telnet, the logger and an access service had been verified, with comments on failures.
THE CATCHThe author warns that these were arranged one-time tests that show no continuous availability, and says the RFC would be updated in about one month.

§1The Checkout Table

As of August 21, 1971, the author had performed verifications with the sites listed. A mark of x means a function was verified, a blank means it was not verified, na means it does not apply to the host, and ? means a comment follows. The columns are NCP-107, ICP-156, user Telnet, server Telnet, Logger and Access Service.

Eleven rows are listed, from UCLA Sigma7 to LINCOLN /67. For UTAH the entry says only that TENEX was being installed.

Each computer gets a row of check marks for the tests it passed. An empty box means nobody tried yet.

§2What the Checks Prove

The author says the 'NCP-107' heading is somewhat misleading. It does not mean a thorough check of all the functions in Document 1 and RFC 107. It only means the NCP answered a RESET, which the Rand NCP needs before it considers a remote host up, and did what an initial connection needed.

Functions such as ECHO, Give Back and error message generation were not checked, except some with UCSB and SDC, and not exhaustively. BBN was writing a protocol certifier for its DDP-516 host to do this automatically. The tests were arranged and show no degree of continuous availability.

One check mark only means a computer answered the door and said hello. It does not mean everything inside works.

§3Comments on Problem Hosts

Three comments are given. At SRI NIC, a server Telnet and logger exist but do not process Telnet messages correctly. At MIT Multics, only an interim logger could be reached, and it sent a 'ts' message. At SDC, the logger crashes the system after login.

Discrepancies were to be reported by phone, and the RFC would be updated in about one month.

A few computers had problems, like one that crashed after someone logged in. The author asks to be told by phone about any mistakes.

§4References

RFC-107RFC 107RFC 107, cited by the report as describing the NCP functions (title not given in the text).March 1971