Public DENIC mailinglist

[Henning Brauer <lists-denic-public-l AT bsws.de>]

On Wed, Mar 28, 2001 at 10:33:13PM +0200, Sabine Dolderer/Denic wrote:
> 
> Hallo,
> 
> ich versuche im folgenden einmal die Diskussion noch einmal zu
> versachlichen 

Das hat sie leider in der Tat noetig... schwadronieren ueber unsere boesen
Gesetze hilft nicht weiter.

> 1. Es gibt eine Zwang, die derzeit bei RIPE abgespeicherten
> Personeneinträge zur DENIC zu verlagern.

OK, akzeptiert.

> 2. Es gibt eine Notwendigkeit für die Registrierung und das Handling der
> Datenbank ein minimales Set an Personendaten zu speichern. 

Auch klar.

> 3. Wenn wir Personendaten speichern, finden darauf die entsprechenen
> Regelungen des Datenschutzes Anwendung.

Ebenso.

> Es gab nun mehrere Ideen das Problem zu lösen.
> 
> 1. Zentrale Handleverwaltung a la RIPE

Waere schoen, hat aber offenbar nicht sein sollen. Also hab ich jetzt nicht
nur RIPE-Handle (fuer inetnum) sondern auch ATNIC, CH (SWITCH), und DENIC.
Nicht zu vergessen CORE und NSI.
Naja. 

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

Waere aufgrund der simplizitaet vielleicht gar nicht so doof gewesen, ist
aber inkompatibel zum Rest der Welt.

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

Das ist doch immerhin mal ein Fortschritt.

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

Das aender der Adresse bei mehreren Provider ist akzeptabel, das duerfte ja
auch nicht unbedingt die breiyte Masse treffen.

Das Problem was ich (und viele andere) hiermit habe ist die nochmals
gestaerkte Macht der Member. Wechsele ich jetzt also "mein" Member muss ich
nicht nur ggf. alle Domains rueberziehen sondern darf auch noch _alle_
Handles duplizieren.
Warum wird das denn schon wieder nur auf Member beschraenkt? Warum kann
nicht eimnfach jeder, meinetwegen auch gegen eine Bearbeitungsgebuehr, so
ein prefix bekommen und dann selbst Aenderungen vornehmen? Dann kann man ja
auch gleich noch einen kleinen Vertrag machen so dass Eure rechtlichen
Bedenken erschlagen sind. Das ist rein technisch nicht allzu kompliziert, der
Verwaltungsaufwand sollte sich in Grenzen halten und es ist in etwa mit dem
Maintainersystem des RIPE, mit dem m. E. die meisten sehr gluecklich waren,
vergleichbar. 

> 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 halte ich durchaus fuer akzeptabel.

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

Das ist ja alles schoen, funktioniert nur in meinem obigen Vorschlag genauso. 
Ihr habt meines Erachtens zwei grosse Probleme nicht beachtet:
a) Reseller neigen dazu gerne mal "ihr" Member zu wechseln
b) Reseller sind nicht sonderlich daran interessiert dass jeder Franz "ihr"
Member rauskriegt

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

Ist ja schoen, loest nur das Problem nicht dass fuer jeden die komplette
Kette Reseller->(Reseller->)Member->Denic nachvollziehbar ist. Irgendwer
nannte das ganz passend "offene GEschaeftsbuecher" - nicht unbedingt unser
groesster Wunsch, ums mal vorsichtig auszudruecken.

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

Naja, leider nicht ganz wuerde ich sagen. Aber um das zu diskutieren sind
wir ja hier - es waere nur schoen wenn Du auch mal was zu den Vorschlaegen
unsererseits sagen koenntest und Ihr sie tatsaechlich auch beruecksichtigen
koenntet. So lange die Huerde Member zu werden so hoch liegt wie sie das
(noch?) tut koennt Ihr die reseller nicht so einfach abbuegeln...

-- 
Henning Brauer     | BS Web Services
Hostmaster BSWS    | Roedingsmarkt 14
hostmaster AT bsws.de | 20459 Hamburg
http://www.bsws.de | Germany