Public DENIC mailinglist

["Sabine Dolderer/Denic" <dolderer AT denic.de>]

Hallo,

ich versuche im folgenden einmal die Diskussion noch einmal zu
versachlichen und die wesentlichen Argumente aufzuführen, wobei ich auf
einige Punkte detaillierter eingehe und auf andere nicht mehr, da sie schon
hinlänglich erläutert wurden. Zuerst einmal die
Fakten:

1. Es gibt eine Zwang, die derzeit bei RIPE abgespeicherten
Personeneinträge zur DENIC zu verlagern. Gründe dafür sind vielfältig. Die
wichtigsten sind, daß wir ein Problem mit den Datenschutzbehörden haben und
daß das RIPE diesen Service nicht mehr leisten möchte.
2. Es gibt eine Notwendigkeit für die Registrierung und das Handling der
Datenbank ein minimales Set an Personendaten zu speichern. Diese ergibt
sich daraus, daß wir immerhin einen Vertrag mit dem Domaininhaber über die
Domain haben und ihn deswegen - zumindest gelegentlich - erreichen müssen.
3. Wenn wir Personendaten speichern, finden darauf die entsprechenen
Regelungen des Datenschutzes Anwendung.

Über diese Fakten möchte ich eigentlich nicht diskutieren müssen, das
sollte nachvollziehbar sein.

Aus 3. folgt allerdings unmittelbar - und das ist das erste Problem - daß
indem wir die Daten bei uns halten, die speichernde Stelle sind und damit
das Ganze nicht mehr auf die Kollegen in den Niederlanden schieben können.
(Was jetzt auch schon schwierig ist, da wir die Einträge dort faktisch
erzwingen, aber das ist ein anderes Thema). Daneben dürften die dieselben
Probleme haben, was wiederum ein Idee gibt, warum sie es nicht mehr machen
wollen.

Es gab nun mehrere Ideen das Problem zu lösen.

1. Zentrale Handleverwaltung a la RIPE

PRO: Technisch elegant - da minimale Daten. Keiner schreit, da niemand sich
umgewöhnen muß. Bei Änderungen einer Person muß dies nur einmal eingepflegt
werden.
CONTRA:
- Man muß dem jeweils anderen vertrauen, da jedes Mitglied uns gegenüber
den Dateninhalten gerade steht (auch finanziell), daß die Daten, die es zu
einer Domain einträgt korrekt sind.
Die Folgen bei einem falschen Eintrag gehen bis zur Löschung der Domain.
Daraus ergeben sich für manche schon jetzt die Lösung, daß man Daten für
"seine" Domains grundsätzlich nur mit "seinem" Maintainer anlegt und
akzepiert. Man sieht also auch heute schon in der RIPE-DB mehrere Einträge
zu einer Person. Mit unterschiedlichen Handles und unterschiedlichen
Maintainern.
- Man müsste die Daten zur Verfügung stellen können, damit man von extern
suchen kann, ob jemand schon ein Handle hat.

2. Pro Domain grundsätzlich den gesamten Datensatz zu übertragen (inkl.
Personen und dernen Adressen)

PRO: Simpel
CONTRA:
- Bei Adressänderungen einer Person ergeben, gibt es u.U. sehr viele
Updates.
- Wenn diese nicht gemacht werden, erhebliche Gefahr für unkorrekte
Datensätze.

3. Handles pro Mitglied
(da gibt es auch wieder verschiedenen Spielarten, aber ich versuche mal zu
erläutern, warum wir denken, daß die von uns gewählte einigermassen allen
Beteiligten hilft).

Kurz zur Idee.

Ziel ist, daß das Mitglied für die von ihm verwalteten Personen selbst die
Verantwortung übernimmt. Wir haben diskutiert, ob es sinnvoll ist die
Handlekonstruktion vorzudefinieren, oder ob wir dies dem Mitglied
überlassen. Wir haben uns dann entschlossen , daß es als Prefix
DENIC-Mitgliednummer (4-stellig) hat (an dem DENIC- vorne oder hinten hänge
ich nicht). Danach ist das Mitglied frei die Identifier zu vergeben, wobei
eine Maximallänge vorgegeben ist.

Dadurch, daß das Mitglied den Rest frei definieren kann, kann es nun eine
Untergruppe an seine Subprovider weitergeben oder auch seine internen
Datenbankschlüssel als eigenen Schlüssel verwenden. Das Konzept lässt also
insbesondere eine Delegation der Verantwortung nach unten zu.

Das hat den Vorteil, daß immer derjenige, der den konkreten geschäftlichen
Kontakt zu einer Person hat, diese auch pflegt. Repräsentiert wird die
Person innerhalb unserer Datenbank durch das Handle. Wenn eine Person Kunde
von mehreren Providern ist, muß sie wie im richtigen Leben jedem seiner
Geschäftspartner die Änderung mitteilen. (Wenn ich bei mehreren Banken
Kunde bin, muß ich das auch).

Was die Veröffentlichung dieser Handle anlangt, so werden diese nicht
(zumindest aller Voraussicht nach nicht) veröffentlicht, da wir um das
sinnvoll zu machen, auch wieder die Suche über den Personenbestand zulassen
müssen, was heute schon hinlänglich diskutiert wurde. Das Handle ist also
nur der Schlüssel unter der euer Kunde bei uns repräsentiert ist. Das
ermöglicht dann auch Updates für diesen euren Kunden durchzuführen, aber
nicht für die Kunden der anderen.

Das hat für uns den Vorteil, wenn sich bei uns nun ein Rechtsanwalt meldet
und sagt, er kann den Domaininhaber und den Admin der Domain xxx.de nicht
erreichen bzw. nicht verklagen, wir sehr genau wissen, wer letztendlich für
die Einträge und die Updates zuständig ist. Wenn wir nun die Domain
kündigen, wegen Verletzung der Registrierungsbedingungen und der Kunde
wendet sich dann doch an uns wegen Verlust der Domain, dann wissen wir auch
wer schuld ist.

Das hat für euch den Vorteil, daß die Verantwortungskette klar definiert
ist und daß ihr sicher sein könnt, daß nur die Änderungen durchgeführt
werden, die von euch in Auftrag gegeben wurden.

Es hat den Vorteil, daß wir alle unserer Probleme mit den Datenschützern
lösen.

4. Handles auch für Subprovider

Wir haben versucht das Problem durch die freie Gestaltung des Handlefelds
zu lösen. Das ermöglicht den Subprovidern eine eigene interne
Kundenverwaltung auf unserer Schlüssel abzubilden und entsprechende
Verträge mit dem Mitglied vorausgesetzt, diese auch direkt durchzureichen.

Wir haben aber jemanden, der die rechtliche Verantwortung und Haftung für
den Eintrag übernimmt, was wir auf lange Sicht brauchen.

Wir sind eigentlich überzeugt, daß diese (Kompromiss)Lösung versucht eine
faire Balance zwischen allen Interessen zu halten.

Viele Grüße
Sabine


Sabine  Dolderer
DENIC eG
Wiesenhüttenplatz 26
D-60329 Frankfurt

eMail: Sabine.Dolderer AT denic.de
Fon: +49 69 27235 0
Fax: +49 69 27235 235