Zusammenfassung

  • Draft Policy ARIN-2025-1 sagt, sämtliche Internet Service Provider seien Local Internet Registries, aber nicht jeder LIR sei ein ISP. Der vorgeschlagene LIR-Begriff verlangt eine Internet-Registry-Funktion, RIR-Mitgliedschaft, den Empfang von Zuteilungen und die Verteilung an Kunden, Endnutzer und Infrastruktur.
  • Der vorgeschlagene ISP-Begriff setzt lediglich voraus, dass eine Organisation Internetdienste für Außenstehende erbringt. Konnektivität, Webdienste, Colocation, dedizierte Server, VPS und VPN belegen für sich genommen keine der Registry-Eigenschaften, die für die behauptete Teilmenge nötig wären.
  • ARIN kann die Unternehmensgestaltung lokal belassen und trotzdem die Ressourcenrolle präzisieren: Jede Einstufung bindet sich an eine Begriffsversion, den Ressourcenlebenszyklus, die Weitergabefunktion und die einschlägige Klausel; jede folgenreiche ISP-zu-LIR-Änderung erhält einen geschützten Migrationseintrag.

Zwei Karten, die nicht von selbst ineinanderpassen

Beim klassischen Zugangsanbieter scheinen ISP und LIR zwei Ansichten derselben Organisation zu sein. Das Unternehmen verkauft Konnektivität, erhält einen Adressblock direkt, gibt Teile davon an Kunden weiter und registriert diese Verteilungen. Marktrolle und Nummernressourcenfunktion fallen zusammen.

Eine belastbare Definition muss aber vor allem am Rand funktionieren. Ein Betreiber verwalteter Webdienste kann ausschließlich Adressen seines Upstreams nutzen. Eine Universität kann eine Zuteilung beziehen und innerhalb ihrer Einrichtungen oder an verbundene Nutzer verteilen, ohne Internetzugang im Einzelhandel anzubieten. Ein Konzern kann für Tochterunternehmen eine Registry-Funktion ausüben, ohne ISP als Geschäftsidentität zu übernehmen.

Der unabhängige NOG-Alliance-Tracker führt ARIN-2025-1 als Draft Policy und nennt den 13. August 2026 als jüngste Änderung. Der Vorschlag beginnt mit einer echten Dokumentationslücke: LIR ist definiert, ISP nur implizit. Danach formuliert die Problembeschreibung eine genaue Beziehung. Durch Implikation und übliche Geschäftspraxis seien alle ISPs LIRs, jedoch nicht alle LIRs ISPs.

Das bedeutet mehr als häufige Überschneidung. Jede Organisation, die die ISP-Definition erfüllt, müsste zugleich sämtliche notwendigen LIR-Merkmale erfüllen. Vertraute Netzbetreiber in der Schnittmenge sagen nichts darüber aus, wie sich die Definition an ihren Grenzen verhält.

Die Community darf diese Hierarchie als politische Entscheidung wählen. Eine Klarstellung ist sie aber nur dann, wenn auch ein Leser ohne Kenntnis der ARIN-Gepflogenheiten sie aus den geschriebenen Bedingungen prüfen kann.

LIR folgt der Nummernressourcenkette

Der in einem unabhängigen PPML-Archiv vom März 2026 erhaltene Text gibt dem LIR mehrere Glieder. Er ist Internet Registry und RIR-Mitglied, erhält von diesem RIR Allocations von Internetnummern und teilt sie Kunden, Endnutzern und Infrastruktur zu.

Jedes Element beschreibt eine Ressourcenbeziehung. Der Empfang ist ein Ereignis im Lebenszyklus; nachgelagerte Verteilung und Registrierung sind eigene Funktionen. Die Beispiele reichen über Zugangsanbieter hinaus und umfassen große Unternehmen, Universitäten und ISPs.

