Introduction
Le RFC n° 67 de Bill Crowther a soulevé une question bien plus fondamentale que celle du marquage. Toute modification du protocole actuellement établi entraînera des changements dans les efforts de développement du matériel et du logiciel qui, dans certains cas, se poursuivent depuis plus de 6 mois. Dans le cas de Multics, cet effort a produit des programmes soit complets, soit à un stade avancé de mise au point. Cela est sans doute vrai pour bien d'autres sites également.
Les arguments développés ici ne visent pas à dire que le protocole actuel est idéal, mais plutôt que tout le monde a convenu qu'il est viable et a commencé à le mettre en œuvre. Nous souhaiterions donc proposer un moratoire sur la plupart des modifications de ce protocole pour les 6 prochains mois, ou aussi longtemps qu'il faudra pour faire fonctionner ce système et observer ses caractéristiques.
Concrètement, cela signifie ne pas apporter de modifications qui n'affectent que l'efficacité ou la facilité de mise en œuvre. Si un problème de conception majeur est découvert, il devrait tout de même être soumis à l'examen, tout comme les questions qui représentent des extensions au système existant. Mais les modifications des détails du système actuel ne devraient pas être apportées.
Plusieurs points plaident en faveur de cet argument. Le premier, et peut-être le plus important, est de faire fonctionner le système le plus tôt possible. Les principaux avantages du réseau résideront dans les usages qui en seront faits, et le développement dans cette direction ne pourra vraiment démarrer tant que le réseau ne sera pas opérationnel. Nous estimons que, même si l'effort nécessaire pour reprogrammer une partie du NCP à une date ultérieure sera sans aucun doute plus important, il sera masqué par l'effort parallèle alors en cours concernant l'utilisation du réseau et le développement de niveaux supérieurs du réseau.
Un autre problème qui se pose immédiatement est de savoir ce qui devrait constituer une modification officielle du protocole. L'histoire du développement du protocole actuel montre qu'une fois une idée émise, elle est modifiée de nombreuses fois avant de recueillir l'accord général. Ainsi, chaque nouvelle suggestion de modification pourrait concevablement retarder de plusieurs mois le développement des programmes.
Enfin, il faut considérer qu'une idée peut s'avérer irréalisable une fois le réseau réellement en fonctionnement. N'importe laquelle des questions actuellement convenues peut être rouverte lorsque les essais à grande échelle commenceront.
Nous pensons que ces considérations sont suffisamment importantes pour geler le protocole de réseau, à moins que ne surviennent des problèmes rendant une certaine fonction impossible à mettre en œuvre. Les modifications qui ne viseraient alors qu'à une plus grande efficacité seraient reportées jusqu'à ce que le fonctionnement réel du réseau ait été testé.
Cela ne signifie pas que de nouvelles idées ou de nouveaux arguments ne doivent pas être présentés, mais qu'ils doivent l'être avec la compréhension qu'ils ne sont pas destinés à une mise en œuvre immédiate, mais plutôt à être discutés en vue d'une mise en œuvre ultérieure éventuelle. Cette notion pourrait se refléter dans le titre de tels documents : « Proposition de modifications postérieures au moratoire pour ... »
Note : Ce RFC a été mis sous forme lisible par machine pour être intégré aux archives RFC en ligne par Bob Hinden en juin 1997.