1 files changed, 180 insertions, 0 deletions
diff --git a/doc/rfc/rfc72.txt b/doc/rfc/rfc72.txt
new file mode 100644
index 0000000..d00ff93
--- /dev/null
+++ b/doc/rfc/rfc72.txt
@@ -0,0 +1,180 @@
+
+
+
+
+
+
+Network Working Group                                 Robert D. Bressler
+Request for Comments #72                              M.I.T./Project MAC
+                                                      September 28, 1970
+
+
+
+           PROPOSED MORATORIUM ON CHANGES TO NETWORK PROTOCOL
+
+
+       Bill Crowther's RFC No. 67 raised a much more  fundamental  issue
+
+   than  the  question  of marking.  Any change to presently established
+
+   protocol  is  going  to  involve  changes  in  the  hardware/software
+
+   development  efforts  that have, in some instances, been going on for
+
+   over 6 months.  In the case  of  Multics,  this  effort  has  yielded
+
+   programs  either  complete or in the advanced debugging stages.  This
+
+   is no doubt true for many other sites as well.
+
+
+       The arguments being developed  here  are  not  that  the  present
+
+   protocol  is  ideal,  but  rather that everyone has agreed that it is
+
+   workable and has begun implementation of it.  We would therefore like
+
+   to propose a moratorium on most changes to this protocol for the next
+
+   6 months, or however long it takes to get this system running and  to
+
+   observe its characteristics.
+
+
+       Specifically this means not making changes that only  effect  the
+
+   efficiency  or  ease of implementation.  If a major design problem is
+
+   uncovered it should still be brought forward  for  consideration,  as
+
+   could  issues that represent extensions to the existing system.  But,
+
+   changes to the details of the present system should not be made.
+
+
+       There are several points to be made in favor  of  this  argument.
+
+
+                                [Page 1]
+
+
+
+
+
+Network Working Group            RFC 72               Robert D. Bressler
+
+
+   The  first,  and  perhaps  the  most important, is getting the system
+
+   working as soon as possible.  The major benefits of the network  will
+
+   be  in the uses to which it is put, and development along those lines
+
+   cannot really get off its feet until the network is operational.   We
+
+   feel that, although the effort needed to reprogram part of the NCP at
+
+   a later date will undoubtedly be greater, it will be  hidden  by  the
+
+   parallel  effort  then  going  on  involving network usage and higher
+
+   level network development.
+
+
+       Another problem that immediately arises is what should constitute
+
+   an  official  change to the protocol.  The history of the development
+
+   of the current protocol shows that once an  idea  is  raised,  it  is
+
+   modified  many  times  before it is generally agreeable to all.  Thus
+
+   each new suggestion  for  change  could  conceivably  retard  program
+
+   development in terms of months.
+
+
+       Finally there  is  the  consideration  that  an  idea  may  prove
+
+   unfeasible  once  actual operation of the network begins.  Any one of
+
+   the currently agreed upon issues may  be  reopened  when  full  scale
+
+   testing begins to take place.
+
+
+       We think that these considerations are important enough to freeze
+
+   the  network  protocol  unless  any  problems arise that would make a
+
+   certain feature unimplementable.   Changes  then  leading  simply  to
+
+   greater  efficiency would be saved until actual network operation has
+
+   been tested.
+
+
+
+                                [Page 2]
+
+
+
+
+
+Network Working Group            RFC 72               Robert D. Bressler
+
+
+       This is not to say that new ideas  or  arguments  should  not  be
+
+   brought  forward,  but  that  they should be brought forward with the
+
+   understanding that they  are  not  to  be  considered  for  immediate
+
+   implementation but rather to be discussed with a view toward possible
+
+   later implementation.  This concept might  be  reflected  by  titling
+
+   such documents, "Proposal for Post-Moratorium Changes to ..."
+
+
+       [ This RFC was put into machine readable form for entry ]
+
+          [ into the online RFC archives by Bob Hinden 6/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                [Page 3]
+
+