You are here: irt.org | RFCs | RFC72 [ previous next ]
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]