Network checkpoint
A dated report of protocol checks performed on ARPANET hosts in August 1971.
Harslem, E., "Network checkpoint", RFC 214, DOI 10.17487/RFC0214, August 1971, <https://www.rfc-editor.org/info/rfc214>.
@misc{rfc214,
series = {Request for Comments},
number = 214,
howpublished = {RFC 214},
publisher = {RFC Editor},
doi = {10.17487/RFC0214},
url = {https://www.rfc-editor.org/info/rfc214},
author = {E. Harslem},
title = {{Network checkpoint}},
pagetotal = 2,
year = 1971,
month = aug,
} RFC text
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 ]
ISO Plain Language
On this page
§1The Checkout Table
As of August 21, the author reported arranged verifications for listed ARPANET sites. The table covers NCP-107, ICP-156, user Telnet, server Telnet, Logger and Access Service, with marks for verified, not applicable and entries with comments.
The listed sites include UCLA Sigma7, SRI NIC, UCSB, BBN, MIT, SDC, Lincoln and Utah.
The table records whether selected functions were checked at each site. It is a snapshot of those checks, not a complete inventory.
§1What the NCP Check Means
The author says the NCP-107 heading is misleading if read as a full test of NCP functions. It only means the NCP responded to RESET, which Rand's NCP needed to consider a remote host up, and performed functions needed for an ICP.
Functions such as ECHO, Give Back and error-message generation were not checked exhaustively. Some were checked with UCSB and SDC.
An NCP mark means a limited set of checks passed. It does not mean every NCP function was tested.
§1Comments and Follow-up
The RFC reports that SRI NIC had a server Telnet and logger that did not process Telnet messages correctly. At MIT Multics, the authors reached an interim logger that sent a 'ts' message; at SDC, the logger caused a crash after login.
The author asks that discrepancies be reported by phone and says the RFC would be updated in about one month.
The comments describe a few specific problems with logins and Telnet processing. The report invites corrections by phone.