Response to RFC 111: Pressure from the chairman
Rand answers a 1971 request for implementation schedules and explains why it is waiting for a TELNET specification.
Heafner, J.F., "Response to RFC 111: Pressure from the chairman", RFC 130, DOI 10.17487/RFC0130, April 1971, <https://www.rfc-editor.org/info/rfc130>.
@misc{rfc130,
series = {Request for Comments},
number = 130,
howpublished = {RFC 130},
publisher = {RFC Editor},
doi = {10.17487/RFC0130},
url = {https://www.rfc-editor.org/info/rfc130},
author = {J.F. Heafner},
title = {{Response to RFC 111: Pressure from the chairman}},
pagetotal = 1,
year = 1971,
month = apr,
} RFC text
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]
AI ELI5
On this page
§1Two Goals of RFC 111
J. Heafner of Rand reads RFC 111 ("Pressure from the chairman") as having two aims. The first is to set realistic implementation schedules and publish them so everyone can plan productive use of Network services. The second is to uncover implementation techniques and strategies that worked best and could help future implementations.
The teacher wants everyone to say when they will finish, and also to share tricks that helped.
§2Waiting for TELNET
Heafner has not yet asked host teams for schedules, because they include TELNET and no specification is known to everyone. Tom O'Sullivan of Raytheon (TELNET Chairman) and John Melvin of SRI advise that a TELNET RFC will be generated soon. Heafner will then contact the site liaisons.
You cannot say when a puzzle will be done if one piece of the instructions is still missing.
§3How Schedules Will Be Published
Heafner and Alex McKenzie of BBN agree the schedules should be published as an RFC updating NIC Memo 5767 (ARPA Network Site Status). Heafner collects the information by phone, mail or NIC and sends it to McKenzie for technical editing and publication. The forthcoming Resource Notebook (NIC 5760) covers service use and job numbers, so the schedules may reference it but will not duplicate it.
Rand's role, as RFC 111 states, is to help test implementations remotely. That testing will be short term and will not go beyond what is in RFC 111. Readers are invited to contact Heafner or Eric Harslem.
One person gathers everyone's dates, a second person tidies them, and then they are posted for all to see.