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

Greg Aaron gca at icginc.com
Thu May 18 14:23:26 UTC 2017


Dear Chuck:
Load-balancing is something very different from rate-limiting.  
Load-balancing is not always a security or stability measure.  As Michele says, it is a method to keep stuff up and running efficiently.  It can be a technique to deal with DoS or peak load.
I am not sure how load-balancing is germane to our conversations.  Load-balancing exists to keep services responsive, to make sure a service responds to queries.  It is not a way to restrict responses (which is what rate-limiting is). 
Rate-limiting is not always a security or stability measure.  Sometimes it's just a way to limit access to a resource for business reasons.
All best,
--Greg


-----Original Message-----
From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Michele Neylon - Blacknight
Sent: Thursday, May 18, 2017 10:01 AM
To: Gomes, Chuck <cgomes at verisign.com>; Paul at law.es; benny at nordreg.se
Cc: 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

Load balancing isn’t really a security measure, more of a “let’s keep this stuff up and running and stable and usable”



--
Mr Michele Neylon

Blacknight Solutions

Hosting, Colocation & Domains

http://www.blacknight.host/

http://blacknight.blog /

http://ceo.hosting/

Intl. +353 (0) 59  9183072

Direct Dial: +353 (0)59 9183090

-------------------------------

Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty

Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

On 18/05/2017, 13:46, "gnso-rds-pdp-wg-bounces at icann.org on behalf of Gomes, Chuck via gnso-rds-pdp-wg" <gnso-rds-pdp-wg-bounces at icann.org on behalf of gnso-rds-pdp-wg at icann.org> 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
    

_______________________________________________
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