Dieselbe archivierte Verteilung zeigt die Breite der Migration: Überschriften und operative Klauseln würden von ISP zu LIR wechseln, während die Terminologieklausel ISP als Teilmenge von LIR behandelt. Das ist keine Glossarfußnote, sondern ein Rollenwechsel über Allocation, Reassignment, Auslastung und Pflichten gegenüber Downstream-Kunden hinweg.

Das Archiv beweist den verbreiteten Wortlaut, nicht dessen Autorität. Der Tracker belegt nur eine spätere Versionsgrenze und den Status. Der redaktionelle Datensatz muss beides bewahren: den exakt analysierten Text und die jüngere Fassung, deren vollständiger Wortlaut vor einer Umsetzung neu zu prüfen ist.

ISP folgt einer Marktaktivität

Die vorgeschlagene ISP-Definition liegt auf einer anderen Achse. Ein Internet Service Provider ist eine Organisation, die anderen Organisationen, Kunden oder Personen außerhalb ihrer Beschäftigten Internetdienste bereitstellt. Aufgeführt werden Konnektivität, Webdienste, Colocation, dedizierte Server, Virtual Private Server und Virtual Private Networks.

Der Satz verlangt nicht, dass ein ISP ein Internet Registry ist. Er verlangt keine direkte Allocation von einem RIR, keine bestimmte Mitgliedschaft und keine Reallocation oder Reassignment von Nummernressourcen an Kunden.

Die Mehrdeutigkeit erscheint in einem unabhängig erhaltenen PPML-Austausch zum Antragsleitfaden. Ein Teilnehmer zitiert eine Kurzform, nach der LIR ein ISP sei, und zugleich eine Definition, nach der LIRs nur „im Allgemeinen“ ISPs seien. Er fragt, ob die Gruppen identisch, verschachtelt oder für Direct-Allocation-Inhaber optional seien. Das Archiv belegt die geäußerte Verwirrung, nicht die Entscheidung über einen konkreten Antrag.

Diese Reihenfolge zeigt die fehlende Brücke. Ein Dienstname kann auf die zu prüfende Tür hinweisen. Er besteht nicht automatisch den Test hinter der Tür. Der Verkauf eines VPN ist nicht der Empfang einer RIR-Allocation. Der Betrieb dedizierter Server beweist keine registrierte Weiterverteilung von Nummernressourcen.

Mehrere Reparaturen wären in sich stimmig. ISP könnte wieder ausdrücklich ein Typ von LIR sein. Der Dienste-Begriff könnte auf Anbieter mit qualifizierter Verteilungsfunktion verengt werden. Die Gruppen könnten als überlappend statt vollständig verschachtelt beschrieben werden. Oder die normative Eignung könnte ohne den ISP-Begriff direkt an Ressourcennutzung und Weitergabe anknüpfen.

Die Community muss zwischen diesen Modellen wählen. Der Leser sollte diese Wahl nicht selbst erraten müssen.

Die fehlende Implikation

Fünf analytische Prädikate machen den Abstand sichtbar. Sie sind weder ARIN-Terminologie noch Vorschlag für ein Softwareschema.

IR(x) bedeute, dass Organisation x Internetnummern verteilt und diese Verteilungen registriert. M(x) bezeichne die vorgegebene RIR-Mitgliedschaft, A(x) den Empfang einer Allocation von diesem RIR, D(x) die nachgelagerte Zuteilung oder Delegation und S(x) die externe Erbringung mindestens eines aufgelisteten Dienstes.

Die LIR-Definition lässt sich dann als LIR(x) = IR(x) ∧ M(x) ∧ A(x) ∧ D(x) lesen. Für ISP ergibt sich ISP(x) = S(x).

Damit jeder ISP ein LIR ist, braucht der Text S(x) → IR(x) ∧ M(x) ∧ A(x) ∧ D(x). Diese Implikation steht dort nicht.

