4. Scegliere una politica di registrazione e politiche note

4. Scegliere una politica di registrazione e politiche note (Choosing a Registration Policy and Well-Known Policies)

Una politica di registrazione (registration policy) è la politica che controlla come vengono accettate le nuove assegnazioni (assignments) in un registro (registry). La definizione della politica di registrazione richiede di considerare diversi aspetti.

Se lo spazio dei nomi (namespace) del registro è limitato, le assegnazioni devono essere effettuate con attenzione per evitare l'esaurimento.

Anche quando lo spazio è sostanzialmente illimitato, spesso è comunque opportuno avere almeno una revisione minima (review) prima dell'assegnazione al fine di:

• impedire l'accaparramento o lo spreco inutile di valori. Ad esempio, se lo spazio è costituito da stringhe di testo, può essere opportuno impedire che entità ottengano grandi insiemi di stringhe corrispondenti a nomi desiderabili (ad esempio nomi di aziende esistenti).

• fornire un controllo di plausibilità (sanity check) che la richiesta abbia effettivamente senso e sia necessaria. L'esperienza mostra che un minimo livello di revisione da parte di un esperto di materia (subject matter expert) è utile per evitare assegnazioni quando la richiesta è malformata o non è realmente necessaria (ad esempio, esiste già un'assegnazione per un servizio sostanzialmente equivalente).

Forse soprattutto, estensioni non revisionate possono incidere sull'interoperabilità (interoperability) e sulla sicurezza (security). Vedere [RFC6709].

Quando lo spazio dei nomi è sostanzialmente illimitato e non vi sono potenziali problemi di interoperabilità o sicurezza, i numeri assegnati (assigned numbers) possono di solito essere dati a chiunque senza revisione soggettiva. In tali casi, IANA (Internet Assigned Numbers Authority) può effettuare le assegnazioni direttamente, purché a IANA siano fornite istruzioni dettagliate su quali tipi di richieste deve concedere e possa farlo senza esercitare giudizio soggettivo.

Quando ciò non è vero, è necessario un certo livello di revisione. È però importante bilanciare revisione adeguata e facilità di registrazione. Spesso chi registra non partecipa all'IETF; le richieste provengono da altre organizzazioni di standard, da organizzazioni non direttamente coinvolte negli standard, da lavoro comunitario ad hoc (da un progetto open source, ad esempio), e così via. La registrazione non deve essere inutilmente difficile, inutilmente costosa (in termini di tempo e altre risorse), né inutilmente soggetta a rifiuto.

Se talvolta è necessario restringere ciò che si registra (ad esempio per risorse limitate come bit in un byte, o per elementi i cui valori non supportati possono danneggiare il funzionamento del protocollo), in molti casi è più importante che ciò che è in uso sia rappresentato nel registro. Criteri di revisione eccessivamente rigorosi e costi eccessivi (tempo e sforzo) scoraggiano i tentativi di registrazione. Se un registro non riflette gli elementi di protocollo effettivamente in uso, ciò può influire negativamente sul dispiegamento dei protocolli su Internet, e il registro stesso si svaluta.

Pertanto è importante riflettere specificamente sulla politica di registrazione, e non sceglierne una arbitrariamente né copiare testo da altri documenti. I working group e altri sviluppatori di documenti dovrebbero usare cautela nella scelta di politiche appropriate quando i loro documenti creano registri. Dovrebbero selezionare la politica meno rigorosa compatibile con le esigenze del registro, e cercare giustificazioni specifiche per politiche che richiedono un coinvolgimento significativo della comunità (più rigorose di Expert Review o Specification Required, in termini di politiche note). Le esigenze variano da registro a registro e, di fatto, nel tempo, e questo BCP (Best Current Practice) non sarà l'ultima parola sull'argomento.

Le politiche seguenti sono definite per uso comune. Coprono una gamma di politiche tipiche usate per descrivere le procedure di assegnazione di nuovi valori in uno spazio dei nomi. Non è strettamente richiesto che i documenti usino questi termini; l'esigenza reale è che le istruzioni a IANA siano chiare e prive di ambiguità. Tuttavia, l'uso di questi termini è fortemente raccomandato perché i loro significati sono ampiamente compresi. Politiche di nuova definizione, incluse quelle che combinano in modi originali elementi delle procedure associate a questi termini, possono essere usate se nessuna di queste politiche è adatta; includere una spiegazione del perché aiuterà il processo di revisione. I termini sono spiegati per intero nelle sottosezioni seguenti.

1. Private Use
2. Experimental Use
3. Hierarchical Allocation
4. First Come First Served
5. Expert Review
6. Specification Required
7. RFC Required
8. IETF Review
9. Standards Action
10. IESG Approval

Va notato che spesso ha senso partizionare uno spazio dei nomi in più categorie, con assegnazioni gestite diversamente in ciascuna categoria. Molti protocolli ora partizionano gli spazi dei nomi in due o più parti, con un intervallo riservato a Private Use o Experimental Use mentre altri intervalli sono riservati ad assegnazioni globalmente uniche secondo qualche processo di revisione. Dividere uno spazio dei nomi in intervalli consente politiche diverse per intervalli e casi d'uso diversi.

Allo stesso modo, spesso sarà utile specificare più politiche in parallelo, ciascuna usata in circostanze diverse. Per ulteriore discussione, vedere Sezione 4.12.

Esempi di RFC che specificano più politiche in parallelo:

• LDAP [RFC4520]
• TLS ClientCertificateType Identifiers [RFC5246] (come dettagliato nelle sottosezioni seguenti)
• MPLS Pseudowire Types Registry [RFC4446]