4. Registrierungsrichtlinie wählen und bekannte Richtlinien

4. Registrierungsrichtlinie wählen und bekannte Richtlinien (Choosing a Registration Policy and Well-Known Policies)

Eine Registrierungsrichtlinie (registration policy) ist die Richtlinie, die steuert, wie neue Zuweisungen (assignments) in einer Registry (Registrierung) angenommen werden. Bei der Definition der Registrierungsrichtlinie sind mehrere Aspekte zu bedenken.

Ist der Namensraum (namespace) der Registry begrenzt, müssen Zuweisungen sorgfältig erfolgen, um Erschöpfung zu vermeiden.

Selbst wenn der Raum praktisch unbegrenzt ist, ist es oft dennoch wünschenswert, vor der Zuweisung zumindest eine minimale Prüfung (review) durchzuführen, um:

• Horten oder unnötiges Verschwenden von Werten zu verhindern. Besteht der Raum etwa aus Textketten, kann es wünschenswert sein zu verhindern, dass große Mengen von Ketten erwünschter Namen (z. B. bestehende Firmennamen) beansprucht werden.

• eine Plausibilitätsprüfung (sanity check) zu ermöglichen, ob die Anfrage sinnvoll und nötig ist. Die Erfahrung zeigt, dass eine minimale Prüfung durch einen Fachexperten (subject matter expert) hilft, Zuweisungen zu vermeiden, wenn die Anfrage fehlerhaft oder unnötig ist (z. B. wenn bereits eine Zuweisung für einen im Wesentlichen gleichwertigen Dienst existiert).

Vor allem können ungeprüfte Erweiterungen Interoperabilität (interoperability) und Sicherheit (security) beeinträchtigen. Siehe [RFC6709].

Ist der Namensraum praktisch unbegrenzt und gibt es keine potenziellen Interoperabilitäts- oder Sicherheitsfragen, können zugewiesene Nummern (assigned numbers) in der Regel ohne subjektive Prüfung an jeden vergeben werden. In solchen Fällen kann IANA (Internet Assigned Numbers Authority) Zuweisungen direkt vornehmen, sofern IANA detaillierte Anweisungen erhält, welche Arten von Anfragen zu gewähren sind, und dies ohne subjektives Urteil möglich ist.

Andernfalls ist ein gewisses Maß an Prüfung erforderlich. Es ist jedoch wichtig, angemessene Prüfung und einfache Registrierung auszubalancieren. Oft sind die Registrierenden keine IETF-Teilnehmer; Anfragen kommen von anderen Standardisierungsorganisationen, von nicht unmittelbar an Normen beteiligten Organisationen, von ad-hoc-Gemeinschaftsarbeit (z. B. aus Open-Source-Projekten) usw. Registrierung darf nicht unnötig schwierig, unnötig kostspielig (hinsichtlich Zeit und anderer Ressourcen) noch unnötig einer Ablehnung ausgesetzt sein.

Obwohl es mitunter nötig ist, das Registrierbare einzuschränken (z. B. bei begrenzten Ressourcen wie Bits in einem Byte oder bei Elementen, deren nicht unterstützte Werte den Protokollbetrieb schädigen können), ist es in vielen Fällen wichtiger, was tatsächlich genutzt wird, in der Registry abzubilden. Übermäßig strenge Prüfkriterien und hoher Aufwand (Zeit und Mühe) entmutigen zu Registrierungsversuchen. Spiegelt eine Registry die tatsächlich genutzten Protokollelemente nicht wider, kann dies die Verbreitung von Protokollen im Internet beeinträchtigen, und die Registry selbst verliert an Wert.

Daher ist es wichtig, die Registrierungsrichtlinie gezielt zu durchdenken und sie nicht willkürlich zu wählen oder Text aus anderen Dokumenten zu kopieren. Arbeitsgruppen und andere Dokumentenentwickler sollten beim Anlegen von Registries passende Registrierungsrichtlinien wählen. Sie sollten die lockerste Richtlinie wählen, die den Anforderungen der Registry genügt, und für Richtlinien mit erheblichem Gemeinschaftsaufwand (strenger als Expert Review oder Specification Required im Sinne der bekannten Richtlinien) konkrete Begründungen (justification) angeben. Die Anforderungen unterscheiden sich von Registry zu Registry und im Laufe der Zeit; dieser BCP (Best Current Practice) wird nicht das letzte Wort zum Thema sein.

Die folgenden Richtlinien sind für gängige Anwendungsfälle definiert. Sie decken typische Richtlinien ab, die zur Beschreibung von Verfahren zur Zuweisung neuer Werte in einem Namensraum verwendet wurden. Es ist nicht zwingend vorgeschrieben, dass Dokumente diese Begriffe verwenden; die eigentliche Forderung ist, dass die Anweisungen an IANA klar und eindeutig sind. Die Verwendung dieser Begriffe wird jedoch nachdrücklich empfohlen, weil ihre Bedeutung weithin verstanden wird. Neu geschaffene Richtlinien, einschließlich solcher, die Elemente der mit diesen Begriffen verbundenen Verfahren neu kombinieren, dürfen verwendet werden, wenn keine dieser Richtlinien passt; eine Erklärung dazu erleichtert den Prüfprozess. Die Begriffe werden in den folgenden Unterabschnitten vollständig erläutert.

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

Häufig ist es sinnvoll, einen Namensraum in mehrere Kategorien zu unterteilen und Zuweisungen innerhalb jeder Kategorie unterschiedlich zu handhaben. Viele Protokolle unterteilen Namensräume nun in zwei oder mehr Teile, wobei ein Bereich Private Use oder Experimental Use vorbehalten ist und andere Bereiche global eindeutigen Zuweisungen nach einem Prüfverfahren dienen. Die Aufteilung in Bereiche ermöglicht unterschiedliche Richtlinien für verschiedene Bereiche und Anwendungsfälle.

Ebenso ist es oft nützlich, mehrere Richtlinien parallel anzugeben, die jeweils unter anderen Umständen gelten. Weitere Diskussion siehe Abschnitt 4.12.

Beispiele für RFCs, die mehrere Richtlinien parallel festlegen:

• LDAP [RFC4520]
• TLS ClientCertificateType Identifiers [RFC5246] (wie in den folgenden Unterabschnitten ausgeführt)
• MPLS Pseudowire Types Registry [RFC4446]