Zusammenfassung

  • Peter Hessler begrüßte ein Referenzregister für RIPE-Regeln und wollte Dokumente der Database Working Group darin sehen.
  • Widersprüchliche Definitionen sollten früh und getrennt erfasst werden, bevor jemand angenommene Regeln ändert.

Ein gut sortiertes Regal hilft beim Suchen. Es verhindert nicht, dass zwei Dokumente auf dieselbe Frage verschiedene Antworten geben.

Remco van Mook brachte dieses Problem in die Address-Policy-Sitzung der RIPE 93. Sein Vorschlag, den er die „neue Küche“ nannte, sollte die RIPE-Regeln nach Themen ordnen. Im Bestand liegen alte und neue Dokumente nebeneinander, Begriffe passen nicht immer zusammen, und Vorschläge gelten entweder als zu kompliziert oder als lückenhaft. Beide Einwände können stimmen. Dann bleibt ein Entwurf zwischen Vollständigkeit und Verständlichkeit stecken.

Van Mook wollte zunächst nur Verweise sammeln. Das Register sollte auf bestehende RIPE-Dokumente zeigen, ihre Regeltexte aber weder verschieben noch neu formulieren. Themen könnten IPv4, IPv6, ASNs, Transfers und Sonderressourcen umfassen. Das Sitzungsprotokoll hält eine Einladung zur Diskussion fest, keine formelle Annahme, keinen zuständigen Eigentümer und keinen Termin.

Peter Hessler begrüßte als Ko-Vorsitzender der RIPE Database Working Group und in deren Namen die Mitarbeit sowie die Aufnahme von Datenbankdokumentation. Zugleich trennte er das einfache Sammeln von Verweisen von der schwierigeren Arbeit, widersprüchliche Definitionen zusammenzuführen. Konflikte sollten früh und sichtbar erfasst werden. Zum Ende der Diskussion betonte er erneut: Wenn angenommene Regeln kollidieren, soll das ausdrücklich benannt werden, damit die zuständige Arbeitsgruppe den Fall übernehmen kann. Die Korrektur der Texte ist ein eigener Schritt.

Das ist mehr als eine Ablagefrage. Ein Register beantwortet: „Wo steht die Regel?“ Eine Konfliktliste fragt: „Welche Stellen widersprechen sich, und wer soll das klären?“ Damit geht es um die Bedeutung der Regel. Tobias Fiebig nannte unterschiedliche Mindestgrößen für IPv6-Zuweisungen als mögliches Beispiel. Das Protokoll nennt weder Dokumentnummern noch konkrete Abschnitte. Erst ein Vergleich dieser Stellen zeigt, ob sie sich tatsächlich widersprechen oder eine Erklärung brauchen.

Die RIPE-781 zum Policy Development Process sieht vier Phasen vor: Vorschlag, Diskussion, Prüfung und Abschluss. Sie beschreibt ein offenes, transparentes und konsensbasiertes Verfahren; Policies werden in RIPE Documents festgehalten. Dieses Verfahren bietet den Weg für Änderungen. Ein Register würde Leser zunächst zu den geltenden Texten führen.

Maynard Koch warnte in der Sitzung, schon eine „Klarstellung“ könne die Anwendung einer Policy verändern. Gert Döring verlangte, dass eine neue Formulierung die ursprüngliche Absicht bewahrt. Der Streit drehte sich also nicht bloß um Ordnung im Dokumentenschrank. Es ging darum, wer feststellen darf, dass zwei Formulierungen dieselbe Wirkung haben.

Die offizielle Seite der RIPE Database Working Group beschreibt ihren Aufgabenbereich mit Änderungen, Funktionen, Verteilung und Sicherheit der Datenbank. Ihre Dokumente in das Register aufzunehmen, würde dessen Reichweite erhöhen. Eine getrennte Konfliktliste gäbe jeder Arbeitsgruppe eine klare Übergabe, statt dass ein Redakteur verstreute Regeln stillschweigend angleicht.

Das Protokoll endet ohne Namen und Termin für diese Konfliktliste. Das nächste sinnvolle Dokument lässt sich konkret beschreiben: versionierte Verweise, eine eigene Liste mit beiden betroffenen Abschnitten und eine Übergabe an das zuständige Verfahren. Hessler will Karte und Entscheidung getrennt halten. Sonst könnte eine redaktionelle Zusammenfassung als beschlossene Policy gelesen werden.

Quellen