Public DENIC mailinglist

[Daniel Roesen <noc AT entire-systems.com>]

Hallo!

> also ich das Wort "Annexion" höre ich in dem Zusammenhang nicht so gerne 
> ;-). 

Das mag sein, aber es gibt ne MENGE Leute die das so sehen... :-]

> Richtiger ist doch, daß wir die Objekte, die im Zusammenhang mit der 
> Registrierung und Verwaltung von DE-Domains stehen zum einen in unsere 
> Datenbank verlagert (Domainobjekte) und bei von Domains referenzierten 
> Objekten (Personenobjekte) wir die Informationen, die wir für die 
> Verwaltung dieser Domains benötigen, kopiert haben.

Warum die doppelte Datenhaltung? Da ja eh eine Migration auf DENIC-
Handles geplant ist, waere doch ein back-refer wesentlich angebrachter.

> Danach haben wir Teile dieser Daten (wobei wir uns in dem Bereich mit 
> etlichen Juristen und Datenschützern beraten haben) wieder öffentlich 
> gemacht haben.

Interessant. Und die hatten kein Problem damit, dass Daten, die der
Kunde zur Veroeffentlichung in der RIPEdb in einer bestimmten Form
und Vollstaendigkeit uebergeben hat, ploetzlich woanders (whois.denic.de)
in unvollstaendiger (und teilweise falscher und sinnentstellender Form)
wiederveroeffentlicht wird?

> Wir werden einen Teil davon so schnell wie möglich wieder zugänglich 
> machen, es handelt sich dabei im einzelnen um phone & fax beim tech-c & 
> zone-c, desweiteren remarks und trouble, wobei wir beide unter remarks 
> zusammenfassen werden.

Damit kann man wohl leben. Allerdings sollte sowas mit denjenigen
abgesprochen sein, die sowohl trouble: als auch remarks: benutzen, denn
ein

remarks:  xyz AT fasel.de

sagt nicht unbedingt aus, dass man sich bei "Trouble" an diese
Adresse wenden soll... :->

> Die changed-Zeile werden wir so abändern, daß klar wird, daß das
> Datum, das angezeit wird der Zeitpunkt der Übernahme in die
> DENIC-DB ist.

Das heisst auf deutsch, dass DENIC weiterhin daran festhaelt, die
Objekthistory komplett untern Tisch fallen zu lassen?

> WICHTIG: Die Daten in der RIPE-DB sind weiterhin verfügbar,
> Änderungen an Personen im RIPE werden derzeit von uns unverändert
> kopiert. Wir veröffentlichen daraus allerdings nur ein
> eingeschränktes Subset.

Dann soll whois.denic.de aber nicht die "verkrueppelten" Contact-
Datensaetze liefern, sondern die vollstaendigen und korrekten
aus der RIPEdb oder halt garkeine, mit dem Hinweis "ask whois.ripe.net
for contact data records". Ggfs (sinnigerweise) per referral.
Datenschutzgruende kann es ja nu keine geben, da in der RIPEdb
weiterhin die kompletten, unmodifizierten Daten liegen.

> > * Es sind Informationen ueber Plaene seitens DENIC durchgesickert, in
> >   Zukunft nur noch DENIC-Contact-Objects der From DENIC-<member>-<ID>
> >   zuzulassen. Wie sehen diese Plaene konkret aus?
> >
> 

> Die Personenpflege wird dann, wie auch heute schon die Domainpflege 
> einem DENIC-Mitglied zugeordnet, wobei diese - wie auch schon bei der 
> Domainpflege - Interfaces für ihre Reseller zur verfügung stellen werden. 

Und wie erklaere ich unseren Kunden, dass Ihre Daten die sie UNS zur
Veroeffentlichung beim RIPE unter UNSEREM PGP-Schutz uebergeben haben,
nunmehr nicht mehr unter unserer Kontrolle liegen?

Wie stellt DENIC sicher, dass eine komplett PGP-authentifizierte Kette
(end-to-end) vom Reseller zum DENIC fuer Anlegen/Update/Delete dieser
Objekte vorhanden ist, um den bislang bestehenden Schutz der Daten
in gleichem Masse aufrecht zu erhalten?

> Es wird so aussehen, daß die RIPE-Referenzen zu einem Zeitpunk X 
> eingefroren werden und weitere Änderungen in der RIPE-DB nicht mehr 
> nachgezogen werden. Das Anlegen von DENIC-Personenobjekten wird aber erst 
> notwendig, wenn die erste Änderung bei der Person ansteht.

Wann ist der Zeitpunkt X?

> > * Inwiefern wird das DENIC sicherstellen, dass Reseller von DENIC-
> >   Mitgliedern in Zukunft weiterhin "Herr" ihrer Daten wie bislang
> >   beim RIPE sind (Stichworte auto-dbm AT ripe.net, mnt-by:, notify: etc.)?
> 
> Das Problem ist eher, daß die DENIC "HerrIn ;-)" ihrer Daten bleibt

Moment... seit wann sind die Contact-Daten Daten des DENIC? Das sind
Daten der Kunden, die uns zur Veroeffentlichung in der RIPE-DB
uebergeben wurden. Unter UNSEREM Schutz.

Nebenbei: wenn mnt-nfy: und notify: wegfallen... wie soll diese
Funktionalitaet in der neuen, geplanten Struktur abgebildet werden?
Oder faellt die dann auch ersatzlos weg? Oder muessen die DENIC-
Mitglieder auch wieder komplizierte Parser und "Informations-Relays"
fuer ihre Reseller basteln?

> d.h. daß zu jedem Zeitpunkt eine kontrollierte Zuordnung der Domain-
> zu den Personendaten existiert

Das tat es auch vor Monaten vor allen Aktionen schon. Warum nu also
alles Umwerfen und damit nen haufen Leuten nen Haufen unnoetiger
Arbeit (und damit Kosten) bescheren?

> denn das ist es was von uns erwartet wird und zu 
> diesem Zweck versuchen wir stabilere und definiertere Beziehungen zu 
> haben.

...und eine Menge redundater (und Redundanzen sind fehlertraechtig)
Daten in RIPE-DB und DENIC-DB. Siehe Antwort von Gerd Doering.


Viele Gruesse,

Daniel Roesen

-- 
Entire Systems Network Operations Center            noc AT entire-systems.com
Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany
InterNIC-Handle: ES1238-ORG  RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55
GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc
GnuPG/PGP Fingerprint:  1F3F B675 1A38 D87C EB3C  6090 C6B9 DF48 BF3C 40C9

Attachment: pgp4TBTT_V4cE.pgp
Description: PGP signature