Introduzione
L'RFC n. 67 di Bill Crowther ha sollevato una questione molto più fondamentale della questione della marcatura. Qualsiasi modifica al protocollo attualmente stabilito comporterà cambiamenti negli sforzi di sviluppo hardware/software che, in alcuni casi, vanno avanti da oltre 6 mesi. Nel caso di Multics, questo sforzo ha prodotto programmi completi o in fase avanzata di debug. Ciò è senza dubbio vero anche per molti altri siti.
Gli argomenti sviluppati qui non sono che il protocollo attuale sia ideale, ma piuttosto che tutti hanno convenuto che è attuabile e ne hanno iniziato l'implementazione. Vorremmo pertanto proporre una moratoria sulla maggior parte delle modifiche a questo protocollo per i prossimi 6 mesi, o comunque per il tempo necessario a far funzionare questo sistema e a osservarne le caratteristiche.
Concretamente, ciò significa non apportare modifiche che incidono solo sull'efficienza o sulla facilità di implementazione. Se viene scoperto un problema di progettazione importante, esso dovrebbe comunque essere presentato per esame, così come le questioni che rappresentano estensioni al sistema esistente. Ma non si dovrebbero apportare modifiche ai dettagli del sistema attuale.
Ci sono diversi punti a favore di questo argomento. Il primo, e forse il più importante, è far funzionare il sistema il prima possibile. I principali vantaggi della rete risiederanno negli usi a cui essa è destinata, e lo sviluppo in tal senso non può davvero decollare finché la rete non è operativa. Riteniamo che, sebbene lo sforzo necessario per riprogrammare parte dell'NCP in una data successiva sarà senza dubbio maggiore, esso sarà nascosto dallo sforzo parallelo che sarà allora in corso e che riguarda l'uso della rete e lo sviluppo della rete di livello superiore.
Un altro problema che sorge immediatamente è che cosa debba costituire una modifica ufficiale al protocollo. La storia dello sviluppo del protocollo attuale mostra che, una volta sollevata un'idea, essa viene modificata molte volte prima che sia generalmente accettabile per tutti. Così ogni nuovo suggerimento di modifica potrebbe verosimilmente ritardare di mesi lo sviluppo dei programmi.
Infine, c'è la considerazione che un'idea può rivelarsi irrealizzabile una volta iniziato il funzionamento effettivo della rete. Qualsiasi punto attualmente concordato può essere riaperto quando iniziano le prove su vasta scala.
Riteniamo che queste considerazioni siano abbastanza importanti da congelare il protocollo di rete, a meno che non sorgano problemi che rendano una certa funzionalità non implementabile. Le modifiche che portano semplicemente a una maggiore efficienza sarebbero allora rimandate fino a quando non sia stato collaudato il funzionamento effettivo della rete.
Ciò non significa che nuove idee o argomenti non debbano essere presentati, ma che dovrebbero esserlo con la consapevolezza che non sono da considerare per un'implementazione immediata, bensì da discutere in vista di una possibile implementazione futura. Questo concetto potrebbe essere rispecchiato intitolando tali documenti « Proposta di modifiche a ... dopo la moratoria ».
Nota: Questo RFC è stato reso in forma leggibile dalla macchina per l'inserimento negli archivi RFC online da Bob Hinden nel giugno 1997.