Zusammenfassung

  • draft-gerke-publication-process-reform-09 vom 29. September nennt nun neben RFC 7841 auch RFC 6359 als vorgeschlagenes Update, ausdrücklich nur für den Fall einer Annahme. Das individuelle Internet-Draft steht beim IESG weiterhin auf I-D Exists und ändert keinen geltenden RFC.
  • Der zweistufige Änderungsstopp war bereits in Fassung 08 enthalten. Neu ist die ausdrückliche Verknüpfung der geplanten Zustandsprüfungen und Schreibgrenzen mit der Datatracker-Nachverfolgung nach RFC 6359, die Informationen aus eigenständigen Systemen der IANA und des RFC Editor sichtbar macht.

Auf dem Deckblatt der Fassung vom 22. September stand nur RFC 7841. Er behandelt die Publikationsströme der RFC-Reihe sowie Kopfzeilen und Statushinweise. Eine Woche später ergänzt der Verfasser RFC 6359. Damit nimmt er ein Dokument in den Blick, das nicht die Beschriftung eines RFC, sondern den Einblick in die Bearbeitung nach der Freigabe betrifft. Das ist die eigentliche Verschiebung dieser Revision.

Ein neuer Abschnitt 1.2 setzt die in RFC 6359 beschriebene Datatracker-Pipeline in Beziehung zu automatischen Integritätsprüfungen und Schreibbeschränkungen. Auch die Zusammenfassung beansprucht nun automatische Meilensteine für bestehende und künftige zentrale Bearbeitungsströme. Ein Anspruch im Entwurf ist jedoch kein Nachweis, dass Datatracker bereits strömübergreifend sperrt oder dass die beteiligten Stellen diesen Eingriff beschlossen hätten.

Die Versionsgeschichte setzt eine wichtige Grenze für die Nachricht. Schon Fassung 08 schlug vor, technische Änderungen früher einzufrieren als redaktionelle, dem IESG nach IESG OK Schreibrechte zu entziehen und die spätere Bearbeitung bei der RFC-Produktion weiter zu begrenzen. Fassung 09 erfindet diese Phasen nicht neu, sondern versieht sie mit einem weiteren Ziel-RFC. Zusätzlich wird draft-ietf-procon-2026bis-11 von einer informativen zu einer normativen Referenz. Dieses referenzierte Dokument befindet sich noch in der Last-Call-Phase seiner Arbeitsgruppe und ist selbst kein RFC.

RFC 6359 wollte eine gemeinsame Sicht auf den Weg von einem genehmigten Internet-Draft zum fertigen RFC schaffen. Zugleich stellt er klar, dass er die Verfahren der beteiligten Einrichtungen nicht festlegt. Für den Bearbeitungsstand der IANA nach der Genehmigung ist deren eigenes System maßgeblich; für den Stand beim RFC Editor ist stets dessen System maßgeblich. Datatracker bildet diese Zustände ab. Eine gemeinsame Anzeige und eine Instanz, die Änderungen an allen Stellen unterbindet, haben unterschiedliche Aufgaben.

Das schließt künftige technische Prüfungen nicht aus. Es verlangt aber, die Entscheidungskompetenz zu benennen: Welcher Stromverantwortliche akzeptiert welche Sperre? Wer beurteilt eine technische Korrektur gegenüber einer redaktionellen Änderung? Wo wird eine Ausnahme dokumentiert und angefochten? Die Zielangabe Best Current Practice auf dem Entwurf und das Wort Updates liefern keine Antworten, keine Annahme durch das IETF und keinen Implementierungsbeleg.

Quellen