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

Paul Keating paul at law.es
Thu May 18 22:09:42 UTC 2017


Hi chuck,

I was trying to limit restrictions on access to thin data to reasons of security to make it clear that it is not to inquire as to identity or purpose.   I had issues with payment/token gateways and i tended to give load balancing as an example. 

Sent from my iPad

> On 18 May 2017, at 20:57, Gomes, Chuck <cgomes at verisign.com> 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


More information about the gnso-rds-pdp-wg mailing list