4. IL PERCORSO DEGLI STANDARD INTERNET
- IL PERCORSO DEGLI STANDARD INTERNET (THE INTERNET STANDARDS TRACK)
Le specifiche destinate a diventare Standard Internet evolvono attraverso un insieme di livelli di maturità noti come "percorso degli standard" (standards track). Questi livelli di maturità -- "Proposed Standard" (Standard proposto), "Draft Standard" (Bozza di standard) e "Standard" -- sono definiti e discussi nella sezione 4.1. Il modo in cui le specifiche avanzano lungo il percorso degli standard è descritto nella sezione 6.
Anche dopo che una specifica è stata adottata come Standard Internet, spesso si verifica un'ulteriore evoluzione basata sull'esperienza e sul riconoscimento di nuovi requisiti. La nomenclatura e le procedure di standardizzazione Internet prevedono la sostituzione dei vecchi Standard Internet con nuovi, e l'assegnazione di etichette descrittive per indicare lo stato degli Standard Internet "ritirati". Un insieme di livelli di maturità è definito nella sezione 4.2 per coprire queste e altre specifiche che non sono considerate sul percorso degli standard.
4.1 Livelli di maturità del percorso degli standard (Standards Track Maturity Levels)
Le specifiche Internet attraversano fasi di sviluppo, test e accettazione. All'interno del processo di standardizzazione Internet, queste fasi sono formalmente etichettate come "livelli di maturità".
Questa sezione descrive i livelli di maturità e le caratteristiche attese delle specifiche a ciascun livello.
4.1.1 Proposed Standard (Standard proposto)
Il livello di maturità di ingresso per il percorso degli standard è "Proposed Standard". Un'azione specifica dell'IESG è necessaria per spostare una specifica sul percorso degli standard al livello "Proposed Standard".
Una specifica Proposed Standard è generalmente stabile, ha risolto scelte di progettazione note, è ritenuta ben compresa, ha ricevuto una revisione comunitaria significativa e sembra godere di sufficiente interesse comunitario per essere considerata preziosa. Tuttavia, ulteriori esperienze potrebbero risultare in una modifica o addirittura nel ritiro della specifica prima che avanzi.
Di solito, né l'implementazione né l'esperienza operativa sono richieste per la designazione di una specifica come Proposed Standard. Tuttavia, tale esperienza è altamente auspicabile e rappresenterà generalmente un forte argomento a favore di una designazione Proposed Standard.
L'IESG può richiedere implementazione e/o esperienza operativa prima di concedere lo stato Proposed Standard a una specifica che influisce materialmente sui protocolli Internet di base o che specifica un comportamento che può avere un impatto operativo significativo su Internet.
Un Proposed Standard non dovrebbe avere omissioni tecniche note rispetto ai requisiti ad esso imposti. Tuttavia, l'IESG può rinunciare a questo requisito per consentire a una specifica di avanzare allo stato Proposed Standard quando è considerata utile e necessaria (e tempestiva) anche con omissioni tecniche note.
Gli implementatori dovrebbero trattare i Proposed Standards come specifiche immature. È auspicabile implementarli per acquisire esperienza e per validare, testare e chiarire la specifica. Tuttavia, poiché il contenuto dei Proposed Standards può essere modificato se vengono trovati problemi o identificate soluzioni migliori, il dispiegamento di implementazioni di tali standard in un ambiente sensibile alle interruzioni non è raccomandato.
4.1.2 Draft Standard (Bozza di standard)
Una specifica dalla quale sono state sviluppate almeno due implementazioni indipendenti e interoperabili da basi di codice diverse, e per la quale è stata ottenuta sufficiente esperienza operativa di successo, può essere elevata al livello "Draft Standard". Ai fini di questa sezione, "interoperabile" significa essere componenti funzionalmente equivalenti o intercambiabili del sistema o processo in cui sono utilizzati. Se è richiesta tecnologia brevettata o altrimenti controllata per l'implementazione, le implementazioni separate devono anche essere risultate da un esercizio separato del processo di licenza. L'elevazione a Draft Standard è un importante avanzamento di stato, che indica una forte convinzione che la specifica sia matura e sarà utile.
Il requisito di almeno due implementazioni indipendenti e interoperabili si applica a tutte le opzioni e funzionalità della specifica. Nei casi in cui una o più opzioni o funzionalità non sono state dimostrate in almeno due implementazioni interoperabili, la specifica può avanzare al livello Draft Standard solo se tali opzioni o funzionalità vengono rimosse.
Il presidente del gruppo di lavoro (Working Group) è responsabile della documentazione delle implementazioni specifiche che qualificano la specifica per lo stato Draft o Internet Standard insieme alla documentazione sui test di interoperazione di queste implementazioni. La documentazione deve includere informazioni sul supporto di ciascuna delle singole opzioni e funzionalità. Questa documentazione dovrebbe essere presentata al direttore di area (Area Director) con la richiesta di azione del protocollo. (vedere sezione 6)
Un Draft Standard deve essere ben compreso e noto per essere abbastanza stabile, sia nella sua semantica che come base per lo sviluppo di un'implementazione. Un Draft Standard può ancora richiedere esperienza sul campo aggiuntiva o più diffusa, poiché è possibile che le implementazioni basate su specifiche Draft Standard dimostrino comportamenti imprevisti quando sottoposte a un uso su larga scala in ambienti di produzione.
Un Draft Standard è normalmente considerato una specifica finale, e le modifiche probabilmente verranno apportate solo per risolvere problemi specifici incontrati. Nella maggior parte delle circostanze, è ragionevole per i fornitori distribuire implementazioni di Draft Standards in un ambiente sensibile alle interruzioni.
4.1.3 Internet Standard (Standard Internet)
Una specifica per la quale è stata ottenuta un'implementazione significativa ed esperienza operativa di successo può essere elevata al livello Internet Standard. Uno Standard Internet (che può essere semplicemente indicato come Standard) è caratterizzato da un alto grado di maturità tecnica e da una convinzione generalmente condivisa che il protocollo o servizio specificato fornisce un beneficio significativo alla comunità Internet.
Una specifica che raggiunge lo stato di Standard riceve un numero nella serie STD mantenendo il suo numero RFC.
4.2 Livelli di maturità non appartenenti al percorso degli standard (Non-Standards Track Maturity Levels)
Non tutte le specifiche sono sul percorso degli standard. Una specifica potrebbe non essere destinata a diventare uno Standard Internet, o potrebbe essere destinata a una eventuale standardizzazione ma non ancora pronta per entrare nel percorso degli standard. Una specifica potrebbe essere stata sostituita da uno Standard Internet più recente, o essere altrimenti caduta in disuso o in disfavore.
Le specifiche che non sono sul percorso degli standard sono etichettate con uno dei tre livelli di maturità "fuori percorso": "Experimental" (Sperimentale), "Informational" (Informativo) o "Historic" (Storico). I documenti che portano queste etichette non sono in alcun modo Standard Internet.
4.2.1 Experimental (Sperimentale)
La designazione "Experimental" denota tipicamente una specifica che fa parte di uno sforzo di ricerca o sviluppo. Tale specifica è pubblicata per l'informazione generale della comunità tecnica Internet e come registro archivistico del lavoro, soggetta solo a considerazioni editoriali e alla verifica che ci sia stata un'adeguata coordinazione con il processo di standardizzazione (vedere sotto). Una specifica sperimentale può essere il risultato di uno sforzo di ricerca Internet organizzato (ad es., un gruppo di ricerca dell'IRTF), di un gruppo di lavoro IETF, o può essere un contributo individuale.
4.2.2 Informational (Informativo)
Una specifica "Informational" è pubblicata per l'informazione generale della comunità Internet e non rappresenta un consenso o una raccomandazione della comunità Internet. La designazione Informational è destinata a consentire la tempestiva pubblicazione di una gamma molto ampia di documenti informativi responsabili da molte fonti, soggetti solo a considerazioni editoriali e alla verifica che ci sia stata un'adeguata coordinazione con il processo di standardizzazione (vedere sezione 4.2.3).
Le specifiche che sono state preparate al di fuori della comunità Internet e non sono incorporate nel processo di standardizzazione Internet da nessuna delle disposizioni della sezione 10 possono essere pubblicate come RFC informativi, con il permesso del proprietario e l'accordo dell'editor RFC.
4.2.3 Procedure per RFC sperimentali e informativi
A meno che non siano il risultato di un'azione di un gruppo di lavoro IETF, i documenti destinati a essere pubblicati con stato Experimental o Informational dovrebbero essere presentati direttamente all'editor RFC. L'editor RFC pubblicherà tutti tali documenti come Internet-Drafts che non sono già stati pubblicati come tali. Per differenziare questi Internet-Drafts, saranno etichettati o raggruppati nella directory I-D in modo che siano facilmente riconoscibili. L'editor RFC attenderà due settimane dopo questa pubblicazione per i commenti prima di procedere ulteriormente. Si prevede che l'editor RFC eserciti il suo giudizio riguardo all'idoneità editoriale di un documento per la pubblicazione con stato Experimental o Informational, e può rifiutare di pubblicare un documento che, nell'opinione esperta dell'editor RFC, non è correlato all'attività Internet o scende al di sotto dello standard tecnico e/o editoriale per i RFC.
Per garantire che le designazioni non appartenenti al percorso degli standard Experimental e Informational non siano utilizzate impropriamente per aggirare il processo di standardizzazione Internet, l'IESG e l'editor RFC hanno concordato che l'editor RFC farà riferimento all'IESG qualsiasi documento presentato per pubblicazione Experimental o Informational che, nell'opinione dell'editor RFC, possa essere correlato al lavoro svolto, o previsto di essere svolto, all'interno della comunità IETF. L'IESG esaminerà tale documento riferito entro un periodo di tempo ragionevole e raccomanderà che sia pubblicato come originariamente presentato o riferito all'IETF come contributo al processo di standardizzazione Internet.
Se (a) l'IESG raccomanda che il documento sia portato all'interno dell'IETF e fatto progredire nel contesto IETF, ma l'autore rifiuta di farlo, o (b) l'IESG considera che il documento proponga qualcosa che è in conflitto con, o è in realtà dannoso per, uno sforzo IETF stabilito, il documento può comunque essere pubblicato come RFC Experimental o Informational. In questi casi, tuttavia, l'IESG può inserire un testo di "disclaimer" appropriato nel RFC, sia nella o immediatamente dopo la sezione "Status of this Memo", per chiarire ai lettori le circostanze della sua pubblicazione.
I documenti proposti per RFC sperimentali e informativi dai gruppi di lavoro IETF passano attraverso la revisione dell'IESG. La revisione è avviata utilizzando il processo descritto nella sezione 6.1.1.
4.2.4 Historic (Storico)
Una specifica che è stata sostituita da una specifica più recente o che è per qualsiasi altro motivo considerata obsoleta è assegnata al livello "Historic". (I puristi hanno suggerito che la parola dovrebbe essere "Historical"; tuttavia, a questo punto l'uso di "Historic" è storico.)
Nota: Le specifiche del percorso degli standard normalmente non devono dipendere da altre specifiche del percorso degli standard che sono a un livello di maturità inferiore o da specifiche non appartenenti al percorso degli standard diverse dalle specifiche referenziate di altri enti di standardizzazione. (Vedere sezione 7.)