RFC72 - Proposed Moratorium on Changes to Network Protocol

2019-11-04 11:29:47

字體：大中小

供稿：網(wǎng)友

　　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 RFCNo. 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 RFC72 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 RFC72 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 RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by Bob Hinden 6/97 ]

上一篇：RFC73 - Response to NWG/RFC67

下一篇：RFC76 - Connection by name: User oriented protocol