home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 900s / rfc967.txt < prev    next >
Text File  |  1992-09-22  |  5KB  |  115 lines
  1.  
  2.  
  3. Network Working Group                                    M. A. Padlipsky
  4. Request for Comments: 967                              Mitre Corporation
  5.                                                            December 1985
  6.  
  7.                           All Victims Together
  8.  
  9.  
  10. STATUS OF THIS MEMO
  11.  
  12.    This RFC notes a significant omission from the networking literature
  13.    and proposes to remedy it.  Distribution of this memo is unlimited.
  14.  
  15. DISCUSSION
  16.  
  17.    An interesting thing happened the other day. Some people were up
  18.    visiting from IBM Federal Systems Division and, during the course of
  19.    the conversation, one of them pointed out that they had just as much
  20.    if not more trouble with the operating system purveyors about making
  21.    OS "changes" in behalf of networking as anyone else. At the time I
  22.    just observed that it looked as if we were all victims together and
  23.    went on to the next point, but further reflection prompts me to offer
  24.    a few thoughts on the topic to the RFC community:
  25.  
  26.    o   To us, it's axiomatic that networking code is system code when it
  27.        has to be.
  28.  
  29.    o   To Them, it's anathema.
  30.  
  31.    o   We haven't really hit very hard on the point in the literature
  32.        (although I guess I have made a few strong assertions along those
  33.        lines, here and there, and it's at least implicit in some of Dave
  34.        Clark's stuff), unless in my usual slipshod fashion I've just
  35.        missed seeing it.
  36.  
  37.    o   It would probably be responsible of us to rectify the omission
  38.        (assuming there is one) since the literature is supposed to be
  39.        the way the researchers educate the practioners.
  40.  
  41.    o   Therefore, I propose a new subseries of RFCs on how the
  42.        networking code was integrated with various OSs, with an eye
  43.        toward subsequent publication of the collection in the open
  44.        literature (RFCs being only semi-open, after all). I'll even
  45.        volunteer to coordinate, at least to the extent of taking offers
  46.        from people who are willing to tackle various systems and telling
  47.        them who else is having a bash at the same one for purposes of
  48.        possible collaboration--and possibly even merging the results of
  49.        separate efforts if people just send in things they've already
  50.        done. (I suppose I even have to offer to do a bit of editing, if
  51.        people want.)
  52.  
  53.  
  54.  
  55.  
  56. Padlipsky                                                       [Page 1]
  57.  
  58.  
  59.  
  60. RFC 967                                                    December 1985
  61. All Victims Together
  62.  
  63.  
  64.    What I'd like to see emerge is a bunch of little essays along the
  65.    lines of what I attempted to do on Multics in RFC 928, pp.14-21,
  66.    which would probably be a waste of electrons to reproduce here, but I
  67.    will if Jon thinks it's worthwhile at some level. With luck,
  68.    volunteers will emerge to discuss all of the major operating systems
  69.    currently on the net and most of the minor ones as well, since one of
  70.    the most interesting philosophical aspects of the exercise is to see
  71.    just what cuts and pastes get made to any OS if it's networked. My
  72.    guess is that given more modern systems' tendencies to make adding
  73.    device drivers more straightforward and to offer interprocess
  74.    communication primitives at the system level, the likeliest
  75.    difficulties to encounter would be getting on the process creation
  76.    path appropriately for Telnet--but that's reasoning ahead of the
  77.    data. Suffice it to say that each piece should address Host-Host
  78.    protocol interpreter(s) integration as well as Host-Comm Subnet
  79.    Processor PI (including device driver, if one), plus something about
  80.    Telnet and something else about FTP (at least to the extent of
  81.    whether it's per-user or "monolithic"--on the server side, that is),
  82.    and, of course, some relevant anatomizing of the OS itself.
  83.  
  84.    The moral, it seems to me, is that we have a chance to strike back at
  85.    the oppressors by showing them what they should be furnishing with
  86.    their silly off-the-rack systems if they are going to continue to
  87.    object to our alterations to make the bloody things fit anywhere near
  88.    right. It's a little extra effort on our part, but it's probably a
  89.    worthy goal. Indeed, if anybody from IPTO is watching I suppose I'd
  90.    even go so far as to suggest a pro tem System Integration Task force
  91.    if I hadn't already volunteered once in this thing and used up my
  92.    quota.
  93.  
  94.    Think about it.
  95.  
  96. EDITOR'S NOTE
  97.  
  98.    The editor recalls a session at the 5th Data Communication Symposium
  99.    (the one at Snowbird) titled "Impact of Networks on Host-System
  100.    Design and Architecture". (1977)
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Padlipsky                                                       [Page 2]
  114.  
  115.