Damit ist kein betrieblicher Fehler bei ARIN mathematisch bewiesen. Öffentliche Regeln besitzen Kontext, weitere Eignungsklauseln und Mitarbeiterauslegung. Bewiesen ist ein engerer Befund: Aus den beiden vorgeschlagenen Definitionen allein kann ein Leser die erklärte Teilmengenbeziehung nicht ableiten.

Ein synthetischer Anbieter an der Grenze

Man stelle sich ein erfundenes Unternehmen vor, das verwaltete Webdienste und VPN-Zugang verkauft. Sämtliche Adressen stammen von einem Upstream. Das Unternehmen hat keine direkte RIR-Allocation und agiert nicht als Internet Registry, das Nummernressourcen an Kunden verteilt und diese Vorgänge registriert.

Das ist ein konstruiertes Logikbeispiel. Es benennt keinen realen Betreiber, keinen Antrag bei ARIN und keine beobachtete Mitarbeiterpraxis.

Die Firma erfüllt das veröffentlichte ISP-Prädikat: Sie liefert Außenstehenden zwei ausdrücklich genannte Dienste. Mindestens die Bedingungen der direkten Allocation und der nachgelagerten Verteilung aus der LIR-Definition erfüllt sie nicht. Je nach beabsichtigter Bedeutung von member of an RIR kann auch diese Bedingung fehlen.

Im Markt mag die Bezeichnung ISP sinnvoll sein. Auch die Weiterleitung zum ISP-Antragsleitfaden kann helfen, weil dort geprüft werden kann, ob geplante Kundenzuweisungen eine direkte Allocation rechtfertigen. Die Weiterleitung erzeugt aber keine bereits vorhandene Allocation und verwandelt die Nutzung von Upstream-Adressen nicht in eine Registry-Funktion.

Grenzfälle sind keine Wortklauberei. Sie sind der günstigste Test dafür, ob eine Definition die von ihren Autoren beabsichtigte Beziehung tatsächlich trägt.

Ressourcenfunktion und Unternehmenslabel sind getrennte Achsen

RFC 7020 beschreibt das Nummernregistrysystem als Hierarchie, in der Registrys Ressourcen an Kunden allocaten und LIRs typischerweise ISPs sind. „Typischerweise“ beschreibt eine häufige Beziehung; es definiert keine Identität zwischen Registry-Rolle und jedem Unternehmen, das Internetdienste verkauft.

Auf der Ressourcenachse stehen Antragsteller, Direct-Allocation-Inhaber, Downstream-Verteiler, Endnutzer und Nutzer von Upstream-Raum. Auf der Diensteachse stehen Konnektivität, Hosting, Colocation und VPN. Eine Klassifikation darf beide lesen, muss aber die Kombination benennen, die die normative Rolle auslöst.

Eine in der PPML vorgeschlagene Alternativdefinition machte diese Wahl ausdrücklich: Sie verband LIR mit dem Registry-System aus RFC 7020 und sah Verbrauch und Rechtfertigung von Nummernressourcen für Kunden als wichtiges ISP-Merkmal. Das war ein Teilnehmerbeitrag, kein angenommener Text. Diagnostisch zeigt er, dass die fehlende Brücke in einen Satz passt, sobald die Ressourcenfunktion feststeht.

Bleibt member of an RIR ein LIR-Prädikat, muss der Text auch die genaue Beziehung und den Prüfzeitpunkt nennen. Ein kommerzieller Dienst erzeugt diesen Zustand nicht durch Implikation, und eine Ressourcenbeziehung darf nicht aus einer Marktbezeichnung abgeleitet werden.

Die Verwaltungsgeschichte hielt die Rollen auseinander

RFC 2901, ein informativer Leitfaden von 2000, verwies Organisationen je nach Bezug und Nutzung von Adressen auf unterschiedliche Antragsunterlagen. Das ist Geschichte und keine heutige ARIN-Anforderung. Es bewahrt aber einen analytischen Punkt: ISP dient seit Langem als Antragspfadlabel, LIR gehört zur Registry-Hierarchie.

