Public DENIC mailinglist

[lutz AT iks-jena.de (Lutz Donnerhacke)]

* Sabine Dolderer/Denic wrote:
>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.

Es ist nachvollziehbar, hat aber nichts mit Personenhandles zu tun.

So wie es beschrieben ist, vermittelt der Reseller über das DENIC Mitglied
der DENIC e.G. einen Vertrag.

Es besteht somit kein Vertrag zwischen dem Reseller und dem Kunden, der über
einen Vertrag des Resellers mit dem DENIC Mitglied abgewickelt wird, den das
DENIC Mitglied aufgrund der Genossenschaftsvereinbarung abwickelt.

Korrekt?

>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.

Korrekt. Es besteht allerdings keine Notwendigkeit, diese Daten zu
publizieren. Das machen andere Firmen mit ihren Kunden ja auch nicht.

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

Das Problem ist, ob überhaupt Handles notwendig sind.

>Kurz zur Idee.
>
>Ziel ist, daß das Mitglied für die von ihm verwalteten Personen selbst die
>Verantwortung übernimmt.

Das kann man in der Genossenschaftsvereinbarung ja so festlegen.

>Wir haben diskutiert, ob es sinnvoll ist die Handlekonstruktion
>vorzudefinieren, oder ob wir dies dem Mitglied überlassen.

Da es eine rein interne Datenverwaltung der DENIC e.G. ist, interessiert es
nicht wirklich die Öffentlichkeit. Daß ihr das aber offen diskutiert, ist
sehr erfreulich und lobenswert.

>Wir haben uns dann entschlossen , daß es als Prefix DENIC-Mitgliednummer
>(4-stellig) hat (an dem DENIC- vorne oder hinten hänge ich nicht).

Wenn es öffentlich sein sollte, dann lieber als Postfix, anderenfalls gibt
es Kollisionen: Er verwaltet DENIC-ARIN?

>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.

Korrekt. Eine Frage der Vertragsgestaltung zwischen Reseller und DENIC
Mitglied.

>Das hat den Vorteil, daß immer derjenige, der den konkreten geschäftlichen
>Kontakt zu einer Person hat, diese auch pflegt.

Korrket. Eine Frage der Vertragsgestaltung zwischen Reseller und Kunde.

Ich fasse mal kurz die Rechtslage aus Teil 'Handhabung' zusammen:
  Es besteht ein Vertrag zwischen dem Reseller und dem Kunden, der über
  einen Vertrag des Resellers mit dem DENIC Mitglied abgewickelt wird, den
  das DENIC Mitglied aufgrund der Genossenschaftsvereinbarung abwickelt.

>Repräsentiert wird die Person innerhalb unserer Datenbank durch das
>Handle.

Das ist aber gar nicht notwendig, da ihr keinen Vertrag mit dem Kunden habt.
Und damit sagt das TDDSG: Keine Datenerfassung durch oder für Euch.

>Was die Veröffentlichung dieser Handle anlangt, so werden diese nicht
>(zumindest aller Voraussicht nach nicht) veröffentlicht,

Logisch.

>da wir um das sinnvoll zu machen, auch wieder die Suche über den
>Personenbestand zulassen müssen, was heute schon hinlänglich diskutiert
>wurde.

Ack. Zentrale Handles bedingen eine Suche auf Mehrfacheinträge.

>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.

Diese Handles müssen (und dürfen) nicht mal bei Euch landen. Ihr habe
Vertragsnummern zu den Mitgliedern, die haben welche zu den Resellern und
die haben welche zu den Kunden. Perfekt!

>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.

Ihr verweist den Rechtsanwalt an das Mitglied, der an den Reseller verweist.
Kein Problem. Für die meisten Anfragen genügt ja die desc: der Firma, auf
die die Domain eingetragen wurde. (Ala Grundbuch)

>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.

Nicht bis ins letzte Detail ohne Rücksprache mit den Datenhaltern, aber es
ist leicht ermittelbar.

>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.

Man braucht nicht mal mehr etwas in Auftrag geben. Daten werden gepflegt und
gehalten, wo sie auftreten. Konform zum TDDSG.

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

Ack.

>4. Handles auch für Subprovider

Eine logische Konsequenz, die Euch gar nicht tangiert, weil ihr sie gar
nicht mitbekommt.

>Wir haben versucht das Problem durch die freie Gestaltung des Handlefelds
>zu lösen.

Warum? Ihr habt doch nur die Vertragsnummer des Mitglieds.

>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.

Overkill und Verstoß gegen den Datenschutz.

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

Klar. Wie in der Wirtschaft auch beim Einschalten von Subfirmen.

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

Ja, allerdings solltet Ihr Euch bitte klar werden, welche rechtliche
Modellierung des Vertragswerkes Ihr wollt. Vertragsvermittlung für Euch oder
Reseller-Kunden-Verträge. Der Rest ergibt sich von selbst.

Im ersten Fall könnt Ihr die eine Franchise-Struktur bauen, bei dem der
Endvertrieb in Form von Resellern auch das Inkasso macht und die genannte
zentrale Datenbank mit strukturierten Handles für den internen Gebrauch
aufbauen.

Im zweiten Fall entfällt das alles. Ihr registriert und veröffentlicht nur
die NS zu einer Domain und die Beschreibung des Eigentümers. Intern wißt
ihr, über welchen Weg das reinkam, aber nicht die vollen Details dieses Weges.

Nur beides zusammen: Rechtlich unmöglich.