5. Designated Experts (Benannte Experten)

5.1. The Motivation for Designated Experts (Die Motivation für benannte Experten)

Diskussionen auf einer Mailingliste können wertvolles technisches Feedback liefern, aber die Meinungen variieren oft, und Diskussionen können einige Zeit ohne klare Lösung fortgesetzt werden. Darüber hinaus kann die IANA nicht an all diesen Mailinglisten teilnehmen und nicht bestimmen, ob oder wann solche Diskussionen einen Konsens erreichen. Daher verlässt sich die IANA auf einen "benannten Experten" (designated expert) für Ratschläge bezüglich der spezifischen Frage, ob eine Zuweisung vorgenommen werden sollte. Der benannte Experte ist eine Person, die für die Durchführung einer angemessenen Bewertung und die Rückgabe einer Empfehlung an die IANA verantwortlich ist.

Es sollte beachtet werden, dass eine wichtige Motivation für benannte Experten darin besteht, dass die IETF der IANA einen Fachexperten (subject matter expert) zur Verfügung stellt, an den der Bewertungsprozess delegiert werden kann. Die IANA leitet Anfragen für eine Zuweisung zur Bewertung an den Experten weiter, und der Experte (nach Durchführung der Bewertung) informiert die IANA darüber, ob die Zuweisung oder Registrierung vorgenommen werden soll oder nicht. In den meisten Fällen arbeiten die Registranten nicht direkt mit den benannten Experten zusammen. Die Liste der benannten Experten für ein Register ist im Register aufgeführt.

Es wird oft nützlich sein, einen benannten Experten nur zeitweise als Ergänzung zu anderen Prozessen zu verwenden. Für weitere Diskussionen zu diesem Thema siehe Abschnitt 4.12.

5.2. The Role of the Designated Expert (Die Rolle des benannten Experten)

Der benannte Experte ist für die Koordinierung der angemessenen Überprüfung einer Zuweisungsanfrage verantwortlich. Die Überprüfung kann breit oder eng sein, abhängig von der Situation und dem Urteil des benannten Experten. Dies kann die Konsultation mit einer Gruppe von Technologieexperten, Diskussionen auf einer öffentlichen Mailingliste, Konsultation mit einer Arbeitsgruppe (oder ihrer Mailingliste, wenn die Arbeitsgruppe aufgelöst wurde) usw. umfassen. Idealerweise folgt der benannte Experte spezifischen Überprüfungskriterien, wie sie mit dem Protokoll dokumentiert sind, das den Namensraum erstellt oder verwendet. Siehe die IANA Considerations-Abschnitte von [RFC3748] und [RFC3575] für spezifische Beispiele.

Von benannten Experten wird erwartet, dass sie in der Lage sind, ihre Entscheidungen gegenüber der IETF-Gemeinschaft zu verteidigen, und der Bewertungsprozess ist nicht dazu gedacht, geheim zu sein oder dem Experten unbestrittene Macht zu verleihen. Von Experten wird erwartet, dass sie anwendbare dokumentierte Überprüfungs- oder Prüfverfahren anwenden oder, in Abwesenheit dokumentierter Kriterien, allgemein akzeptierte Normen wie die in Abschnitt 5.3 befolgen. Von benannten Experten wird im Allgemeinen nicht erwartet, dass sie "Torwächter" (gatekeepers) sind, die versuchen, Registrierungen schwer zu erhalten, es sei denn, die Anleitung im definierenden Dokument spezifiziert, dass sie als solche handeln sollten. In Abwesenheit stärkerer Anleitung sollten die Experten Registrierungsanfragen auf Vollständigkeit, Interoperabilität und Konflikte mit bestehenden Protokollen und Optionen bewerten.

Es hat sich als nützlich erwiesen, für einige Register mehrere benannte Experten zu haben. Manchmal arbeiten diese Experten zusammen bei der Bewertung einer Anfrage, während in anderen Fällen zusätzliche Experten als Ersatz dienen und nur handeln, wenn der primäre Experte nicht verfügbar ist. In Registern mit einem Pool von Experten hat der Pool oft einen einzelnen Vorsitzenden, der dafür verantwortlich ist zu definieren, wie Anfragen den Experten zugewiesen und von ihnen überprüft werden. In anderen Fällen kann die IANA Anfragen einzelnen Mitgliedern in sequenzieller oder ungefähr zufälliger Reihenfolge zuweisen. Das Dokument, das das Register definiert, kann, wenn es für die Situation angemessen ist, spezifizieren, wie die Gruppe arbeiten sollte -- zum Beispiel könnte es angemessen sein, einen groben Konsens (rough consensus) auf einer Mailingliste, innerhalb einer verwandten Arbeitsgruppe oder unter einem Pool benannter Experten zu spezifizieren.

