はじめに

Bill Crowther の RFC 67 は、マーキングの問題よりもはるかに根本的な問題を提起した。現在確立されているプロトコルへの変更は、ハードウェアおよびソフトウェア開発の作業に変更を伴う。その作業は、場合によっては 6 か月以上続いている。Multics の場合、この作業は、完成したプログラム、あるいは高度なデバッグ段階にあるプログラムをすでに生み出している。これは他の多くのサイトにとっても疑いなく当てはまる。

ここで展開している議論は、現在のプロトコルが理想的であるというものではなく、むしろ、それが実行可能であると全員が合意し、その実装を開始しているというものである。したがって我々は、このプロトコルへのほとんどの変更について、今後 6 か月間、あるいはこのシステムを稼働させその特性を観察するのに要する期間、モラトリアムを提案したい。

具体的には、効率や実装の容易さだけに影響する変更を行わないということである。主要な設計上の問題が明らかになった場合は、引き続き検討のために提出されるべきであり、既存のシステムへの拡張を表す問題も同様である。しかし、現在のシステムの細部への変更は行うべきではない。

この議論を支持する論点はいくつかある。第一の、そしておそらく最も重要な論点は、システムをできるだけ早く稼働させることである。ネットワークの主要な利点は、それがどのように利用されるかにあり、その方向での開発は、ネットワークが運用可能になるまでは本格的に動き出すことができない。後日 NCP の一部を再プログラミングするのに必要な作業は、疑いなくより大きくなるが、そのとき並行して進むネットワーク利用やより高水準のネットワーク開発に伴う作業に隠れてしまうと我々は考えている。

すぐに生じるもう一つの問題は、何がプロトコルへの公式の変更を構成するかということである。現在のプロトコルの開発の経緯を見ると、一つの着想が提起されると、全員が受け入れられるようになるまでに何度も修正される。したがって、新しい変更提案のたびに、プログラム開発が数か月単位で遅れかねない。

最後に、ネットワークの実際の運用が始まれば、ある着想が実現不可能であると判明するかもしれないという考慮がある。現在合意されている事項はどれも、本格的な試験が行われるようになれば再び議論の対象になりうる。

我々は、これらの考慮が、ある機能を実装不可能にするような問題が生じない限り、ネットワークプロトコルを凍結するのに十分重要であると考える。その場合、単により高い効率をもたらすだけの変更は、実際のネットワーク運用が試験されるまで保留されるであろう。

これは、新しい着想や議論を提起すべきでないという意味ではない。即時の実装のために検討されるのではなく、むしろ後日の実装の可能性を視野に入れて議論するために提起されるべきであるという理解のもとに提起すべきだという意味である。この考え方は、そのような文書に「モラトリアム後の〜への変更の提案」という表題を付けることに反映されるかもしれない。

注: この RFC は、Bob Hinden によって 1997 年 6 月に、オンライン RFC アーカイブへの登録のために機械可読形式にされた。