1 files changed, 59 insertions, 0 deletions
diff --git a/doc/rfc/rfc130.txt b/doc/rfc/rfc130.txt
new file mode 100644
index 0000000..04b16e0
--- /dev/null
+++ b/doc/rfc/rfc130.txt
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+Network Working Group                                         J. Heafner
+Request for Comments: 130                                           Rand
+NIC 5848                                                   22 April 1971
+
+
+           RESPONSE TO RFC #111 (PRESSURE FROM THE CHAIRMAN)
+
+   The purpose of RFC #111, as I interpret it, is two-fold:  1) To
+   establish realistic implementation schedules and to make them known
+   to the Network community so as to expedite everyone's planning of
+   productive use of Network Services.  2) To uncover implementation
+   techniques and strategies that were most successful and might be
+   useful in future implementations.
+
+   RFC #111 asks for implementation schedules.  I have not "prodded"
+   host teams yet because an integral part of those schedules includes
+   TELNET for which no specification is known to everyone.  Tom
+   O'Sullivan, Raytheon (TELNET Chairman) and John Melvin, SRI (TELNET
+   Committee Member) advise me that a TELNET RFC will be generated soon.
+   I will subsequently contact site liaisons concerning a schedule.
+
+   I will talk with Alex McKenzie, BBN about the form of publication of
+   these schedules.  Alex and I agree that they should be published as
+   an RFC updating NIC Memo #5767 (ARPA Network Site Status).  I will
+   collect and compile the information via phone, mail or NIC and send
+   it to Alex for technical editing and subsequent NIC RFC publication.
+
+   Alex informed me that the forthcoming Resource Notebook (see NIC
+   #5760) includes much of the information on use of services, obtaining
+   job numbers, etc.  RFC #111 schedules will be an update of NIC #5767
+   and may reference, but will not duplicate, the Resource Notebook.
+
+   One begins to wonder why I'm in this loop since Alex has the
+   responsibility to periodically update NIC #5767.  The reason, as RFC
+   #111 states, is that Rand will assist in testing implementations
+   remotely.  To facilitate testing, I would like first-hand information
+   on schedules and comments on how we might be of service in this
+   respect.  Testing will be short-term and will not go beyond what is
+   included in RFC #111.  I will contact site liaisons shortly to find
+   out if and how we can be of assistance in this capacity.
+
+   Please feel free to contact either me or Eric Harslem regarding this
+   RFC or RFC #111.
+
+
+        [ This RFC was put into machine readable form for entry]
+      [into the online RFC archives by Alison M. De La Cruz 12/00]
+
+
+
+
+Heafner                                                         [Page 1]
+