Zusammenfassung

  • draft-ietf-regext-epp-same-entity-01 überlässt Gleichwertigkeit und Optionen der Registry; Richtlinie und Einigung mit Registraren bleiben außerhalb der Spezifikation.
  • Transfer und Löschung wirken auf alle zugeteilten Mitglieder, gegebenenfalls über mehrere Registries in einem zentralen Repository.
  • Ein Gleichwertigkeitsbeleg muss Richtlinien- und LGR-Version, Parteien, Primary Domain, Mitgliedsnachweis, Ausnahmen, Reichweite und Ergebnis verbinden.

Die Gruppe entsteht durch eine Regel, nicht erst durch Registrierung. Der erste Name wird Primary Domain; weitere zugeteilte Namen bleiben beim selben Registrar und Registranten. Ein realistisches Beispiel umfasst 10^15 mögliche Namen. Das Protokoll kann zugeteilte Mitglieder liefern, nicht die ganze Menge. Ohne die Regel ist das Protokollprotokoll unvollständig.

Prescribed, Settable und Linked sind Beispiele, keine Pflichtklassen. Ändert sich die LGR, kann sich die Menge ändern, obwohl die EPP-Nachricht gleich aussieht.

Atomar heißt nicht richtig klassifiziert

Beim Löschen der Primary Domain werden alle zugeteilten Mitglieder gelöscht oder keines. Das schützt vor einem zerrissenen Zustand. Es beweist aber nicht, dass die richtige Richtlinie, Version oder Ausnahme verwendet wurde. Auch ein Irrtum kann konsistent ausgeführt werden.

Ein Transfer eines Mitglieds erfasst die ganze Gruppe. Bei gemeinsamer Richtlinie und zentralem Repository kann er Registry-Grenzen überschreiten. Das bewahrt Einheit, konzentriert aber Autorisierungsfehler. Alte Clients werden sicher abgewiesen, verstehen ohne Richtlinienkontext jedoch womöglich nicht warum.

Allocated bedeutet nicht zwingend DNS-delegiert. Allocatable reserviert für dieselbe Entität, Blocked sperrt für alle, Exempted bewahrt Altbestände bis zur Konvergenz. Solche Ausnahmen dokumentieren bestehende Rechte.

Der Entwurf hat offene Fehlercodes, Sicherheits-, DS- und Unicode-Fragen; der IANA-Abschnitt ist leer. Datatracker nennt keinen beabsichtigten RFC-Status, der Kopf Standards Track. Es ist kein RFC und kein Nachweis eines Betriebs.

Der Beleg macht Macht nachvollziehbar

Der vorgeschlagene Beleg hält Versionen, Wirksamkeit, Parteien, Repository, Primary Domain und Mitgliedsnachweis fest. Er dokumentiert Befehl, zugeteilte Mitglieder, beteiligte Registries, Zustände, Ausnahmen sowie Transaktionskennungen und vollständigen Rollback.

Die Registry verantwortet die Regel, der Registrar die Identität, das Repository Symmetrie und Ausführung. Die Menge darf implizit sein; ihre Autorität nicht.

Quellen