4.11. Verwendung der bekannten Registrierungsrichtlinien

Da die bekannten Richtlinien von der Erfahrung der Gemeinschaft und dem breiten Verständnis profitieren, wird ihre Verwendung gefördert, und die Erstellung neuer Richtlinien muss von einer angemessenen Begründung begleitet werden.

Es ist auch akzeptabel, eine oder mehrere bekannte Richtlinien zu zitieren und zusätzliche Leitlinien darüber aufzunehmen, welche Art von Überlegungen im Überprüfungsprozess berücksichtigt werden sollten.

Zum Beispiel werden bei Medientyp-Registrierungen [RFC6838] eine Reihe verschiedener Situationen abgedeckt, die die Verwendung von IETF Review und Specification Required beinhalten, während auch spezifische zusätzliche Kriterien enthalten sind, die der designierte Experte befolgen sollte. Dies soll nicht ein Registrierungsverfahren darstellen, sondern ein Beispiel zeigen, was getan werden kann, wenn besondere Umstände abgedeckt werden müssen.

Die bekannten Richtlinien von „First Come First Served" bis „Standards Action" spezifizieren eine Reihe von Richtlinien in aufsteigender Reihenfolge der Strenge (unter Verwendung der Nummerierung aus der vollständigen Liste in Abschnitt 4):

4. First Come First Served (Wer zuerst kommt, mahlt zuerst)

Keine Überprüfung, minimale Dokumentation.

5 und 6 (von gleicher Strenge)

5. Expert Review (Expertenprüfung): Expertenprüfung mit ausreichender Dokumentation für die Überprüfung.
6. Specification Required (Spezifikation erforderlich): Bedeutende stabile öffentliche Dokumentation ausreichend für Interoperabilität.

7. RFC Required (RFC erforderlich)

Jede RFC-Veröffentlichung, IETF oder ein nicht-IETF-Stream.

8. IETF Review (IETF-Überprüfung)

RFC-Veröffentlichung, nur IETF-Stream, muss aber nicht Standards Track sein.

9. Standards Action (Standards-Aktion)

RFC-Veröffentlichung, IETF-Stream, nur Standards Track oder BCP.

Beispiele für Situationen, die IETF Review oder Standards Action rechtfertigen könnten, umfassen Folgendes:

Wenn eine Ressource begrenzt ist, wie Bits in einem Byte (oder in zwei Bytes oder vier), oder Zahlen in einem begrenzten Bereich. In diesen Fällen könnte die Zulassung von Registrierungen, die nicht sorgfältig überprüft und durch Konsens der Gemeinschaft vereinbart wurden, die zulässigen Werte zu schnell erschöpfen.
Wenn eine gründliche Überprüfung durch die Gemeinschaft notwendig ist, um zu vermeiden, dass das Protokoll auf Weise erweitert oder modifiziert wird, die schädlich sein könnte. Ein Beispiel ist die Definition neuer Befehlscodes im Gegensatz zu Optionen, die bestehende Befehlscodes verwenden: Ersteres könnte eine strenge Richtlinie erfordern, während eine entspanntere Richtlinie für Letzteres angemessen sein könnte. Ein weiteres Beispiel ist die Definition von Protokollelementen, die die Semantik bestehender Operationen ändern.
Wenn es Sicherheitsauswirkungen in Bezug auf die Ressource gibt und eine gründliche Überprüfung erforderlich ist, um sicherzustellen, dass die neue Verwendung sinnvoll ist. Beispiele hierfür sind Listen akzeptabler Hash- und kryptografischer Algorithmen sowie die Zuweisung von Transportports im Systembereich.

Bei der Überprüfung eines Dokuments, das IANA auffordert, eine neue Registry zu erstellen oder eine Registrierungsrichtlinie auf eine Richtlinie zu ändern, die strenger als Expert Review oder Specification Required ist, sollte die IESG nach einer Begründung fragen, um sicherzustellen, dass entspanntere Richtlinien in Betracht gezogen wurden und dass die strengere Richtlinie die richtige ist.

Dementsprechend müssen Dokumententwickler dies antizipieren und ihre Überlegungen zur Auswahl der angegebenen Richtlinie dokumentieren (idealerweise im Dokument selbst; andernfalls im Shepherd-Writeup). Ebenso sollte der Dokument-Shepherd sicherstellen, dass die ausgewählten Richtlinien gerechtfertigt wurden, bevor das Dokument an die IESG gesendet wird.

Wenn Spezifikationen überarbeitet werden, sollten Registrierungsrichtlinien im Lichte der Erfahrungen seit der Festlegung der Richtlinien überprüft werden.