3.1. Requisiti di documentazione per le registrazioni
3.1. Requisiti di documentazione per le registrazioni (Documentation Requirements for Registrations)
Spesso, i documenti richiedono un'assegnazione in un registro esistente (uno creato da un documento pubblicato in precedenza).
Tali documenti dovrebbero identificare chiaramente il registro in cui deve essere registrato ciascun valore. Utilizzare il nome esatto del registro come elencato nella pagina web IANA e citare il RFC in cui è definito il registro. Quando si fa riferimento a un registro esistente, fornire un URL per identificare con precisione il registro è utile (vedere sezione 2.2).
Non è necessario menzionare quale sia la politica di assegnazione quando si effettuano nuove assegnazioni in registri esistenti, poiché ciò dovrebbe essere chiaro dai riferimenti. Tuttavia, se potrebbero applicarsi più politiche di assegnazione, come nei registri con intervalli diversi che hanno politiche diverse, è importante chiarire quale intervallo viene richiesto, in modo che IANA sappia quale politica si applica e possa assegnare un valore nell'intervallo corretto.
Assicurarsi di fornire tutte le informazioni richieste per una registrazione e seguire eventuali processi speciali stabiliti per il registro. I registri a volte richiedono il completamento di un modello di registrazione o chiedono ai registranti di pubblicare la loro richiesta su una particolare mailing list per la discussione prima della registrazione. Consultare il documento di riferimento del registro: le informazioni richieste e i processi speciali dovrebbero essere documentati lì.
Normalmente, i valori numerici da utilizzare sono scelti da IANA quando il documento è approvato; le bozze non dovrebbero specificare valori finali. Invece, dovrebbero essere usati segnaposto come "TBD1" e "TBD2" in modo coerente in tutto il documento, assegnando a ciascun elemento da registrare un segnaposto diverso. Le considerazioni IANA dovrebbero chiedere all'editor RFC di sostituire i nomi dei segnaposto con i valori assegnati da IANA. Quando le bozze devono specificare valori numerici per test o implementazioni anticipate, richiederanno un'allocazione anticipata (vedere sezione 3.4) o useranno valori già riservati per test o sperimentazione (se il registro in questione lo consente senza assegnazione esplicita). È importante che le bozze non scelgano i propri valori, per evitare che IANA assegni uno di quei valori a un altro documento nel frattempo. Una bozza può richiedere un valore specifico nella sezione Considerazioni IANA e IANA accoglierà tali richieste quando possibile, ma il numero proposto potrebbe essere stato assegnato ad altro uso quando la bozza viene approvata.
Normalmente, i valori di stringa di testo da utilizzare sono specificati nel documento, poiché le collisioni sono meno probabili con le stringhe di testo. IANA consulterà gli autori se si verifica effettivamente una collisione e deve essere utilizzato un valore diverso. Quando le bozze devono specificare valori di stringa per test o implementazioni anticipate, a volte usano il valore finale atteso. Ma è spesso utile utilizzare invece un valore di bozza, possibilmente includendo il numero di versione della bozza. Ciò consente di distinguere le implementazioni anticipate da quelle che implementano la versione finale. Un documento che intende utilizzare "foobar" nella versione finale potrebbe utilizzare "foobar-testing-draft-05" per la versione -05 della bozza, ad esempio.
Per alcuni registri, esiste una politica di lunga data che vieta l'assegnazione di nomi o codici su base vanità o nome dell'organizzazione. Ad esempio, i codici potrebbero essere sempre assegnati in sequenza a meno che non ci sia un motivo forte per fare un'eccezione. Nulla in questo documento è inteso a modificare tali politiche o impedirne l'applicazione futura.
Come esempio, il seguente testo potrebbe essere utilizzato per richiedere l'assegnazione di un numero di opzione DHCPv6:
Si chiede a IANA di assegnare un valore di codice opzione di TBD1 all'opzione
DNS Recursive Name Server e un valore di codice opzione di TBD2 all'opzione
Domain Search List dallo spazio dei codici opzione DHCP definito nella
sezione 24.3 del RFC 3315.
La sezione Considerazioni IANA dovrebbe riassumere tutte le azioni IANA, con puntatori alle sezioni pertinenti altrove nel documento, se appropriato. L'inclusione di numeri di sezione è particolarmente utile quando il documento di riferimento è grande; i numeri di sezione renderanno più facile per coloro che cercano nel documento di riferimento trovare le informazioni pertinenti.
Quando vengono richiesti più valori, è generalmente utile includere una tabella riepilogativa delle aggiunte/modifiche. È anche utile che questa tabella sia nello stesso formato in cui appare o apparirà sul sito web IANA. Per esempio:
Value Description Reference
-------- ------------------- ---------
TBD1 Foobar this RFC, Section 3.2
TBD2 Gumbo this RFC, Section 3.3
TBD3 Banana this RFC, Section 3.4
Nota: Nei casi in cui gli autori ritengono che includere la tabella completa delle modifiche sia troppo prolisso o ripetitivo, gli autori dovrebbero comunque includere la tabella nella bozza, ma possono includere una nota chiedendo che la tabella venga rimossa prima della pubblicazione del RFC finale.