[gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from Next-Generation RDS PDP Working Group Call - 17 May 2017

Thu May 18 12:46:29 UTC 2017

Is load balancing always a security measure?

Chuck

-----Original Message-----
From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Paul Keating
Sent: Thursday, May 18, 2017 6:18 AM
To: benny at nordreg.se
Cc: gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org>
Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from Next-Generation RDS PDP Working Group Call - 17 May 2017

I am agreeable only to those restrictions imposed as a security measure by the source (e.g. Load balancing, etc).

Paul

On 5/18/17, 12:06 PM, "benny at nordreg.se" <benny at nordreg.se> wrote:

>There can be technical issues where you need to do so, that was pointed
>out during the call
>--
>Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
>
>Benny Samuelsen
>Registry Manager - Domainexpert
>
>Nordreg AB - ICANN accredited registrar
>IANA-ID: 638
>Phone: +46.42197080
>Direct: +47.32260201
>Mobile: +47.40410200
>
>> On 18 May 2017, at 11:59, Paul Keating <Paul at law.es> wrote:
>>
>> Yes, the CURRENT issue is Thin Data only.
>>
>> My comment was indented to deal with what I understood to be a
>>re-assertion that THIN DATA be subject to access restriction.
>>
>> To reiterate,  There is no basis to restrict THIN DATA (IMHO) for the
>>simple reason that there is no Personal ID Data in the set.  Nor are
>>there any intellectual property rights in THIN DATA.
>>
>> That means anyone can harvest what they want subject only to load
>>balancing restrictions imposed by the source from which the data is
>>being harvested.
>>
>> Paul
>>
>> From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Chris Pelling
>><chris at netearth.net>
>> Date: Thursday, May 18, 2017 at 11:46 AM
>> To: gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org>
>> Subject: Re: [gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes
>>from Next-Generation RDS PDP Working Group Call - 17 May 2017
>>
>>> Got to agree with Andrew on this - my thoughts on thin is exactly
>>>what Verisign shows now which is basically domain name, dates,
>>>registrar, nameservers and status << That is the common term of "THIN DATA".
>>>
>>> As I said, thin data I have no issues with, even data harvesting
>>>companies having it lawfully.
>>>
>>> Kind regards,
>>>
>>> Chris
>>>
>>> From: "Andrew Sullivan" <ajs at anvilwalrusden.com>
>>> To: "Paul Keating" <paul at law.es>
>>> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org>
>>> Sent: Thursday, 18 May, 2017 00:52:33
>>> Subject: Re: [gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from
>>>       Next-Generation RDS PDP Working Group Call - 17 May 2017
>>>
>>> No, the data we are currently discussing is thin data.  Among it, I
>>>believe only the domain name and maybe the name servers are entered
>>>by the registrant, and both of those are required if there is to be a
>>>domain name that works on the Internet.
>>>
>>> I find it quite frustrating that we do not seem to be able, as a
>>>group, to keep these elementary distinctions before us during
>>>discussion.
>>>
>>> A
>>>
>>> --
>>> Andrew Sullivan
>>> Please excuse my clumbsy thums.
>>>
>>> On May 17, 2017, at 18:06, Paul Keating <paul at law.es> wrote:
>>>
>>>> Licensing what and from whom?
>>>>
>>>> This is data entered by the registrant.  Privacy issues apply only
>>>>to the subset of individuals.
>>>>
>>>> Sent from my iPad
>>>>
>>>> On 17 May 2017, at 23:38, Greg Shatan <gregshatanipc at gmail.com> wrote:
>>>>
>>>>> One way to deal with harvesters is through a licensing set-up.
>>>>>There are legitimate reasons to have the full dataset, and these
>>>>>should be accommodated in a controlled environment.  Preventing bad
>>>>>harvesters is worthwhile, prevent all harvesting is another issue
>>>>>entirely....
>>>>>
>>>>> Greg Shatan
>>>>> C: 917-816-6428
>>>>> S: gsshatan
>>>>> gregshatanipc at gmail.com
>>>>>
>>>>>
>>>>>
>>>>> On Wed, May 17, 2017 at 3:00 PM, Michael Peddemors
>>>>><michael at linuxmagic.com> wrote:
>>>>>> On 17-05-17 10:46 AM, Jeremy Malcolm wrote:
>>>>>>> On 17/5/17 9:40 am, Michael Peddemors wrote:
>>>>>>>> Yes, this is the common argument, however IMHO this is a red
>>>>>>>>herring..
>>>>>>>> There are more efficient ways for 'harvesters' to gain data,
>>>>>>>>and  others way to prevent such abuse..
>>>>>>>>
>>>>>>>> Again, IMHO this argument is another case of impacting the many
>>>>>>>> legitimate users, for the sake of a few bad apples..
>>>>>>>>
>>>>>>>> And I havent' seen any arguments yet, of a case scenario which
>>>>>>>>can't  be addressed by other means..
>>>>>>>
>>>>>>> So to reverse this, what are the *legitimate* purposes of
>>>>>>>harvesting?
>>>>>>
>>>>>> Who said anything about arguing for 'harvesting' as a legitimate
>>>>>>purpose?  I didn't, and even pointed out that there are way(s) to
>>>>>>target harvesters..
>>>>>>
>>>>>> I was pointing out the legitimate purposes of accessing the data..
>>>>>>
>>>>>> And many of those cases have already been stated, I could
>>>>>>re-iterate those arguments, and give examples of why 'we' need to
>>>>>>access the data, but again, 'harvesting' is different than access.
>>>>>>
>>>>>> Arguing that we 'have to stop harvesters' by denying access to
>>>>>>the data for legitimate purposes was the original point.  There
>>>>>>are other means to target those perpetrators..  But it shouldn't
>>>>>>be used as a 'scary boogeyman' exists, so everyone lock your doors.
>>>>>>
>>>>>> To paraphrase.. "Just because criminals exist, doesn't mean that
>>>>>>civilians can't walk the street".  That is a 'gut reaction' of
>>>>>>fear, and not a solution.  Better policing, targeting criminals,
>>>>>>or carry a big stick solves that :)
>>>>>>
>>>>>> Nuff said.. as I said, lets' place case scenario's and argument
>>>>>>each on their merits.. and not react to a 'undefinable' threat..
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> "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
>>>>>
>>>>> _______________________________________________
>>>>> gnso-rds-pdp-wg mailing list
>>>>> gnso-rds-pdp-wg at icann.org
>>>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>> _______________________________________________
>>>> gnso-rds-pdp-wg mailing list
>>>> gnso-rds-pdp-wg at icann.org
>>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>
>>> _______________________________________________
>>> gnso-rds-pdp-wg mailing list
>>> gnso-rds-pdp-wg at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>> _______________________________________________ gnso-rds-pdp-wg
>>>mailing list gnso-rds-pdp-wg at icann.org
>>>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>

_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg