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

Wed Jun 7 08:27:08 UTC 2017

There is no basis for restricting ungated access any more so than the
domain's existence or the string of characters registered.

On Wed, 7 Jun 2017 at 11:22 Volker Greimann <vgreimann at key-systems.net>
wrote:

> I have no objections against having this data available and accessible.
> The question is whether it should be as accessible as it is now or
> whether there could be certain restrictions. A tiered access system as
> has been proposed would solve this beautifully.
>
> In this case, the dates would be on the second tier (the first tier
> being full unhindered access), which would entail some form of
> authentification and bulk access restrictions. Every single one of the
> uses Andrew desribes would remain possible and unproblematic, but the
> data would no longer be in as much danger of being abused as it is today.
>
> Best,
>
> Volker
>
>
> Am 06.06.2017 um 22:07 schrieb Michael Peddemors:
> > +1 as well..
> >
> > .. but with so many +1's on having that data publicly accessible, it
> > would be interesting to take a straw poll, to a wider audience on that
> > simple question..
> >
> > It would be also nice to see what category the parties in each camp
> > lie? We know that everyone involved in making the internet a safer and
> > better place (security companies, law enforcement et al) want it
> > available, and to define 'thin data' as wide as possible, and I can
> > understand that some consideration to privacy be considered so that it
> > doesn't go too wide, but not really certain I understand the position
> > of those that want it as 'thin' as possible, or non-existant, and/or
> > the parties behind that position and their numbers.
> >
> > And of course the ever present question for both camps, is the opinion
> > coming from a place where there are financial motivations (not that
> > necessarily there is anything wrong with that <sic>) that have formed
> > the basis of that opinion. (eg, if the money equation was removed,
> > would you still have that opinion, or even be in the conversation?)
> >
> > For all we know, the privacy camp are in very small numbers in this
> > conversation, and while they might hold legitimate positions, maybe it
> > isn't enough to affect the directions/positions of ICANN as a group
> > going forward.
> >
> > And IMHO, even if it was 50/50 split, if it came down to two camps, eg
> > 'the ones keeping us safe' and 'it affects/risks our pocketbooks', I
> > would err on policies that would aid the former..
> >
> > Don't want 'politics' to affect such important decisions..
> >
> >
> >
> > On 17-06-06 11:22 AM, Andrew Sullivan wrote:
> >> 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.
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-- 
jonathan matkowsky, vp - ip & head of global brand threat mitigation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170607/25f66069/attachment-0001.html>