5. Designated Experts (Esperti designati)

5.1. The Motivation for Designated Experts (La motivazione per gli esperti designati)

Le discussioni su una mailing list possono fornire feedback tecnici preziosi, ma le opinioni spesso variano e le discussioni possono continuare per qualche tempo senza una chiara risoluzione. Inoltre, IANA non può partecipare a tutte queste mailing list e non può determinare se o quando tali discussioni raggiungono un consenso. Pertanto, IANA si affida a un "esperto designato" (designated expert) per consigli riguardanti la questione specifica se un'assegnazione debba essere effettuata. L'esperto designato è un individuo responsabile di condurre una valutazione appropriata e di restituire una raccomandazione a IANA.

Va notato che una motivazione chiave per avere esperti designati è che l'IETF fornisca a IANA un esperto in materia (subject matter expert) a cui il processo di valutazione può essere delegato. IANA inoltra le richieste di assegnazione all'esperto per la valutazione, e l'esperto (dopo aver eseguito la valutazione) informa IANA se effettuare o meno l'assegnazione o la registrazione. Nella maggior parte dei casi, i registranti non lavorano direttamente con gli esperti designati. L'elenco degli esperti designati per un registro è elencato nel registro stesso.

Sarà spesso utile utilizzare un esperto designato solo in alcuni momenti, come supplemento ad altri processi. Per ulteriori discussioni su questo argomento, vedere la Sezione 4.12.