Im Falle von Meinungsverschiedenheiten zwischen mehreren Experten liegt es in der Verantwortung dieser Experten, eine einzige klare Empfehlung an die IANA abzugeben. Es ist nicht angemessen, dass die IANA Streitigkeiten zwischen Experten löst. In extremen Situationen, wie einer Pattsituation, muss möglicherweise die benennende Stelle eingreifen, um das Problem zu lösen.

Wenn ein benannter Experte einen Interessenkonflikt für eine bestimmte Überprüfung hat (zum Beispiel ein Autor oder bedeutender Befürworter einer Spezifikation ist, die mit der zu überprüfenden Registrierung zusammenhängt), sollte sich dieser Experte zurückziehen. Für den Fall, dass alle benannten Experten in Konflikt stehen, sollten sie darum bitten, dass ein vorübergehender Experte für die konfliktbehaftete Überprüfung benannt wird. Der verantwortliche AD kann dann jemanden ernennen oder der AD kann die Überprüfung durchführen.

Dieses Dokument definiert den Mechanismus des benannten Experten nur in Bezug auf Dokumente im IETF-Stream (IETF stream). Wenn andere Streams Registrierungsrichtlinien verwenden möchten, die benannte Experten erfordern, liegt es an diesen Streams (oder diesen Dokumenten) zu spezifizieren, wie diese benannten Experten ernannt und verwaltet werden. Was unten beschrieben wird, mit Verwaltung durch die IESG, ist nur für den IETF-Stream geeignet.

5.2.1. Managing Designated Experts in the IETF (Verwaltung benannter Experten in der IETF)

Benannte Experten für von der IETF erstellte Register werden von der IESG ernannt, normalerweise auf Empfehlung des zuständigen Bereichsdirektors (Area Director). Sie können zum Zeitpunkt ernannt werden, an dem ein Dokument, das einen Namensraum erstellt oder aktualisiert, von der IESG genehmigt wird, oder später, wenn die erste Registrierungsanfrage eingeht. Da ursprünglich ernannte Experten später möglicherweise nicht mehr verfügbar sind, wird die IESG bei Bedarf Ersatz ernennen. Die IESG kann jeden von ihr ernannten benannten Experten nach eigenem Ermessen abberufen.

Das normale Beschwerdeverfahren, wie in [RFC2026], Abschnitt 6.5.1 beschrieben, gilt für Probleme, die beim Team benannter Experten auftreten. Zu diesem Zweck nimmt das Team benannter Experten in dieser Beschreibung den Platz der Arbeitsgruppe ein.

5.3. Designated Expert Reviews (Überprüfungen durch benannte Experten)

In den Jahren seit der Veröffentlichung und Verwendung von [RFC2434] hat die Erfahrung zu den folgenden Beobachtungen geführt:

Ein benannter Experte muss zeitnah antworten, normalerweise innerhalb einer Woche für einfache Anfragen bis zu einigen Wochen für komplexere. Unangemessene Verzögerungen können erhebliche Probleme für diejenigen verursachen, die Zuweisungen benötigen, wie zum Beispiel wenn Produkte Codepunkte (code points) zum Versand benötigen. Dies bedeutet nicht, dass alle Überprüfungen innerhalb einer festen Frist abgeschlossen werden können, aber sie müssen begonnen werden, und der Antragsteller und die IANA sollten eine gewisse Transparenz in den Prozess haben, wenn eine Antwort nicht schnell gegeben werden kann.
Wenn ein benannter Experte nicht innerhalb eines angemessenen Zeitraums auf Anfragen der IANA antwortet, weder mit einer Antwort noch mit einer angemessenen Erklärung für die Verzögerung (einige Anfragen können besonders komplex sein), und wenn dies ein wiederkehrendes Ereignis ist, muss die IANA das Problem bei der IESG ansprechen. Aufgrund der durch verzögerte Bewertungen und Zuweisungen verursachten Probleme sollte die IESG geeignete Maßnahmen ergreifen, um sicherzustellen, dass der Experte seine Verantwortlichkeiten versteht und akzeptiert, oder einen neuen Experten ernennen.
Der benannte Experte ist nicht verpflichtet, die Last der Bewertung und Entscheidung aller Anfragen persönlich zu tragen, sondern fungiert als Hirte (shepherd) für die Anfrage und holt bei Bedarf die Hilfe anderer ein. In dem Fall, dass eine Anfrage abgelehnt wird und die Ablehnung der Anfrage wahrscheinlich kontrovers ist, sollte der Experte die Unterstützung anderer Fachexperten haben. Das heißt, der Experte muss in der Lage sein, eine Entscheidung gegenüber der gesamten Gemeinschaft zu verteidigen.

