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

Thu May 18 19:22:23 UTC 2017

I've just attended a webinar on strategies for companies on how to deal with the GDPR. This might help those who are afraid of getting fined. I'm not sure this should be distributed beyong our WG, though, as there might be copyright issues. 
In the ensuing discussion, two highlights:  - Mr. Baladi doesn't believe companies will be fined 4% of their revenues, if they show they are trying to comply. There will be leniency during the first couple of years.- Need to show processes and will to implement privacy laws.  Nathalie  

    On Thursday, May 18, 2017 2:57 PM, "Gomes, Chuck via gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org> wrote:

 As others have pointed out since I asked my question, load balancing may be done for reasons other than security.  My point is this:  restricting load balancing for security reasons only may be too restrictive.

Chuck

-----Original Message-----
From: Paul Keating [mailto:paul at law.es]
Sent: Thursday, May 18, 2017 12:32 PM
To: Gomes, Chuck <cgomes at verisign.com>
Cc: benny at nordreg.se; 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

For systems integrity, yes.

Sent from my iPad

> On 18 May 2017, at 14:46, Gomes, Chuck <cgomes at verisign.com> wrote:
>
> 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
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170518/c2acb45f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FTI+and+Bloomberg+BNA+GDPR+Webinar+May+18+2017+v10.pdf
Type: application/pdf
Size: 1751780 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170518/c2acb45f/FTIandBloombergBNAGDPRWebinarMay182017v10-0001.pdf>