home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 00s / rfc72.txt < prev    next >
Text File  |  1997-06-09  |  4KB  |  181 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                 Robert D. Bressler
  8. Request for Comments #72                              M.I.T./Project MAC
  9.                                                       September 28, 1970
  10.  
  11.  
  12.  
  13.            PROPOSED MORATORIUM ON CHANGES TO NETWORK PROTOCOL
  14.  
  15.  
  16.        Bill Crowther's RFC No. 67 raised a much more  fundamental  issue
  17.  
  18.    than  the  question  of marking.  Any change to presently established
  19.  
  20.    protocol  is  going  to  involve  changes  in  the  hardware/software
  21.  
  22.    development  efforts  that have, in some instances, been going on for
  23.  
  24.    over 6 months.  In the case  of  Multics,  this  effort  has  yielded
  25.  
  26.    programs  either  complete or in the advanced debugging stages.  This
  27.  
  28.    is no doubt true for many other sites as well.
  29.  
  30.  
  31.        The arguments being developed  here  are  not  that  the  present
  32.  
  33.    protocol  is  ideal,  but  rather that everyone has agreed that it is
  34.  
  35.    workable and has begun implementation of it.  We would therefore like
  36.  
  37.    to propose a moratorium on most changes to this protocol for the next
  38.  
  39.    6 months, or however long it takes to get this system running and  to
  40.  
  41.    observe its characteristics.
  42.  
  43.  
  44.        Specifically this means not making changes that only  effect  the
  45.  
  46.    efficiency  or  ease of implementation.  If a major design problem is
  47.  
  48.    uncovered it should still be brought forward  for  consideration,  as
  49.  
  50.    could  issues that represent extensions to the existing system.  But,
  51.  
  52.    changes to the details of the present system should not be made.
  53.  
  54.  
  55.        There are several points to be made in favor  of  this  argument.
  56.  
  57.  
  58.                                 [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. Network Working Group            RFC 72               Robert D. Bressler
  65.  
  66.  
  67.    The  first,  and  perhaps  the  most important, is getting the system
  68.  
  69.    working as soon as possible.  The major benefits of the network  will
  70.  
  71.    be  in the uses to which it is put, and development along those lines
  72.  
  73.    cannot really get off its feet until the network is operational.   We
  74.  
  75.    feel that, although the effort needed to reprogram part of the NCP at
  76.  
  77.    a later date will undoubtedly be greater, it will be  hidden  by  the
  78.  
  79.    parallel  effort  then  going  on  involving network usage and higher
  80.  
  81.    level network development.
  82.  
  83.  
  84.        Another problem that immediately arises is what should constitute
  85.  
  86.    an  official  change to the protocol.  The history of the development
  87.  
  88.    of the current protocol shows that once an  idea  is  raised,  it  is
  89.  
  90.    modified  many  times  before it is generally agreeable to all.  Thus
  91.  
  92.    each new suggestion  for  change  could  conceivably  retard  program
  93.  
  94.    development in terms of months.
  95.  
  96.  
  97.        Finally there  is  the  consideration  that  an  idea  may  prove
  98.  
  99.    unfeasible  once  actual operation of the network begins.  Any one of
  100.  
  101.    the currently agreed upon issues may  be  reopened  when  full  scale
  102.  
  103.    testing begins to take place.
  104.  
  105.  
  106.        We think that these considerations are important enough to freeze
  107.  
  108.    the  network  protocol  unless  any  problems arise that would make a
  109.  
  110.    certain feature unimplementable.   Changes  then  leading  simply  to
  111.  
  112.    greater  efficiency would be saved until actual network operation has
  113.  
  114.    been tested.
  115.  
  116.  
  117.  
  118.                                 [Page 2]
  119.  
  120.  
  121.  
  122.  
  123.  
  124. Network Working Group            RFC 72               Robert D. Bressler
  125.  
  126.  
  127.        This is not to say that new ideas  or  arguments  should  not  be
  128.  
  129.    brought  forward,  but  that  they should be brought forward with the
  130.  
  131.    understanding that they  are  not  to  be  considered  for  immediate
  132.  
  133.    implementation but rather to be discussed with a view toward possible
  134.  
  135.    later implementation.  This concept might  be  reflected  by  titling
  136.  
  137.    such documents, "Proposal for Post-Moratorium Changes to ..."
  138.  
  139.  
  140.        [ This RFC was put into machine readable form for entry ]
  141.  
  142.           [ into the online RFC archives by Bob Hinden 6/97 ]
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.                                 [Page 3]
  179.  
  180.  
  181.