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

Tue Jun 6 23:09:33 UTC 2017

And of course politics can and should change to reflect the desires of the majority with balanced protections for the minority. 

Sincerely,
Paul Keating, Esq.

> On Jun 6, 2017, at 9:08 PM, Michael Peddemors <michael at linuxmagic.com> wrote:
> 
> +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
>> 
> 
> 
> 
> -- 
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
> 
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg