RFC 72

PROPOSED MORATORIUM ON CHANGES TO NETWORK PROTOCOL ✨

Okay bestie, the title block first 🎀. This is RFC 72 from the Network Working Group, written by Robert D. Bressler of M.I.T./Project MAC, dated September 28, 1970. The header doesn't list a category, and it doesn't say it obsoletes or updates anything 💅.

Bill Crowther's RFC No. 67 brought up something way bigger than marking 👀. Any change to the protocol that's already established means redoing hardware and software work that, in some cases, has been going on for over 6 months 😭. For Multics, that work has produced programs that are either finished or in the advanced debugging stage 🔥. It's probably the same story at lots of other sites too 🌸.

[Page 1]

Network Working Group RFC 72 Robert D. Bressler

Quick clarification: the point here isn't that the current protocol is perfect 🙈. The point is that everyone agreed it works and has already started building on it 🫶. So the proposal is a moratorium on most changes for the next 6 months, or however long it takes to get the system running and see how it actually behaves 🧚.

Specifically, that means no changes that only change efficiency or ease of implementation 💜. If someone finds a major design problem, it should still be brought up for discussion, and so should ideas that extend the existing system ✨. But the details of the current system shouldn't get changed 🙅‍♀️.

There are a few reasons this makes sense, and they're honestly kind of iconic 👑.

The first and most important one: get the system working ASAP 🚀. The real payoff of the network comes from what people do with it, and that kind of development can't really take off until the network is up and running 🦋. Yes, reprogramming part of the NCP later will take more effort, but that effort will get lost in the crowd of work happening at the same time on network usage and higher-level network development 💖.

Next problem: what counts as an official change to the protocol? The history of this protocol shows that once someone raises an idea, it gets modified many times before everybody agrees on it 😩. So every new suggestion could slow program development by months 💀.

[Page 2]

Network Working Group RFC 72 Robert D. Bressler

And finally, an idea that looked good on paper might turn out not to work once the network is actually running 🙈. Any of the issues everyone has agreed on so far could get reopened when full-scale testing starts 🍓.

So these points are important enough that the network protocol should be frozen, unless a problem comes up that makes some feature impossible to implement 🔒. Changes that just make things more efficient can wait until the network has actually been tested in operation 🌈.

That doesn't mean new ideas or arguments should stop 🙌. They should still be brought forward, just with the understanding that they aren't going to be implemented right away. They're for discussion, with possible implementation later on 💅. The suggested way to label these documents is "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]