6. IL PROCESSO DI STANDARDIZZAZIONE INTERNET
- IL PROCESSO DI STANDARDIZZAZIONE INTERNET (THE INTERNET STANDARDS PROCESS)
La meccanica del processo di standardizzazione Internet coinvolge decisioni dell'IESG riguardanti l'elevazione di una specifica sul percorso degli standard o il movimento di una specifica del percorso degli standard da un livello di maturità a un altro. Sebbene siano disponibili numerosi criteri ragionevolmente oggettivi (descritti di seguito e nella sezione 4) per guidare l'IESG nel prendere una decisione per spostare una specifica sul, lungo o fuori dal percorso degli standard, non esiste alcuna garanzia algoritmica di elevazione a o progressione lungo il percorso degli standard per qualsiasi specifica. Il giudizio collettivo esperto dell'IESG riguardo alla qualità tecnica di una specifica proposta per l'elevazione a o l'avanzamento nel percorso degli standard è una componente essenziale del processo decisionale.
6.1 Azioni di standardizzazione (Standards Actions)
Un'"azione di standardizzazione" -- inserire una particolare specifica nel, farla avanzare all'interno o rimuoverla dal percorso degli standard -- deve essere approvata dall'IESG.
6.1.1 Avvio dell'azione (Initiation of Action)
Una specifica che è destinata a entrare o avanzare nel percorso degli standard Internet deve prima essere pubblicata come Internet-Draft (vedere sezione 2.2) a meno che non sia cambiata dalla pubblicazione come RFC. Deve rimanere come Internet-Draft per un periodo di tempo, non inferiore a due settimane, che permetta una revisione comunitaria utile, dopo di che può essere avviata una raccomandazione per l'azione.
Un'azione di standardizzazione è avviata da una raccomandazione del gruppo di lavoro IETF responsabile di una specifica al suo direttore di area, copiata al segretariato IETF o, nel caso di una specifica non associata a un gruppo di lavoro, una raccomandazione di un individuo all'IESG.
6.1.2 Revisione e approvazione dell'IESG (IESG Review and Approval)
L'IESG determinerà se una specifica presentata ad essa secondo la sezione 6.1.1 soddisfa i criteri applicabili per l'azione raccomandata (vedere sezioni 4.1 e 4.2), e determinerà inoltre se la qualità tecnica e la chiarezza della specifica sono coerenti con quelle attese per il livello di maturità al quale la specifica è raccomandata.
Al fine di ottenere tutte le informazioni necessarie per effettuare queste determinazioni, in particolare quando la specifica è considerata dall'IESG estremamente importante in termini del suo potenziale impatto su Internet o sulla suite di protocolli Internet, l'IESG può, a sua discrezione, commissionare una revisione tecnica indipendente della specifica.
L'IESG invierà un avviso all'IETF della considerazione IESG in sospeso del documento o dei documenti per permettere una revisione finale da parte della comunità Internet generale. Questa notifica di "Last-Call" (ultimo appello) sarà via email alla mailing list IETF Announce. I commenti su un Last-Call saranno accettati da chiunque e dovrebbero essere inviati come indicato nell'annuncio del Last-Call.
Il periodo di Last-Call non sarà inferiore a due settimane, tranne nei casi in cui l'azione di standardizzazione proposta non è stata avviata da un gruppo di lavoro IETF, nel qual caso il periodo di Last-Call non sarà inferiore a quattro settimane. Se l'IESG ritiene che l'interesse della comunità sarebbe servito permettendo più tempo per i commenti, può decidere su un periodo di Last-Call più lungo o di prolungare esplicitamente un periodo di Last-Call corrente.
L'IESG non è vincolata dall'azione raccomandata quando la specifica è stata presentata. Ad esempio, l'IESG può decidere di considerare la specifica per la pubblicazione in una categoria diversa da quella richiesta. Se l'IESG determina ciò prima che il Last-Call sia emesso, allora il Last-Call dovrebbe riflettere la visione dell'IESG. L'IESG potrebbe anche decidere di cambiare la categoria di pubblicazione in base alla risposta a un Last-Call. Se questa decisione comporterebbe la pubblicazione di una specifica a un livello "superiore" rispetto a quello per cui era il Last-Call originale, dovrebbe essere emesso un nuovo Last-Call indicando la raccomandazione dell'IESG. Inoltre, l'IESG può decidere di raccomandare la formazione di un nuovo gruppo di lavoro nel caso di controversia significativa in risposta a un Last-Call per una specifica non proveniente da un gruppo di lavoro IETF.
In modo tempestivo dopo la scadenza del periodo di Last-Call, l'IESG prenderà la sua determinazione finale se approvare o meno l'azione di standardizzazione, e notificherà l'IETF della sua decisione via email alla mailing list IETF Announce.
6.1.3 Pubblicazione (Publication)
Se un'azione di standardizzazione è approvata, viene inviata una notifica all'editor RFC e copiata all'IETF con istruzioni per pubblicare la specifica come RFC. La specifica sarà a quel punto rimossa dalla directory Internet-Drafts.
Un riepilogo ufficiale delle azioni di standardizzazione completate e in sospeso apparirà in ogni numero della newsletter dell'Internet Society. Questo costituirà la "pubblicazione di record" per le azioni di standardizzazione Internet.
L'editor RFC pubblicherà periodicamente un RFC "Internet Official Protocol Standards" [1], riassumendo lo stato di tutte le specifiche di protocollo e servizio Internet.
6.2 Avanzamento nel percorso degli standard (Advancing in the Standards Track)
La procedura descritta nella sezione 6.1 è seguita per ogni azione che accompagna l'avanzamento di una specifica lungo il percorso degli standard.
Una specifica rimarrà al livello Proposed Standard per almeno sei (6) mesi.
Una specifica rimarrà al livello Draft Standard per almeno quattro (4) mesi, o fino a quando almeno una riunione IETF non si è svolta, a seconda di quale evento si verifichi per ultimo.
Questi periodi minimi sono destinati a garantire un'opportunità adeguata per la revisione della comunità senza impattare gravemente la tempestività. Questi intervalli saranno misurati dalla data di pubblicazione del o dei RFC corrispondenti, o, se l'azione non risulta nella pubblicazione di un RFC, la data dell'annuncio dell'approvazione dell'IESG dell'azione.
Una specifica può essere (anzi, è probabile che sia) rivista mentre avanza attraverso il percorso degli standard. A ciascuna fase, l'IESG determinerà l'ambito e l'importanza della revisione della specifica e, se necessario e appropriato, modificherà l'azione raccomandata. Sono attese revisioni minori, ma una revisione significativa può richiedere che la specifica accumuli più esperienza al suo livello di maturità attuale prima di progredire. Infine, se la specifica è stata modificata in modo molto significativo, l'IESG può raccomandare che la revisione sia trattata come un nuovo documento, rientrando nel percorso degli standard all'inizio.
Il cambio di stato comporterà la ripubblicazione della specifica come RFC, tranne nel caso raro in cui non ci sono stati cambiamenti nella specifica dall'ultima pubblicazione. Generalmente, i cambiamenti desiderati saranno "raggruppati" per l'incorporazione al livello successivo nel percorso degli standard. Tuttavia, il rinvio dei cambiamenti alla prossima azione di standardizzazione sulla specifica non sarà sempre possibile o desiderabile; ad esempio, un importante errore tipografico, o un errore tecnico che non rappresenta un cambiamento nella funzione complessiva della specifica, potrebbe dover essere corretto immediatamente. In tali casi, l'IESG o l'editor RFC può essere richiesto di ripubblicare il RFC (con un nuovo numero) con correzioni, e questo non resetterà l'orologio del tempo minimo al livello.
Quando una specifica del percorso degli standard non ha raggiunto il livello Internet Standard ma è rimasta allo stesso livello di maturità per ventiquattro (24) mesi, e ogni dodici (12) mesi successivamente fino a quando lo stato non viene cambiato, l'IESG esaminerà la vitalità dello sforzo di standardizzazione responsabile di quella specifica e l'utilità della tecnologia. Dopo ogni tale revisione, l'IESG approverà la terminazione o la continuazione dello sforzo di sviluppo, allo stesso tempo l'IESG deciderà di mantenere la specifica allo stesso livello di maturità o di spostarla allo stato Historic. Questa decisione sarà comunicata all'IETF via email alla mailing list IETF Announce per permettere alla comunità Internet un'opportunità di commentare. Questa disposizione non è destinata a minacciare uno sforzo di gruppo di lavoro legittimo e attivo, ma piuttosto a fornire un meccanismo amministrativo per terminare uno sforzo moribondo.
6.3 Revisione di uno standard (Revising a Standard)
Una nuova versione di uno Standard Internet stabilito deve progredire attraverso il processo completo di standardizzazione Internet come se fosse una specifica completamente nuova. Una volta che la nuova versione ha raggiunto il livello Standard, di solito sostituirà la versione precedente, che sarà spostata allo stato Historic. Tuttavia, in alcuni casi entrambe le versioni possono rimanere come Standard Internet per onorare i requisiti di una base installata. In questa situazione, la relazione tra la versione precedente e la nuova versione deve essere esplicitamente dichiarata nel testo della nuova versione o in un altro documento appropriato (ad es., una dichiarazione di applicabilità; vedere sezione 3.2).
6.4 Ritiro di uno standard (Retiring a Standard)
Man mano che la tecnologia cambia e matura, è possibile che una nuova specifica Standard sia così chiaramente superiore tecnicamente che una o più specifiche esistenti del percorso degli standard per la stessa funzione dovrebbero essere ritirate. In questo caso, o quando si ritiene per qualche altro motivo che una specifica esistente del percorso degli standard dovrebbe essere ritirata, l'IESG approverà un cambio di stato della o delle vecchie specifiche a Historic. Questa raccomandazione sarà emessa con le stesse procedure di Last-Call e notifica utilizzate per qualsiasi altra azione di standardizzazione. Una richiesta di ritiro di uno standard esistente può provenire da un gruppo di lavoro, un direttore di area o qualche altra parte interessata.
6.5 Risoluzione dei conflitti e appelli (Conflict Resolution and Appeals)
Le controversie sono possibili in varie fasi durante il processo IETF. Per quanto possibile, il processo è progettato in modo che possano essere fatti compromessi e raggiunto un vero consenso, tuttavia ci sono momenti in cui anche le persone più ragionevoli e competenti non sono in grado di concordare. Per raggiungere gli obiettivi di apertura ed equità, tali conflitti devono essere risolti attraverso un processo di revisione e discussione aperta. Questa sezione specifica le procedure che devono essere seguite per affrontare questioni di standard Internet che non possono essere risolte attraverso i normali processi mediante i quali i gruppi di lavoro IETF e altri partecipanti al processo di standardizzazione Internet raggiungono ordinariamente il consenso.
6.5.1 Controversie di gruppo di lavoro (Working Group Disputes)
Un individuo (sia esso un partecipante al gruppo di lavoro rilevante o meno) può essere in disaccordo con una raccomandazione del gruppo di lavoro sulla base della sua convinzione che (a) le sue opinioni non sono state adeguatamente considerate dal gruppo di lavoro, o (b) il gruppo di lavoro ha fatto una scelta tecnica errata che mette in pericolo significativo la qualità e/o l'integrità del prodotto o dei prodotti del gruppo di lavoro. La prima questione è una difficoltà con il processo del gruppo di lavoro; la seconda è un'affermazione di errore tecnico. Questi due tipi di disaccordo sono abbastanza diversi, ma entrambi sono gestiti dallo stesso processo di revisione.
Una persona che è in disaccordo con una raccomandazione del gruppo di lavoro deve sempre prima discutere la questione con il presidente o i presidenti del gruppo di lavoro, che possono coinvolgere altri membri del gruppo di lavoro (o il gruppo di lavoro nel suo insieme) nella discussione.
Se il disaccordo non può essere risolto in questo modo, una qualsiasi delle parti coinvolte può portarlo all'attenzione del direttore o dei direttori di area per l'area in cui il gruppo di lavoro è costituito. Il direttore o i direttori di area tenteranno di risolvere la controversia.
Se il disaccordo non può essere risolto dal direttore o dai direttori di area, una qualsiasi delle parti coinvolte può quindi appellarsi all'IESG nel suo insieme. L'IESG esaminerà quindi la situazione e tenterà di risolverla in un modo di sua scelta.
Se il disaccordo non viene risolto con soddisfazione delle parti a livello di IESG, una qualsiasi delle parti coinvolte può appellare la decisione all'IAB. L'IAB esaminerà quindi la situazione e tenterà di risolverla in un modo di sua scelta.
La decisione dell'IAB è finale per quanto riguarda la questione se le procedure di standardizzazione Internet siano state seguite o meno e per quanto riguarda tutte le questioni di merito tecnico.
6.5.2 Fallimenti di processo (Process Failures)
Questo documento stabilisce procedure che devono essere seguite per garantire l'apertura e l'equità del processo di standardizzazione Internet, e la vitalità tecnica degli standard creati. L'IESG è l'agente principale dell'IETF per questo scopo, ed è l'IESG che è incaricato di garantire che le procedure richieste siano state seguite e che tutti i prerequisiti necessari a un'azione di standardizzazione siano stati soddisfatti.
Se un individuo dovesse essere in disaccordo con un'azione intrapresa dall'IESG in questo processo, quella persona dovrebbe prima discutere la questione con il presidente dell'IESG. Se il presidente dell'IESG non è in grado di soddisfare il querelante, allora l'IESG nel suo insieme dovrebbe riesaminare l'azione intrapresa, insieme all'input del querelante, e determinare se sono necessarie ulteriori azioni. L'IESG emetterà un rapporto sulla sua revisione del reclamo all'IETF.
Se il querelante non è soddisfatto dell'esito della revisione dell'IESG, può essere presentato un appello all'IAB. L'IAB esaminerà quindi la situazione e tenterà di risolverla in un modo di sua scelta e riferirà all'IETF sull'esito della sua revisione.
Se le circostanze lo giustificano, l'IAB può ordinare che una decisione dell'IESG sia annullata, e la situazione sarà quindi come era prima che la decisione dell'IESG fosse presa. L'IAB può anche raccomandare un'azione all'IESG, o fare altre raccomandazioni che ritiene appropriate. L'IAB non può, tuttavia, prevaricaresuper il ruolo dell'IESG emettendo una decisione che solo l'IESG è autorizzato a prendere.
La decisione dell'IAB è finale per quanto riguarda la questione se le procedure di standardizzazione Internet siano state seguite o meno.
6.5.3 Questioni di procedura applicabile (Questions of Applicable Procedure)
Ulteriore ricorso è disponibile solo nei casi in cui le procedure stesse (cioè le procedure descritte in questo documento) sono rivendicate essere inadeguate o insufficienti alla protezione dei diritti di tutte le parti in un processo di standardizzazione Internet equo e aperto. Le rivendicazioni su questa base possono essere fatte al consiglio di amministrazione dell'Internet Society. Il presidente dell'Internet Society riconoscerà tale appello entro due settimane e al momento del riconoscimento avviserà il richiedente della durata prevista della revisione dell'appello da parte degli amministratori. Gli amministratori esamineranno la situazione in un modo di loro scelta e riferiranno all'IETF sull'esito della loro revisione.
La decisione degli amministratori al completamento della loro revisione sarà finale per quanto riguarda tutti gli aspetti della controversia.
6.5.4 Procedura di appello (Appeals Procedure)
Tutti gli appelli devono includere una descrizione dettagliata e specifica dei fatti della controversia.
Tutti gli appelli devono essere avviati entro due mesi dalla conoscenza pubblica dell'azione o decisione da contestare.
In tutte le fasi del processo di appello, gli individui o enti responsabili delle decisioni hanno la discrezione di definire le procedure specifiche che seguiranno nel processo di prendere la loro decisione.
In tutti i casi una decisione riguardante la disposizione della controversia, e la comunicazione di tale decisione alle parti coinvolte, deve essere compiuta entro un periodo di tempo ragionevole.
[NOTA: Queste procedure intenzionalmente ed esplicitamente non stabiliscono un periodo di tempo massimo fisso che sarebbe considerato "ragionevole" in tutti i casi. Il processo di standardizzazione Internet pone un premio sul consenso e sugli sforzi per raggiungerlo, e rinuncia deliberatamente all'esecuzione deterministicamente rapida delle procedure a favore di una latitudine entro la quale possono essere raggiunti accordi tecnici più genuini.]