From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc271.txt | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)
 create mode 100644 doc/rfc/rfc271.txt

(limited to 'doc/rfc/rfc271.txt')

diff --git a/doc/rfc/rfc271.txt b/doc/rfc/rfc271.txt
new file mode 100644
index 0000000..27f5fed
--- /dev/null
+++ b/doc/rfc/rfc271.txt
@@ -0,0 +1,112 @@
+
+
+
+
+
+
+Network Working Group                              Bernard Cosell
+RFC # 271                                          BBN
+NIC 7819                                           3 January 1972
+Categories:  B.1
+Updates:  None
+Obsoletes:  None
+
+                     IMP System Change Notification
+                     ------------------------------
+
+
+    We are planning to install a new version of the IMP System,
+version 2514.  The new version is scheduled for field installation
+Thursday, January 13, 1972 between noon and 1 PM EST, and will require
+the assistance of IMP-site personnel at each site.
+
+
+    There were two principal problems with version 2513, both related
+to the delay inserted between the time when a Host comes up and the
+time when its IMP will accept the second packet from the Host.  The
+first was that the delay was lengthened to slightly over 40 seconds,
+which caused hardware difficulties for some Hosts.  The second was
+that there was an ambiguity that could make the delay run as long as a
+minute and a quarter.  On the first point, the delay has been backed
+off from 40 seconds to 30 seconds, as it was for IMP systems prior to
+2513.  On the second point, the ambiguity has been entirely removed.
+(Note, however, that BBN Report No. 1822, on page 23, specifies that
+the delay may range from 30 to 90 seconds, and that future versions
+may require a longer delay.)
+
+
+    In summary, a Host may come alive in one of two ways, corres-
+ponding to the two ways in which the Host can go down.  If the Host
+went down voluntarily (by sending a "Host going down" to the IMP), the
+Host indicates his intention to come alive by sending the IMP
+something.  If the Host went down involuntarily (by dropping his ready
+line), the Host indicates his intention to come alive by bringing his
+ready line back up.  In either case
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+the IMP will refuse to accept more than one packet from the Host for
+30 seconds after the Host has indicated his intention to come alive.
+Notice, however, that the Host must be prepared to accept all messages
+from the Network from the instant that he indicates his intention to
+come alive.* This particular point seems to have given many Hosts
+difficulty in running through their standard initialization
+procedures.  Don't forget this simple and universal rule, that when
+you are telling your IMP that you are alive, you must be prepared to
+always take every- thing from the Network whether or not the Network
+is taking any- thing from you.
+
+    Version 2514 will also incorporate a few other changes, mainly
+related to the operation of the NCC.  Since the Timeout is, for a
+change, being made shorter, and the other modifications are minor,
+there should be no appreciable transient with the coming of the new
+version.
+
+_______________
+*In fact, if the Host does not accept messages from his IMP
+pimmediately then the Host may see the IMP's Ready line go down
+for 1/4 second sometime during the 30 second waiting period.
+This is due to the following set of circumstances:
+
+    *  The IMP periodically places NOPs on the queue for a
+       dead Host as part of the process of checking the IMP/Host
+       interface.
+
+    *  If a message remains on a Host's queue for 30 seconds
+       without being taken, the IMP drops its Ready line for
+       1/4 second in order to clear the interface (see RFC #270).
+
+    *  The timeout periods for the Host queue and the delay
+       when the Host comes alive are _not_ synchronized.
+
+If the Host is prepared to see the IMP's Ready line dropped
+during the 30-second delay while coming alive, then no harm
+will be done if messages from the IMP are not accepted immediately.
+
+
+BC/jm
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by BBN Corp. under the   ]
+       [ direction of Alex McKenzie.                   12/96   ]
+
+
+
+
+
+
+
+                                                                [Page 2]
+
-- 
cgit v1.2.3