Index Journeys
RFC 73 UNKNOWN META · DECISIONS

Response to NWG/RFC 67

An early 1970 response cautioning against premature protocol changes.

On rfc-editor.org ↗
PUBLISHED
September 1970
AUTHORS
S.D. Crocker
STREAM
Legacy
DOI
10.17487/RFC0073

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
Network Working Group                                   S. Crocker
Request for Comments #73                                UCLA
                                                        25 Sept. 70

                        Response to NWM/RFC #67

Bill's suggestion is a good one; however, my current policy is to
encourage the most rapid implementation of the protocol in document
#1, and his suggested modification should be delayed.  It seems to me
most important to gain experience using the network before making
changes to the protocol which are not dictated by necessity.  (I
polled several sites regarding Bill's suggestion.  Sites with NCP
implementations under way tended to agree with this policy, while
sites further behind tended to desire Bill's suggested change.)

With respect to changes, in general, I believe that changes are
necessary to improve the efficiency, provide greater flexibility, and
guarantee reliability.  Many of us can suggest changes now, but I
suspect that clearer ideas will emerge from usage.

       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Josh Elliott 1/98 ]

AI ELI5

On this page
PROBLEMThere were suggestions to modify the early network protocol, but early implementers disagreed about whether to adopt them.
MECHANISMThe RFC author argues for prioritizing implementation and field experience before making non-critical changes, polling sites to validate this policy.
WHY IT MATTERSThe focus remained on implementing the existing protocol first and gathering real-world experience before designing improvements.

§1Response to Protocol Change Suggestions

RFC 73 is a brief response by Steve Crocker addressing a proposal in RFC 67 to modify the host-IMP specification. The author acknowledges that the suggestion is reasonable but argues against adopting it at that time.

The policy prioritized rapid implementation of the existing protocol over premature modifications. Crocker had polled several network sites and found that those actively implementing the network control program (NCP) agreed with this cautious approach, while sites with less implementation progress wanted the suggested change.

Someone wanted to change how the network worked, but the author polled the other groups and found that the ones building systems wanted to build with what they had first.

§2Learning from Experience

The author makes the case that while improvements are necessary in the long term, clearer ideas about what needs to change will emerge from actual use of the network. Making changes now without field experience risks introducing problems or solving the wrong problems.

The RFC reflects the early experimental nature of the network: the focus was on building working implementations first, documenting lessons learned, and then making informed decisions about protocol improvements.

You learn what needs fixing by actually using something, not by guessing before you build it.

§3Why This Matters

This brief document captures an important moment in network design: the decision to stabilize an experimental protocol and gain operational experience before continuing major changes. This approach influenced how the early ARPA network evolved through multiple iterations as understanding improved.

The early builders learned that it was smarter to get something working first and then improve it, rather than redesign everything before anyone tried it.