Zusammenfassung

  • AFPUB-2026-IPv4-003-DRAFT01 schlägt vier IPv4-Pools, die Rückverfolgung zurückgewonnener Blöcke, Antragsgrenzen und eine Warteliste nach Erschöpfung vor.
  • AFRINIC führt den Text derzeit als „Under Discussion“. Eine datierte Antwort der PDWG-Ko-Vorsitzenden besagt jedoch, dass die Juni-Einreichung die Frist für einen neuen Vorschlag beim nächsten Treffen verpasst hatte.
  • Nötig sind zwei verbundene Register: eines für Adressbewegungen und eines für Verfahrensstatus und Autorität jeder Regel.

Präzise Zahlen machen noch keine geltende Regel

Der Entwurf wirkt wie eine Betriebsanweisung. Im Pre-Softlanding Pool läge ein normaler Antrag zwischen /24 und /18; mit Wachstumsdaten und prüfbarem Ausbauplan wären bis zu /16 möglich. Antragsteller müssten für frühere Zuweisungen 80% effiziente Nutzung über einen Begründungszeitraum von zwölf Monaten nachweisen. Nach Erschöpfung beider Hauptpools würde eine Warteliste gewöhnlich /23 bis /24 vergeben, unbeantwortete Anträge nach dreißig Tagen verfallen lassen und freiwillige Übertragungen vierundzwanzig Monate beschränken.

Das sind vorgeschlagene Parameter. Der offizielle Index bezeichnet Version 1.0 vom 8. Juni 2026 als in Diskussion, nicht als konsentiert, ratifiziert oder umgesetzt. Diese Grenze zählt früh, weil exakte Schwellen Investitionen und Anträge schon verändern können, bevor eine Durchsetzungsbefugnis besteht.

Vier Pools verlangen Herkunftsnachweise

Die Architektur trennt Soft-Landing Pool, zweckgebundene Reserven, Pre-Softlanding Pool und einen temporären Recovered Pool. Jeder zurückgewonnene Block käme zunächst in den Zwischenpool. Mitarbeiter würden die Ursprungskategorie ermitteln; ohne hinreichende Sicherheit fiele der Block an Pre-Softlanding. Teilblöcke würden proportional klassifiziert und Entscheidungen dokumentiert sowie veröffentlicht.

Die Herkunft bestimmt damit Eignung, Größe und Weiterleitung. Eine Fehlklassifizierung kann ändern, wer knappe Ressourcen erhält, wie viel und unter welchen Transferauflagen. Ein Register muss Block, Vorstatus, Herkunftsnachweis, angewandte Regel, Verantwortlichen, Zeit, Zielpool und spätere Vergabe zeigen. Summen allein rekonstruieren keine strittige Entscheidung.

Die Behauptungen, der aktive Pool reiche etwa zwei Jahre, ein reserviertes /12 weitere drei, mehr als drei Millionen Adressen seien zurückgewonnen und einige Mitglieder hätten durch aufeinanderfolgende Anträge mehr als acht /22-Blöcke erhalten, stammen von den Autoren. Das eingefrorene Paket prüft die Betriebsdaten nicht unabhängig.

Auch das Politikverfahren hat eine Warteschlange

Am 18. Juni bestätigten die Ko-Vorsitzenden die Einreichung vom 8. Juni, nannten aber den 26. Mai um 23:59 UTC als Frist für neue Vorschläge zum nächsten Treffen. Zudem verwiesen sie auf einen bestehenden Vorschlag zu zurückgewonnenem Raum. Daher konnte dieser Text bei jenem Treffen nicht als neuer Vorschlag angenommen werden.

Das war keine inhaltliche Ablehnung. Sie empfahlen, den Text als Verbesserung oder Alternative auf der Liste zu teilen. „Under Discussion“ und die fehlende Berechtigung für ein bestimmtes Treffen sind verschiedene Zustände; keiner belegt allein Konsens, Rückzug oder Ratifizierung.

Ressourcen- und Regelstatus verbinden

Die richtige Kontrolle ist ein Doppelregister. Die Ressourcenseite verfolgt Eingang, Neuklassifizierung und Ausgang jedes Blocks. Die Autoritätsseite speichert Version, Diskussion, Treffenberechtigung, Konsens, Verwaltungsratsentscheidung und Wirksamkeitsdatum. Jede Bewegung verweist auf die damals gültige Regel.

So läuft Knappheitspraxis der Autorität nicht voraus. Überschneidende Vorschläge lassen sich nach ihren konkreten Wirkungen auf Herkunft, Nachfüllung, Nutzung, Grenzen, Priorität, Übertragung und Transparenz vergleichen.

Quellen