[gnso-rds-pdp-wg] Why the thin data is necessary

Wed Jun 7 08:17:39 UTC 2017

Hi Andrew,

I do not dispute that having this information (specifically, the 
created, updated and expiration dates) accessible and available is 
useful and beneficial, I am just asking the question whether these dates 
should be available without authentification.

Is there a harm in asking the entity requesting this data from 
identifying themselves and stating a purpose for the access?

I see your point that there is benefit to having this data, so would 
putting it behind the access wall (or fence) be an acceptable compromise 
solution? That way, harvesting of this data would be impacted to some 
effect, yet all the uses for this data you described below would still 
be possible. In other words, the beneficial potential of this data would 
remain as it is today, but the harm that can be done with it would be 
restricted.

I have no objections whatsoever against the DNS settings and domain 
statuus being public.

Best,

Volker

Am 06.06.2017 um 20:22 schrieb Andrew Sullivan:
> Hi,
>
> On the call today there were arguments being made about why certain
> fields should not be publicly accessible.  In effect, what we are now
> arguing about, in talking about what should be considered "thin data",
> is the definition of the set of data to which unauthenticated access
> should be permitted.  (Let us please not get distracted by what is
> actually required by the RAA or anything like that just now, since the
> outcome of this policy discussion might change that.)
>
> There were several arguments put forth about whether the created on,
> updated on, and expiry dates should be included.  Similarly, people
> discussed whether the domain status values should be included.  I
> believe they must be.
>
> The Internet is unlike many other technologies because of its radical
> decentralization.  That is not some sort of political choice, but
> instead a fundamental part of the design of the Internet: it's a
> network of networks (of networks…) formed by voluntary interoperation
> among the participants.  Participants in the Internet interoperate
> without setting up formal contractual arrangements between all the
> participating parties.  This feature is part of what has made the
> Internet so successful compared to other telecommunications systems,
> because the barrier to entry is really low.  But that design comes at a cost.
>
> The cost is that there's not always a party to speak to, with whom one
> has a pre-existing relationship.  If communications break down between
> two telephone customers, they know whom to call: the phone company.
> The phone company also has contractual (or sometimes treaty)
> relationships to other phone companies.
>
> The Internet doesn't work that way.  If you and I are communicating
> over the Internet, there is no guarantee of direct contractual
> relationships all the way along the transit path: that's what open
> peering policies ensure.  The way we make this work in fact is by
> placing the responsibility for troubleshooting out at the edges.  And
> because of that, when I need to troubleshoot my site I need to have
> tools with which to do that.
>
> In domain-based communications (such as email, IP telephony, websites,
> money transfer, and thousands of other applications), when I encounter
> a problem with the communication I need to answer whether the problem
> is in _my_ network operation, or in the other end.  Important data to
> rule out "the other end" is in the thin RDS data.
>
> Obviously, the nameserver and DNSSEC information in the RDS will allow
> me to tell whether what is in the global DNS is what ought to be
> there.  For instance, if the RDS has one value for the name servers,
> but the DNS returns something else, there is a problem.
>
> Less obvious but just as important are the status values.  If a name
> is on Hold or is pendingTransfer or something like that, it can tell
> me that something is up.  A name that doesn't appear in the DNS but
> has a full complement of name servers in the RDS, for example, might
> be on hold; and I can't tell that without seeing the status values.
>
> In the same way, the dates in the RDS allow a troubleshooter to
> understand what might be wrong when things are broken.  If a name is
> set to expire in a day and you're getting a parking page on the
> website, you have a clue about what is going on.  Most of the examples
> cited in
> https://whoapi.com/blog/1582/5-all-time-domain-expirations-in-internets-history/
> were trivial to understand for help desks that could see that a name
> that should have existed for some time was just hours old, because the
> created_on date was available.  And if you start having trouble and
> see a domain was updated about the same time the trouble started, you
> have a pretty good clue that the problem is most likely at the target
> domain, and not in your own network.
>
> As for the question of why the global Internet infrastructure needs to
> help with this, the answer is that _that's what the infrastructure is
> for_.  We have registrars and registries in order to co-ordinate these
> assignments and make those assignments available, in support of the
> distributed administration and operation of the Internet.  If the
> infrastructure isn't providing this kind of information in order to
> help administrators of various Internet administrators, then it isn't
> doing its job.
>
> The Internet is a distributed system.  If you want to make distributed
> systems work, you have to allow the operators to have enough
> information to do their jobs independently of one another.  So,
> regardless of where one lands on whether any of this data is personal
> data, it makes no difference.  If you want the domain name system to
> continue to work reliably, you have to publish this data.
> Centralization and locking the data up for just registrars simply
> won't scale.
>
> Best regards,
>
> A
>

-- 
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann
- Rechtsabteilung -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems

Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP
www.keydrive.lu

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.

--------------------------------------------

Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann
- legal department -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems

CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP
www.keydrive.lu

This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.