Proposed Moratorium on Changes to Network Protocol
A proposal to pause most protocol changes while implementation proceeds.
Bressler, R.D., "Proposed Moratorium on Changes to Network Protocol", RFC 72, DOI 10.17487/RFC0072, September 1970, <https://www.rfc-editor.org/info/rfc72>.
@misc{rfc72,
series = {Request for Comments},
number = 72,
howpublished = {RFC 72},
publisher = {RFC Editor},
doi = {10.17487/RFC0072},
url = {https://www.rfc-editor.org/info/rfc72},
author = {R.D. Bressler},
title = {{Proposed Moratorium on Changes to Network Protocol}},
pagetotal = 4,
year = 1970,
month = sep,
} RFC text
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 ]
ISO Plain Language
On this page
§1The Cost of Changing an Implemented Protocol
Robert Bressler says changes to the established protocol would affect hardware and software work that had been underway for more than 6 months at some sites. In the case of Multics, programs were complete or in advanced debugging.
The author argues that sites had agreed the protocol was workable and had begun implementation, even if it was not ideal.
Some sites had already spent months building against the agreed protocol. Changing it could force them to revise work that was complete or being debugged.
§1What the Moratorium Would Allow
The proposal is a moratorium on most changes for the next 6 months, or until the system is running and its characteristics can be observed. Changes that only improve efficiency or ease of implementation should wait.
A major design problem should still be brought forward, as may an extension to the existing system. The author says details of the present system should not otherwise change during the moratorium.
The proposed pause would defer efficiency improvements and implementation changes. It would still allow discussion of major design problems and new extensions.
§1Why Wait for Operational Experience
The author argues that the network should become operational as soon as possible so people can develop uses for it. He says changes can be judged more clearly after actual operation, because a feature may prove unworkable or a proposed improvement may address the wrong problem.
New ideas should still be raised and discussed, but the author suggests labeling them as proposals for post-moratorium changes rather than immediate implementation.
The proposal is to get the system running and learn from its use before making nonessential changes. People can still discuss ideas and consider implementing them later.