1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
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]
|
