All victims together
A call to document how networks integrate with operating systems.
Padlipsky, M.A., "All victims together", RFC 967, DOI 10.17487/RFC0967, December 1985, <https://www.rfc-editor.org/info/rfc967>.
@misc{rfc967,
series = {Request for Comments},
number = 967,
howpublished = {RFC 967},
publisher = {RFC Editor},
doi = {10.17487/RFC0967},
url = {https://www.rfc-editor.org/info/rfc967},
author = {M.A. Padlipsky},
title = {{All victims together}},
pagetotal = 2,
year = 1985,
month = dec,
} RFC text
Contents
Network Working Group M. A. Padlipsky
Request for Comments: 967 Mitre Corporation
December 1985
All Victims Together
STATUS OF THIS MEMO
This RFC notes a significant omission from the networking literature
and proposes to remedy it. Distribution of this memo is unlimited.
DISCUSSION
An interesting thing happened the other day. Some people were up
visiting from IBM Federal Systems Division and, during the course of
the conversation, one of them pointed out that they had just as much
if not more trouble with the operating system purveyors about making
OS "changes" in behalf of networking as anyone else. At the time I
just observed that it looked as if we were all victims together and
went on to the next point, but further reflection prompts me to offer
a few thoughts on the topic to the RFC community:
o To us, it's axiomatic that networking code is system code when it
has to be.
o To Them, it's anathema.
o We haven't really hit very hard on the point in the literature
(although I guess I have made a few strong assertions along those
lines, here and there, and it's at least implicit in some of Dave
Clark's stuff), unless in my usual slipshod fashion I've just
missed seeing it.
o It would probably be responsible of us to rectify the omission
(assuming there is one) since the literature is supposed to be
the way the researchers educate the practioners.
o Therefore, I propose a new subseries of RFCs on how the
networking code was integrated with various OSs, with an eye
toward subsequent publication of the collection in the open
literature (RFCs being only semi-open, after all). I'll even
volunteer to coordinate, at least to the extent of taking offers
from people who are willing to tackle various systems and telling
them who else is having a bash at the same one for purposes of
possible collaboration--and possibly even merging the results of
separate efforts if people just send in things they've already
done. (I suppose I even have to offer to do a bit of editing, if
people want.)
All Victims Together
What I'd like to see emerge is a bunch of little essays along the
lines of what I attempted to do on Multics in RFC 928, pp.14-21,
which would probably be a waste of electrons to reproduce here, but I
will if Jon thinks it's worthwhile at some level. With luck,
volunteers will emerge to discuss all of the major operating systems
currently on the net and most of the minor ones as well, since one of
the most interesting philosophical aspects of the exercise is to see
just what cuts and pastes get made to any OS if it's networked. My
guess is that given more modern systems' tendencies to make adding
device drivers more straightforward and to offer interprocess
communication primitives at the system level, the likeliest
difficulties to encounter would be getting on the process creation
path appropriately for Telnet--but that's reasoning ahead of the
data. Suffice it to say that each piece should address Host-Host
protocol interpreter(s) integration as well as Host-Comm Subnet
Processor PI (including device driver, if one), plus something about
Telnet and something else about FTP (at least to the extent of
whether it's per-user or "monolithic"--on the server side, that is),
and, of course, some relevant anatomizing of the OS itself.
The moral, it seems to me, is that we have a chance to strike back at
the oppressors by showing them what they should be furnishing with
their silly off-the-rack systems if they are going to continue to
object to our alterations to make the bloody things fit anywhere near
right. It's a little extra effort on our part, but it's probably a
worthy goal. Indeed, if anybody from IPTO is watching I suppose I'd
even go so far as to suggest a pro tem System Integration Task force
if I hadn't already volunteered once in this thing and used up my
quota.
Think about it.
EDITOR'S NOTE
The editor recalls a session at the 5th Data Communication Symposium
(the one at Snowbird) titled "Impact of Networks on Host-System
Design and Architecture". (1977)
AI ELI5
On this page
§1The Documentation Gap
RFC 967 observes that networking code, when properly integrated into an operating system, becomes system code and requires the kind of deep changes that OS vendors often resist. The RFC notes that this problem affects organizations across the industry, from academic research networks to major companies like IBM. The author proposes that the ARPANET community should document this integration process to help practitioners understand what is required and to justify these changes to OS vendors.
Putting Internet tools into a computer means changing how the computer works. Different computers change in different ways. Nobody has written down how.
§2A Subseries of RFCs
The author proposes a new subseries of RFCs focusing on OS integration, with essays from practitioners who have integrated networking code into each major operating system. Each essay should document the Host-Host protocol interpreter(s), the Subnet Processor device driver, Telnet integration, FTP integration (addressing whether it runs per-user or as a single daemon on the server), and relevant aspects of the OS architecture itself. The author offers to coordinate submissions and potentially help edit and merge overlapping contributions from different implementers on the same OS.
The goal is eventually to publish these essays in the open literature beyond the RFC series itself, making this knowledge available to a broader audience.
Ask everyone who put the Internet on their computer to write an essay about it. Then collect them together so everyone can learn from everyone else.
§3Striking Back at Objections
The RFC frames this initiative as a way to "strike back" at OS vendors who object to necessary networking modifications by showing them what they should be including in their systems. The author notes that modern systems' trends toward making device drivers easier to add and offering interprocess communication primitives at the system level may simplify integration, though one remaining challenge is adapting the process creation path for Telnet. The author expresses hope that volunteers will document all major and most minor operating systems on the network, creating a comprehensive handbook of integration experience.
If we show the computer makers what networking really needs, maybe they'll make their computers easier to network.