5.2. The Role of the Designated Expert (Il ruolo dell'esperto designato)

L'esperto designato è responsabile del coordinamento della revisione appropriata di una richiesta di assegnazione. La revisione può essere ampia o ristretta, a seconda della situazione e del giudizio dell'esperto designato. Questo può comportare la consultazione con un insieme di esperti tecnologici, la discussione su una mailing list pubblica, la consultazione con un gruppo di lavoro (o la sua mailing list se il gruppo di lavoro è stato sciolto), ecc. Idealmente, l'esperto designato segue criteri di revisione specifici come documentato nel protocollo che crea o utilizza lo spazio dei nomi. Vedere le sezioni IANA Considerations di [RFC3748] e [RFC3575] per esempi specifici.

Ci si aspetta che gli esperti designati siano in grado di difendere le loro decisioni alla comunità IETF, e il processo di valutazione non è destinato ad essere segreto o a conferire un potere indiscusso all'esperto. Ci si aspetta che gli esperti applichino le procedure di revisione o verifica documentate applicabili, o in assenza di criteri documentati, seguano norme generalmente accettate come quelle nella Sezione 5.3. Gli esperti designati generalmente non dovrebbero essere "custodi" (gatekeepers), cercando di rendere difficile ottenere registrazioni, a meno che le linee guida nel documento di definizione non specifichino che dovrebbero agire come tali. In assenza di linee guida più forti, gli esperti dovrebbero valutare le richieste di registrazione per completezza, interoperabilità e conflitti con protocolli e opzioni esistenti.

Si è dimostrato utile avere più esperti designati per alcuni registri. A volte questi esperti lavorano insieme nella valutazione di una richiesta, mentre in altri casi esperti aggiuntivi fungono da riserve, agendo solo quando l'esperto principale non è disponibile. Nei registri con un pool di esperti, il pool ha spesso un singolo presidente responsabile di definire come le richieste devono essere assegnate agli esperti e revisionate da essi. In altri casi, IANA potrebbe assegnare richieste a singoli membri in ordine sequenziale o approssimativamente casuale. Il documento che definisce il registro può, se appropriato per la situazione, specificare come il gruppo dovrebbe lavorare -- per esempio, potrebbe essere appropriato specificare un consenso approssimativo (rough consensus) su una mailing list, all'interno di un gruppo di lavoro correlato o tra un pool di esperti designati.

In caso di disaccordo tra più esperti, è responsabilità di questi esperti formulare una singola raccomandazione chiara a IANA. Non è appropriato che IANA risolva le dispute tra esperti. In situazioni estreme, come uno stallo, l'organismo designante potrebbe dover intervenire per risolvere il problema.

Se un esperto designato ha un conflitto di interessi per una particolare revisione (è, ad esempio, un autore o un significativo sostenitore di una specifica relativa alla registrazione in esame), quell'esperto dovrebbe astenersi. Nel caso in cui tutti gli esperti designati siano in conflitto, dovrebbero richiedere che venga designato un esperto temporaneo per la revisione conflittuale. Il direttore di area (AD) responsabile può quindi nominare qualcuno o l'AD può gestire la revisione.

Questo documento definisce il meccanismo dell'esperto designato solo rispetto ai documenti nel flusso IETF (IETF stream). Se altri flussi desiderano utilizzare politiche di registrazione che richiedono esperti designati, spetta a quei flussi (o a quei documenti) specificare come tali esperti designati vengono nominati e gestiti. Ciò che è descritto di seguito, con la gestione da parte dell'IESG, è appropriato solo per il flusso IETF.

5.2.1. Managing Designated Experts in the IETF (Gestione degli esperti designati nell'IETF)

Gli esperti designati per i registri creati dall'IETF sono nominati dall'IESG, normalmente su raccomandazione del direttore di area (Area Director) pertinente. Possono essere nominati al momento in cui un documento che crea o aggiorna uno spazio dei nomi viene approvato dall'IESG, o successivamente, quando viene ricevuta la prima richiesta di registrazione. Poiché gli esperti originariamente nominati potrebbero successivamente diventare non disponibili, l'IESG nominerà sostituti secondo necessità. L'IESG può rimuovere qualsiasi esperto designato che ha nominato, a sua discrezione.

Il normale processo di appello, come descritto in [RFC2026], Sezione 6.5.1, si applica ai problemi che sorgono con il team di esperti designati. A questo scopo, il team di esperti designati prende il posto del gruppo di lavoro in quella descrizione.

5.3. Designated Expert Reviews (Revisioni degli esperti designati)

Negli anni trascorsi dalla pubblicazione e dall'utilizzo di [RFC2434], l'esperienza ha portato alle seguenti osservazioni:

Un esperto designato deve rispondere in modo tempestivo, normalmente entro una settimana per richieste semplici fino a poche settimane per quelle più complesse. Ritardi irragionevoli possono causare problemi significativi per coloro che necessitano di assegnazioni, come quando i prodotti necessitano di punti codice (code points) per la spedizione. Questo non significa che tutte le revisioni possano essere completate entro una scadenza rigida, ma devono essere avviate, e il richiedente e IANA dovrebbero avere una certa trasparenza nel processo se una risposta non può essere data rapidamente.
Se un esperto designato non risponde alle richieste di IANA entro un periodo di tempo ragionevole, né con una risposta né con una spiegazione ragionevole del ritardo (alcune richieste possono essere particolarmente complesse), e se questo è un evento ricorrente, IANA deve sollevare la questione con l'IESG. A causa dei problemi causati da valutazioni e assegnazioni ritardate, l'IESG dovrebbe intraprendere azioni appropriate per garantire che l'esperto comprenda e accetti le sue responsabilità, o nominare un nuovo esperto.
L'esperto designato non è tenuto a sopportare personalmente il carico di valutare e decidere tutte le richieste, ma agisce come pastore (shepherd) per la richiesta, arruolando l'aiuto di altri come appropriato. Nel caso in cui una richiesta venga negata, e il rifiuto della richiesta sia probabilmente controverso, l'esperto dovrebbe avere il supporto di altri esperti in materia. Cioè, l'esperto deve essere in grado di difendere una decisione alla comunità nel suo insieme.

Quando viene utilizzato un esperto designato, la documentazione dovrebbe fornire una guida chiara all'esperto designato, delineando i criteri per eseguire una valutazione e le ragioni per rifiutare una richiesta. Nel caso in cui non ci siano criteri specifici documentati, la presunzione dovrebbe essere che un punto codice debba essere concesso a meno che non ci sia una ragione convincente per il contrario (e vedere anche la Sezione 5.4). Le ragioni che sono state utilizzate per negare richieste hanno incluso:

Scarsità di punti codice, dove i punti codice finiti rimanenti dovrebbero essere gestiti con prudenza, o dove viene effettuata una richiesta per un gran numero di punti codice e un singolo punto codice è la norma.
La documentazione non è sufficientemente chiara per valutare o garantire l'interoperabilità.
Il punto codice è necessario per un'estensione di protocollo, ma l'estensione non è coerente con l'architettura documentata (o generalmente compresa) del protocollo base da estendere e sarebbe dannosa per il protocollo se ampiamente distribuita. Non è intenzione che "incoerenze" si riferiscano a differenze minori "di natura di preferenza personale". Invece, si riferiscono a differenze significative come incoerenze con il modello di sicurezza sottostante, implicando un cambiamento nella semantica di un tipo di messaggio o operazione esistente, richiedendo cambiamenti ingiustificati nei sistemi distribuiti (rispetto a modi alternativi di raggiungere un risultato simile), ecc.
L'estensione causerebbe problemi con i sistemi distribuiti esistenti.
L'estensione entrerebbe in conflitto con una in sviluppo attivo da parte dell'IETF, e avere entrambe danneggerebbe piuttosto che favorire l'interoperabilità.

I documenti non devono nominare l'esperto o gli esperti designati nel documento stesso; invece, eventuali nomi suggeriti dovrebbero essere trasmessi al direttore di area appropriato al momento in cui il documento viene inviato all'IESG per l'approvazione. Questo di solito viene fatto nel document shepherd writeup.

Se la richiesta dovrebbe essere anche rivista su una specifica mailing list pubblica, il suo indirizzo dovrebbe essere specificato.

5.4. Expert Reviews and the Document Lifecycle (Revisioni degli esperti e ciclo di vita del documento)

La revisione da parte dell'esperto designato viene necessariamente effettuata in un momento specifico e rappresenta la revisione di una versione particolare del documento. Mentre le revisioni vengono generalmente effettuate intorno al momento dell'IETF Last Call, decidere quando la revisione dovrebbe aver luogo è una questione di buon giudizio. E mentre le revisioni potrebbero essere effettuate quando è riconosciuto che la documentazione dell'elemento registrato è cambiata sostanzialmente, assicurarsi che la revisione avvenga richiede attenzione e cura.

È possibile, attraverso negligenza, incidente, disattenzione o anche deliberato disprezzo, che vengano effettuate modifiche dopo la revisione e l'approvazione dell'esperto designato che, se il documento fosse riesaminato, porterebbero l'esperto a non approvare la registrazione. Spetta all'IESG, con il token detenuto dal direttore di area responsabile, essere vigile su tali situazioni e riconoscere che tali cambiamenti devono essere verificati.

Per le registrazioni effettuate da documenti sul percorso degli standard (Standards Track), è spesso richiesta una revisione da parte di esperti (dalla politica di registrazione) in aggiunta al consenso IETF (per l'approvazione come RFC sul percorso degli standard). In tali casi, la revisione da parte dell'esperto designato deve essere tempestiva, presentata prima che l'IESG valuti il documento. L'IESG generalmente non dovrebbe trattenere il documento in attesa di una revisione tardiva. Non è inoltre previsto che la revisione dell'esperto annulli il consenso IETF: l'IESG dovrebbe considerare la revisione nella propria valutazione, come farebbe per altre revisioni di Last Call.