Begriffe können im Gespräch zusammenrücken, während Verfahren weiter unterschiedliche Tatsachen abfragen. Die gemeinsame Tatsache ist nicht das bevorzugte Nomen des Unternehmens, sondern die Ressourcenfunktion, die zu Version und Zeitpunkt eine Regel auswählt.

Die öffentliche Debatte fand die schwache Brücke

Die archivierte Debatte war nicht nur stilistisch. Eine Antwort vom März 2026 stimmte zu, dass der vorgeschlagene LIR-Satz grammatisch unvollständig sei, und bezweifelte at a local level, weil manche LIRs über eine einzelne RIR-Region hinaus operieren. Dieselbe Nachricht gab die dienstebasierte ISP-Definition wieder.

Die Antwort entscheidet keine Policy und beschreibt keine Umsetzung. Sie zeigt, dass Teilnehmer Prädikate und Reichweite bereits vor der Versionsgrenze vom 13. August testeten. Der Befund dieses Artikels ist kein verborgener Vorwurf, sondern eine reproduzierbare Textfrage, die eine spätere Fassung beantworten kann.

Terminologie ist verteilter Zustand. Eine Definition erreicht Überschriften, Leitfäden, Anweisungen, Schulungen und Antragsfelder. Die spätere Fassung muss als neues Objekt geprüft werden, nicht als stille Fortsetzung des archivierten März-Texts.

Eine minimale Rollen-Prädikat-Matrix

ARIN muss zur Behebung nicht das gesamte Angebot jedes Unternehmens erfassen. Nötig ist ein kleiner geschützter Datensatz, der die Rollenentscheidung mit Regel und tatsächlicher Ressourcenfunktion verbindet.

Für eine erste Zuordnung und ein Migrationsmanifest genügen sechzehn Felder.

  1. Identität von Organisation und Org ID. Rechtliche und registrierte Identität der Einstufung samt maßgeblicher Zeitgrenze festhalten.
  2. Identität von Antrag oder Entscheidung. Stabilen Schlüssel, Einreichungszeit und ausdrückliche Verbindungen zu Überarbeitungen oder Ersatzanträgen führen.
  3. Begriffsversion und Wirksamkeit. Das genaue NRPM, den Entwurf oder die Implementierungsversion samt Datum für ISP, LIR, IR, Endnutzer und Delegation nennen.
  4. Zweck der Einstufung. Festhalten, für welche Policy-Entscheidung die Rolle geprüft wird; ein universelles Geschäftsetikett darf keine sachfremden Handlungen bestimmen.
  5. Prädikat des kommerziellen Dienstes. Nur die begrenzte externe Diensteklasse erfassen, ohne den gesamten privaten Produktkatalog zum Gegenstand der Policy zu machen.
  6. Internet-Registry-Prädikat. Angeben, ob die Organisation Nummernressourcen verteilt und die Verteilung registriert, mit geschütztem Belegverweis.
  7. Status der direkten Allocation. Nicht vorhanden, beantragt, genehmigt, ausgegeben, zurückgegeben, widerrufen und ersetzt trennen und an das Ressourcenereignis binden.
  8. Funktion der nachgelagerten Delegation. Reallocation oder Reassignment, Empfängerklasse und maßgebliche Klausel dokumentieren.
  9. Nutzung für interne Infrastruktur. Abgegrenzte Eigennutzung von Kundenverteilung trennen.
  10. Mitgliedschaftsstatus. Nichtmitglied und Antragsteller, Service, General, General in Good Standing oder Trustee unter der einschlägigen Regel festhalten; Stimmrechte nie aus der Ressourcenrolle ableiten.
  11. Vertrags- und Vertretungsstatus. RSA- oder LRSA-Deckung und organisatorische Befugnis an geschützte Belege binden, ohne Vollmachtsdokumente zu veröffentlichen.
  12. Einschlägiger Policy-Pfad. Klauseln, Qualifikationstests und Ausschlüsse benennen, die aufgrund der verifizierten Ressourcenfunktion ausgewählt wurden.
  13. Zuordnung der Begriffsvorkommen. Für jede folgenreiche Stelle alten und neuen Begriff, Abschnitt, Oberfläche und einen begrenzten Code der Bedeutungswirkung speichern.
  14. Implementierungsbindung. Policy-Bedeutung an dieselbe Version von öffentlichem Leitfaden, Mitarbeiteranweisung, Schulung, Antragsfeld und Testvektor koppeln.
  15. Ergebnis, Begründung und Korrektur. Entscheidende Prädikate, Ergebnis, Prüfpfad, spätere Rollenänderung und Berichtigungshistorie erhalten.
  16. Datenschutzwahrende Aggregation. Zahlen zu Antragspfaden, Einstufungswechseln, Formularversionskonflikten und Korrekturen ohne Antragstellernamen oder Produktgeheimnisse veröffentlichen.

