Browse Prior Art Database

Proposed Moratorium on Changes to Network Protocol (RFC0072) Disclosure Number: IPCOM000003765D
Original Publication Date: 1970-Sep-28
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 4K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.D. Bressler: AUTHOR


Bill Crowther's RFC No. 67 raised a much more fundamental issue

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 72% of the total text.

Network Working Group Robert D. Bressler

Request for Comments #72 M.I.T./Project MAC

September 28, 1970


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.

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...