1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc17.txt b/doc/rfc/rfc17.txt
new file mode 100644
index 0000000..9580428
--- /dev/null
+++ b/doc/rfc/rfc17.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                         J. Kreznar
+Request for Comments: 17                                             SDC
+Category: Informational                                   27 August 1969
+
+
+                  Some Questions Re: HOST-IMP Protocol
+
+1.  Automatic deletion of links, as indicated in BBN 1822, page 11,
+    seems bad:
+
+     a) Link use may be dependent upon human use of a time share
+        terminal - indefinite time between messages.
+
+     b) Program using link may be slow due to:
+
+        i)  Busy HOST (many jobs)
+
+        ii) Much local I/O and/or CPU time between messages - is it
+            that, if a HOST's user fails to use a link for 15 seconds,
+            the HOST network program must generate a dummy message
+            merely to keep the link open?
+
+2.  Steve Crocker, HOST Software, 1969 Apr 7, asks on page 2: "Can a
+    HOST, as opposed to its IMP, control RFNM's?"  BBN, Report No. 1837,
+    1969 Jul, says on page 2: "The principal function of the (IMP)
+    program...includes...generating of RFNM's..."  What if an IMP
+    generates an RFNM and then discovers it cannot, for some reason,
+    complete timely delivery of the last received message to its HOST?
+    This seems especially pressing since I don't recall seeing anywhere an
+    IMP constraint upon HOSTs that they must accept incoming messages
+    within some specified maximum time.
+
+3.  A HOST has to be prepared to repeat transmissions of a message
+    into network (see, e.g., Page 17, BBN 1822) therefore why the
+            special discardable NOP message (Page 12, BBN 1822).
+
+4.  "Arbitrary delays," middle paragraph, page 23, BBN 1822, seems
+    inconsistent with automatic link deletion questioned in 1 above.
+    Normally the times involved differ by many orders of magnitude but a
+    high priority non-network HOST responsibility could delay next bit for
+    a long time.
+
+    1.  Abhi Bhushan, Proj. MAC         10.  Sal Aranda, SDC
+    2.  Steve Crocker, UCLA             11.  Jerry Cole,  "
+    3.  Ron Stoughton, UCSB             12.  John Kreznar,"
+    4.  Elmer Shapiro, SRI              13.  Dick Linde,  "
+    5.  Steve Carr, Utah                14.  Bob Long,    "
+    6.  John Haefner, RAND              15.  Reg Martin,  "
+
+
+
+Kreznar & Kahn                                                  [Page 1]
+
+RFC 17& 17a         Re: HOST-IMP Protocol & Response         August 1969
+
+
+    7.  Paul Rovner, LL                 16.  Hal Sackman, "
+    8.  Bob Kahn, BB & N                17.  C. Weissman, "
+    9.  Larry Roberts, ARPA
+
+         [ This RFC was put into machine readable form for entry ]
+          [ into the online RFC archives by Marc Blanchett 3/00 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kreznar & Kahn                                                  [Page 2]
+
+RFC 17& 17a         Re: HOST-IMP Protocol & Response         August 1969
+
+
+Network Working Group                                            R. Kahn
+Request for Comments: 17a                    Bolt Beranek and Newman Inc
+                                                             August 1969
+
+
+                 Re: Some Questions Re: HOST-IMP Protocol
+
+   THE FOLLOWING COMMENTS ARE IN RESPONSE TO JOHN KREZNAR'S QUESTIONS
+   WHICH WERE RAISED IN NWG:- 17
+
+   The deletion of a link entry from an IMP's link table will, in
+   general, have no effect upon a Host transmission (or reception) at
+   that IMP's site.  Let us distinguish between non-use of a link in-
+   between messages and non-use of a link due to Host program delays in
+   the middle of transmitting or receiving a message.  When the Host
+   transmits a message on a link for which an entry is not in the link
+   table, one will simply be inserted there.  There is no need for
+   "dummy" Host messages to keep a link "open" since a link is
+   effectively always open.  Only if the link table becomes full
+   immediately after an entry is deleted (a situation we do not expect
+   to occur) is there a possibility of resulting delay.
+
+   Arbitrary delays introduced by Host programs are also not
+   inconsistent with the link entry deletion procedure.  A link is
+   blocked when the first access of the link table is made during
+   transmission from the source IMP and is unblocked when the RFNM
+   returns.  Only non-blocked transmit link entries are deleted after 30
+   seconds of disuse.  The statement on page 23 referencing arbitrary
+   delays was only intended to have hardware implications insofar as the
+   Host/IMP interface is designed to transfer bits asynchronously
+   between the Host and the IMP.
+
+   A RFNM is returned from the destination IMP to the source IMP when a
+   message reaches the head of the destination IMP's output queue to the
+   Host (i.e. just before a message is sent to the Host).  If a
+   destination IMP cannot then deliver that full message to the Host, at
+   most one more message may possibly arrive at that IMP due to the
+   premature release of the RFNM.  The new message will subsequently
+   take its place at the end of the output queue to the Host thus
+   guaranteeing the preservation of the proper message arrival sequence.
+
+   The NOP message is a special control message which is available for
+   use during initiation of communication between the Host and its IMP.
+   The Host may, of course, decline to send NOP messages during this
+   period, but the first received message after IMP startup or after the
+
+
+
+
+
+
+Kreznar & Kahn                                                  [Page 3]
+
+RFC 17& 17a         Re: HOST-IMP Protocol & Response         August 1969
+
+
+   Host ready indicator has gone on, may be discarded by the IMP.  We do
+   not require a Host to be prepared to repeat transmissions into the
+   network.
+
+   R.E. Kahn
+   BOLT BERANEK AND NEWMAN INC.
+
+
+         [ This RFC was put into machine readable form for entry ]
+          [ into the online RFC archives by Marc Blanchett 3/00 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kreznar & Kahn                                                  [Page 4]
+