Das ist keine Forderung nach einem bestimmten Datenbankschema. Es ist die Mindestinformation, mit der ein anderer Prüfer nachvollziehen kann, warum ein Policy-Pfad galt.

Die gemeinsame Ebene kennt die Funktion, nicht den Geschäftsplan

Die Minimum Initial Specification liefert eine passende Grenze. Gemeinsame Koordination soll streng bei den deterministischen Tatsachen sein, die Eindeutigkeit, Interoperabilität, Nachweis, Sicherheit und Schutz erfordern. Geschäftsvereinbarungen, institutionelle Ambitionen und Ermessenspräferenzen bleiben lokal.

Zu den gemeinsamen Tatsachen gehören hier Organisationsidentität, Begriffsversion, Ressourcenlebenszyklus, Weitergabefunktion, einschlägige Regel und aufgezeichnete Statusänderung. Geschützte Belege können Vertrag und Befugnis nachweisen. Öffentliche Aggregate können zeigen, wie oft sich ein Pfad änderte oder Formularversionen auseinanderliefen.

Der Produktmix bleibt lokal. Die Registry muss nicht entscheiden, ob Webhosting das Hauptgeschäft ist, VPN zusammen mit Zugang verkauft wird, welcher Hypervisor einen VPS betreibt, welcher Router in der Colocation-Fläche steht oder wie eine Universität ihre Fachbereiche organisiert. Solche Tatsachen werden nur relevant, wenn ein benanntes Policy-Prädikat sie benötigt.

Minimal bedeutet nicht vage. Eine kleine Rollendefinition muss bei ihrem begrenzten gemeinsamen Anspruch gerade deshalb präzise sein, weil sie weniger Herrschaft über das Unternehmen beansprucht.

Quellen

Was die Belege nicht zeigen

Keine Quelle dieses Pakets benennt eine reale Organisation, die ARIN wegen der ISP/LIR-Begriffe auf den falschen Antragspfad gesetzt hätte. Es gibt keine Messung zusätzlicher Tickets, Verzögerungen, Ablehnungen oder veränderter Zuteilungsgrößen. Die aktuellen internen Antragsfelder, Schulungen und die vollständige Einstufungslogik sind ebenfalls nicht öffentlich.

Die Belege tragen deshalb einen Textbefund und eine Migrationsempfehlung. Sie tragen weder einen Vorwurf des Fehlverhaltens noch eine Häufigkeitsschätzung.

Auch der Ausgang des Policy-Prozesses ist offen. Der unabhängige Tracker führt ARIN-2025-1 als Draft Policy. Eine neue Fassung kann den direkten Mengenbezug wiederherstellen, den Teilmengensatz entfernen, nur LIR verwenden oder die Definitionen neu entwerfen. Eine Prüfung des neuen Objekts wäre eine neue Tatsache und keine nachträgliche Bestätigung der heutigen Schlussfolgerung.