On June 4, 2018 at 17:01 ra...@psg.com (Randy Bush) wrote:
> once upon a time, when one received what had yet to be called spam, or
> logs showed an attack, one wrote to the owner of the source ip to tell
> them their system had been hacked. dunno about everyone else, but i
> stopped doing t
On Mon, Jun 4, 2018 at 9:34 PM, Dan Hollis wrote:
> On Mon, 4 Jun 2018, Rubens Kuhl wrote:
>
>> On Fri, Jun 1, 2018 at 1:56 AM, Hank Nussbacher
>> wrote:
>> Usually, identifying attackers at other online services is a duty on RIR
>> directories, and even the RIPE one is not suffering that many c
On Mon, 4 Jun 2018, Rubens Kuhl wrote:
On Fri, Jun 1, 2018 at 1:56 AM, Hank Nussbacher
wrote:
Usually, identifying attackers at other online services is a duty on RIR
directories, and even the RIPE one is not suffering that many changes due
to GDPR.
Also, GDPR doesn't prevent law enforcement ac
once upon a time, when one received what had yet to be called spam, or
logs showed an attack, one wrote to the owner of the source ip to tell
them their system had been hacked. dunno about everyone else, but i
stopped doing that sometime in the '80s.
randy
_ //` `\
_,-"\% //
Peering DB is also a directory service.
The only 'service' they provide is to distribute contact information.
Therefor maintaining and distributing information is in fact 'essential'.
Further, Peering DB make it easy to remove contact information.
The difference in legal systems makes Peering DB a
man. 4. jun. 2018 20.56 skrev Daniel Corbe :
>
> It occurs to me that operators might want to opt-in to have their data
> published through PeeringDB. From a purely pragmatic standpoint, I won’t
> peer with anyone I can’t reach out to and if you don’t have a 24/7 NOC
> chances are good that you’r
man. 4. jun. 2018 20.58 skrev Owen DeLong :
>
>
> Much of the information in Peering DB is people. In fact, IIRC, peering DB
> doesn’t really have “role” accounts.
>
> Peering DB is unrelated to whois.
>
> Owen
>
No actually I just checked and peeringdb has none of my personal
information. It has
On Fri, Jun 1, 2018 at 1:56 AM, Hank Nussbacher
wrote:
> On 31/05/2018 21:44, John Peach wrote:
> > On 05/31/2018 02:37 PM, Dan Hollis wrote:
> >> On Thu, 31 May 2018, b...@theworld.com wrote:
> >>> FWIW a German court has just ruled against ICANN's injunction and in
> >>> favor of Tucows/EPAG.
>
Kasper Adel wrote on 04/06/2018 06:41:
Assuming these vendors give the same SDK and similar documentation/support,
then what would be comparison points to consider, other than the obvious
(price, features, bps, pps).
power draw. Depending on your hosting costs, the differences in power
draw b
That’s a wonderful theory. However, in practice, it’s a bit different.
GDPR eliminates or at the very least complicates the maintenance of directory
services.
If past experience is any guide, once something becomes sufficiently difficult
to maintain while complying with regulation, said thing eve
> On Jun 3, 2018, at 22:44 , Baldur Norddahl wrote:
>
>>
>>
>>
>> Yeah, what Niels is really leaving out here is the open question of
>> whether or not GDPR will eventually lead to the destruction of Peering DB.
>>
>> Owen
>>
>
>
> Of course it will not. We just need to accept that only
man. 4. jun. 2018 17.31 skrev McBride, Mack :
> GDPR doesn't play well with directory listing services.
> BUT since providing contact information is exactly what a directory
> listing service does,
> It is safe to assume that this is 'essential' under GDPR.
>
No it is very clear that publishing p
On 04/06/18 06:41, Kasper Adel wrote:
> I’m thinking, how do i validate their claims about capability to do
> leaf/spine arch, ToR/Gateways, telemetry, serviceability, facilities to
> troubleshoot packet drops or FIB programming misses, hidden tools...etc
I'd start with a software vendor that supp
That would be real time information involving 'essential' activities.
GDPR would not prevent determining the source of an attack.
GDPR specifically doesn't protect anyone involved in criminal activity
nor contradict any regulatory requirement (which covers cyber attacks).
Mack
-Original Messa
Mellanox commissioned a report along these lines from Tolly in 2016:
https://www.mellanox.com/related-docs/tolly/tolly-report-performance-evaluation-2016-march.pdf
Obviously a grain of salt is needed with any commissioned study - but it
will at least point you to some tests and methodologies that
Hank Nussbacher wrote:
> The entire whois debacle will only get resolved when some hackers attack
> www.eugdpr.org, ec.europa.eu and some other key .eu sites. When the
> response they get will be "sorry, we can't determine who is attacking
> you since that contravenes GDPR", will the EU light bu
Use the package that corresponds to the chipset in your equipment.
Ie. Broadcom/Mellanox chips use that SDK. Intel chips use DPDK.
With white box switches using Broadcom chips you will run into issues
If you don't use the Broadcom SDK. Obviously your mileage will vary
based on the actual applicat
GDPR doesn't play well with directory listing services.
BUT since providing contact information is exactly what a directory listing
service does,
It is safe to assume that this is 'essential' under GDPR.
Ie. Unlike the US, an EU judge would find it silly that you signed up for a
directory listi
If they are hijacking a netblock, it is safe to assume they will also hijack an
ASN.
The best method of dealing with hijacking is still deaggregation and contacting
Upstreams providers from a registered whois address which should be a role
account.
Mack
-Original Message-
From: NANOG [m
19 matches
Mail list logo
