Index Journeys
RFC 270 UNKNOWN INFRASTRUCTURE · CORRECTION

Correction to BBN Report No. 1822 (NIC NO 7958)

Correction to a documentation error about IMP host timeout.

On rfc-editor.org ↗
PUBLISHED
January 1972
AUTHORS
A.M. McKenzie
STREAM
Legacy
ACTUAL TIMEOUT
30 seconds
DOCUMENTED (INCORRECTLY)
40 seconds
HOST DEAD STATUS
NOT changed by timeout alone
DOI
10.17487/RFC0270
ERRATA
Reported errata

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
Network Working Group                                        A. McKenzie
Request for Comments: 270                                            BBN
NIC: 7818                                                January 1, 1972


                    CORRECTION TO BBN REPORT NO. 1822


   In the process of generating RFC #271 we have discovered a set of
   errors in BBN Report No. 1822 (NIC 7958).  The attached page is a
   corrected version of page 25; in addition the first two lines should
   be deleted from page 26.  The paragraph at the top of page 25 is
   changed to show that the Host is NOT marked dead under the stated
   conditions, and to show that the timeout period is 30 (rather than
   40) seconds.  In the footnote, the two changes are underlined; these
   changes also show the timeout period as 30 seconds.  A more formal
   update to Report 1822 will be distributed eventually.

   Please note that these changes reflect errors in previous versions of
   Report 1822, _not_ changes to the IMP system.  The timeout period has
   ALWAYS been 30 seconds and the Host was NEVER marked dead under these
   conditions.
















          [This RFC was put into machine readable form for entry]
      [into the online RFC archives by Kelly Tardif, Viag�nie 10/99]

AI ELI5

On this page
PROBLEMBBN Report No. 1822, which documents the IMP system, contains an error on page 25 about when a host is marked dead.
MECHANISMRFC 270 provides a corrected page showing the actual timeout is 30 seconds, not 40, and clarifies that the host is NOT marked dead under the stated conditions.
CLARIFICATIONThe RFC clarifies that the IMP system itself was always correct; only the documentation was wrong.

§1The Error

Alex McKenzie at BBN discovered errors in BBN Report No. 1822 while preparing RFC 271. The report documents the IMP (Interface Message Processor) system and how it handles host communication. The primary error is on page 25, which incorrectly states that a host is marked dead under certain timeout conditions.

McKenzie's team identified the need for a corrected version of page 25 and also required deletion of the first two lines of page 26. The changes show that the host is NOT marked dead under the stated conditions and that the timeout period is 30 seconds, not 40 seconds.

The manual said the machine waits 40 seconds before deciding a host is dead. It actually waits 30, and even then the host does not get marked dead the way the manual said.

§2Documentation, Not System Change

Critically, McKenzie emphasizes that these changes reflect errors in previous versions of Report 1822, not changes to the IMP system itself. The IMP has ALWAYS used a 30-second timeout and the host was NEVER marked dead under the stated conditions. The actual hardware and software were correct all along.

This is a pure documentation correction. The document had drifted from reality, and RFC 270 helps bring it back in line with how the system actually operates. A more formal update to Report 1822 was promised for distribution later.

The machine always worked right. Someone just wrote down the wrong numbers in the manual.

§3Significance

RFC 270 is brief but important: it shows how early network documentation could become inaccurate. BBN Report No. 1822 was the authoritative specification for IMP behavior, but humans writing documentation can misstate how systems actually work.

The RFC process, by making corrections public and linked to earlier documents, helped catch and fix such errors. Sites relying on Report 1822 for implementing their host software would have been confused without this clarification.

This small note helped people understand the real behavior, stopping them from building wrong things based on bad docs.

§4Scope

RFC 270 exemplifies how the early RFC process handled errata and clarifications. Rather than waiting for a complete new edition of a report, corrections could be published quickly as RFCs, ensuring all network sites received the right information promptly.

The emphasis on clarity—that this is a documentation correction, not a system change—shows good practice. It prevents unnecessary alarm and confusion among implementers and operators.

When docs are wrong, fix them fast and tell everyone. This was how the early network kept information reliable.

§5References

[1]BBN, "The ARPANET Imp Program Quarterly Technical Report", BBN Report No. 1822, NIC 7958, 1970.