4.11. Utilizzo delle politiche di registrazione ben note

Poiché le politiche ben note beneficiano sia dell'esperienza della comunità che di una comprensione diffusa, il loro utilizzo è incoraggiato, e la creazione di nuove politiche deve essere accompagnata da una giustificazione ragionevole.

È anche accettabile citare una o più politiche ben note e includere linee guida aggiuntive su che tipo di considerazioni dovrebbero essere prese in considerazione dal processo di revisione.

Ad esempio, per le registrazioni di tipi di media [RFC6838], sono coperte diverse situazioni che implicano l'uso di IETF Review e Specification Required, includendo anche criteri aggiuntivi specifici che l'esperto designato dovrebbe seguire. Questo non intende rappresentare una procedura di registrazione, ma mostrare un esempio di ciò che può essere fatto quando devono essere coperte circostanze speciali.

Le politiche ben note da "First Come First Served" a "Standards Action" specificano una gamma di politiche in ordine crescente di rigore (utilizzando la numerazione dall'elenco completo nella Sezione 4):

4. First Come First Served (Primo arrivato, primo servito)

• Nessuna revisione, documentazione minima.

5 e 6 (di uguale rigore)

• 5. Expert Review (Revisione da parte di esperti): Revisione da parte di esperti con documentazione sufficiente per la revisione.
• 6. Specification Required (Specifica richiesta): Documentazione pubblica stabile significativa sufficiente per l'interoperabilità.

7. RFC Required (RFC richiesta)

• Qualsiasi pubblicazione RFC, IETF o un flusso non-IETF.

8. IETF Review (Revisione IETF)

• Pubblicazione RFC, solo flusso IETF, ma non deve essere Standards Track.

9. Standards Action (Azione degli standard)

• Pubblicazione RFC, flusso IETF, solo Standards Track o BCP.

Esempi di situazioni che potrebbero giustificare IETF Review o Standards Action includono quanto segue:

• Quando una risorsa è limitata, come i bit in un byte (o in due byte, o quattro), o numeri in un intervallo limitato. In questi casi, consentire registrazioni che non sono state attentamente esaminate e concordate dal consenso della comunità potrebbe esaurire troppo rapidamente i valori consentiti.

• Quando è necessaria una revisione approfondita della comunità per evitare di estendere o modificare il protocollo in modi che potrebbero essere dannosi. Un esempio è la definizione di nuovi codici di comando, in contrasto con le opzioni che utilizzano codici di comando esistenti: il primo potrebbe richiedere una politica rigorosa, mentre una politica più rilassata potrebbe essere adeguata per il secondo. Un altro esempio è la definizione di elementi di protocollo che cambiano la semantica delle operazioni esistenti.

• Quando ci sono implicazioni di sicurezza rispetto alla risorsa, ed è necessaria una revisione approfondita per garantire che il nuovo utilizzo sia valido. Esempi di ciò includono elenchi di algoritmi di hashing e crittografici accettabili e l'assegnazione di porte di trasporto nell'intervallo di sistema.

Quando si esamina un documento che chiede all'IANA di creare un nuovo registro o di modificare una politica di registrazione verso una politica più rigorosa di Expert Review o Specification Required, l'IESG dovrebbe richiedere una giustificazione per garantire che siano state considerate politiche più rilassate e che la politica più rigorosa sia quella giusta.

Di conseguenza, gli sviluppatori di documenti devono anticipare questo e documentare le loro considerazioni per la selezione della politica specificata (idealmente, nel documento stesso; in caso contrario, nel writeup del pastore). Allo stesso modo, il pastore del documento dovrebbe garantire che le politiche selezionate siano state giustificate prima di inviare il documento all'IESG.

Quando le specifiche vengono riviste, le politiche di registrazione dovrebbero essere esaminate alla luce dell'esperienza da quando le politiche sono state stabilite.