Wenn ein benannter Experte verwendet wird, sollte die Dokumentation dem benannten Experten klare Anleitung geben und Kriterien für die Durchführung einer Bewertung sowie Gründe für die Ablehnung einer Anfrage darlegen. Für den Fall, dass es keine spezifischen dokumentierten Kriterien gibt, sollte die Annahme sein, dass ein Codepunkt gewährt werden sollte, es sei denn, es gibt einen zwingenden Grund für das Gegenteil (und siehe auch Abschnitt 5.4). Gründe, die zur Ablehnung von Anfragen verwendet wurden, umfassen:

Knappheit von Codepunkten, bei denen die begrenzten verbleibenden Codepunkte umsichtig verwaltet werden sollten, oder bei denen eine Anfrage für eine große Anzahl von Codepunkten gestellt wird und ein einzelner Codepunkt die Norm ist.
Die Dokumentation ist nicht ausreichend klar, um die Interoperabilität zu bewerten oder sicherzustellen.
Der Codepunkt wird für eine Protokollerweiterung benötigt, aber die Erweiterung ist nicht konsistent mit der dokumentierten (oder allgemein verstandenen) Architektur des zu erweiternden Basisprotokolls und würde dem Protokoll schaden, wenn sie weit verbreitet eingesetzt würde. Es ist nicht beabsichtigt, dass "Inkonsistenzen" sich auf geringfügige Unterschiede "persönlicher Präferenz" beziehen. Stattdessen beziehen sie sich auf signifikante Unterschiede wie Inkonsistenzen mit dem zugrunde liegenden Sicherheitsmodell, die eine Änderung der Semantik eines vorhandenen Nachrichtentyps oder einer Operation implizieren, ungerechtfertigte Änderungen in bereitgestellten Systemen erfordern (im Vergleich zu alternativen Möglichkeiten, ein ähnliches Ergebnis zu erzielen) usw.
Die Erweiterung würde Probleme mit vorhandenen bereitgestellten Systemen verursachen.
Die Erweiterung würde mit einer in aktiver Entwicklung befindlichen Erweiterung der IETF in Konflikt geraten, und beide zu haben würde der Interoperabilität eher schaden als sie zu fördern.

Dokumente dürfen den oder die benannten Experten nicht im Dokument selbst benennen; stattdessen sollten alle vorgeschlagenen Namen dem zuständigen Bereichsdirektor mitgeteilt werden, wenn das Dokument zur Genehmigung an die IESG gesendet wird. Dies geschieht normalerweise im document shepherd writeup.

Wenn die Anfrage auch auf einer bestimmten öffentlichen Mailingliste überprüft werden sollte, sollte ihre Adresse angegeben werden.

5.4. Expert Reviews and the Document Lifecycle (Expertenprüfungen und Dokumentenlebenszyklus)

Die Überprüfung durch den benannten Experten erfolgt notwendigerweise zu einem bestimmten Zeitpunkt und stellt die Überprüfung einer bestimmten Version des Dokuments dar. Während Überprüfungen im Allgemeinen etwa zum Zeitpunkt des IETF Last Call durchgeführt werden, ist die Entscheidung, wann die Überprüfung stattfinden sollte, eine Frage des guten Urteils. Und während Wiederholungsüberprüfungen durchgeführt werden könnten, wenn anerkannt wird, dass sich die Dokumentation des registrierten Elements wesentlich geändert hat, erfordert die Sicherstellung, dass eine Wiederholungsüberprüfung stattfindet, Aufmerksamkeit und Sorgfalt.

Es ist möglich, durch Fahrlässigkeit, Unfall, Unachtsamkeit oder sogar vorsätzliche Missachtung, dass Änderungen nach der Überprüfung und Genehmigung des benannten Experten vorgenommen werden, die, wenn das Dokument erneut überprüft würde, dazu führen würden, dass der Experte die Registrierung nicht genehmigt. Es liegt an der IESG, mit dem vom verantwortlichen Bereichsdirektor gehaltenen Token, auf solche Situationen aufmerksam zu sein und zu erkennen, dass solche Änderungen überprüft werden müssen.

Für Registrierungen aus Dokumenten auf dem Standards Track gibt es oft eine erforderliche Expertenprüfung (durch die Registrierungsrichtlinie) zusätzlich zum IETF-Konsens (zur Genehmigung als Standards Track RFC). In solchen Fällen muss die Überprüfung durch den benannten Experten zeitnah sein und vor der Bewertung des Dokuments durch die IESG eingereicht werden. Die IESG sollte das Dokument im Allgemeinen nicht zurückhalten und auf eine verspätete Überprüfung warten. Es ist auch nicht beabsichtigt, dass die Expertenprüfung den IETF-Konsens außer Kraft setzt: Die IESG sollte die Überprüfung in ihrer eigenen Bewertung berücksichtigen, wie sie es für andere Last Call-Überprüfungen tun würde.