Re: ICANN GDPR lawsuit
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 bulb go on that > something in GDPR needs to be tweaked. You seem to assume that said light bulb does in fact exist. > -Hank --Johnny /\_/\ ( *.* ) > ^ <
RE: Only 5x IPv4 /8 remaining at IANA
"Tony Hain" wrote: > Actually nat does something for security, it decimates it. Any 'real' > security system (physical, technology, ...) includes some form of audit > trail. NAT explicitly breaks any form of audit trail, unless you are the one > operating the header mangling device. Given that there is no limit to the > number of nat devices along a path, there can be no limit to the number of > people operating them. This means there is no audit trail, and therefore NO > SECURITY. So an audit trail implies security? I don't agree. It may make post-mortem analysis easier, thou. Does end-to-end crypto break security? Which security? The security of the endpoints or the security of someone else who cannot now audit the communication in question fully? > Tony --Johnny
Re: US patent 5473599
Jared Mauch wrote: > > Your point being? > > That the "BSD" community sometimes doesn't play well with others, > and certainly won't fess up when they make a mistake and cause > collateral damage. The "BSD" community is larger than OpenBSD, and larger than Theo's ego, much to said persons disappointment. There are other BSDs out there. > - Jared --Johnny
Re: Yup; the Internet is screwed up.
dcroc...@bbiw.net wrote: > While the image of a desiccated user, still typing away, is appealing -- > but possibly not all that remarkable, given recent reports of Internet > addiction -- what's especially tasty is the idea of having an Internet > connection that works without electricity... About as useful as a phone that works without electricity. Oh, thats different, nevermind. > d/ --Johnny
Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....
Owen DeLong wrote: > Take a carrier like Comcast that has ~20,000,000 subscribers. That's > 660,000,000,000 or 660 Terabytes per day of log files. Now, imagine > trying to keep that data set for 7 years worth of data. That's a > 660*365*7 = 1,686,300 Terabyte (or 1.7 Exabyte) storage array. On my side of the Atlantic pond 660,000,000,000 is 660 Gigabytes. --Johnny
Re: Muni fiber: L1 or L2?
Owen DeLong wrote: > Nope The power going into each fiber out of the splitter is 1/16th > that of what went into the splitter. ... which is 12 dB loss. > Yes, your total in-line loss is still 10km, but you are forgetting > about the fact that you lost 15/16th of the power effectively going > to the fiber when you went through the splitter (in addition to the > splitter loss itself). > > So: CO Based splitter: > > Each customer gets (IN - 16dB - (10km x .26db))/32 Each customer gets IN - ~0dB - 12 dB - 2.6 dB = IN - 14.6 dB. > Splitter at 9km: > > Each customer gets (IN - (9km x .26dB) -16db)/32-(1km x .26db) Each customer gets IN - 2.34 dB - 12 dB - 0.26 dB = IN - 14.6 dB. > If we use 5dBm as our input, this works out: > > CO: (5db - 16db - (10km x .26db) / 32 > /32 is effectively -15 db (-3db = ½ power, 32 = 2^5) > Substituting: (5db - 16db - 2.6db) -15db = -28.6db to each customer. > > Spitter at 9km: (5db - (9km x .26db) -16db)/32-(1km x .26db) > Substituting: (5db - 2.34db -16db)-15db-.26db = -28.08db to each customer > > So there is a difference, but it seems rather negligible now that I've > run the numbers. > > However, it's entirely possible that I got this wrong somewhere, > so I invite those more expert than I to review the calculations > and tell me what I got wrong. You are multiplying logarithmic values. > Owen --Johnny
Re: IPv4 address length technical design
valdis.kletni...@vt.edu wrote: > And the -10s and -20s were the major reason RFCs refer to octets > rather than bytes, as they had a rather slippery notion of "byte" > (anywhere from 6 to 9 bits, often multiple sizes used *in the > same program*). Not quite correct. Anywhere from 1 to 36 bits, and not spanning a 36-bit word boundary. Essentialy what is now known as a bit field. --Johnny
Re: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6
Javier Henderson wrote: > > Or XNS. On the other hand, people did have a nice career with > SNA...but they weren't trying to push packets over the > > LAT .daytime Monday 29-Jun-2015 20:10:46 .pjob Job 3 at ODEN User BYGG [10,335] TTY4 .where tty4 LAT PC78(LATD for FreeBSD) TTY4 Is there anyting wrong with LAT? > -jav --Johnny
Re: leap second outage
Mikael Abrahamsson wrote: > This is similar to the jiffycounter wrapping, since this doesn't happen > that often, it's not commonly tested for. Good way is to start the jiffy > counter so it wraps after 10 minutes of uptime. That way you'll run into > any bugs quickly. Either we should abolish the leap second or we should > make leap second adjustments (back and forth) on a monthly basis to > exercise the code. You could do this, move back on even-numbered months and forward on odd. Any real adjustment could be done via inhibiting the monthly change... > This is a hard sell though... 'fraid so. > Mikael Abrahamssonemail: swm...@swm.pp.se --Johnny
Re: What to expect after a cooling failure
Jake Khuon wrote: > While others have already talked about what to look out for in terms of > systems and drives, I haven't seen anyone mention things like your UPS > batteries. Were they also heat-soaked? At one place I worked at, we > lost a whole bank of batteries in the UPS room when it overheated. I > think that was somewhere around a $95,000 replacement and required > rush-delivery of a lot of SLAs from all over the place. That is one reason to have the UPS and the batteries in separate rooms. --Johnny
Re: sort by agony
Marshall Eubanks wrote: > A _really_ intelligent airline scheduling system would (IMHO) be > able to offer you options like > > "there is a direct flight Pittsburgh -> Kansas City, and from there it > is a 2 hour drive to Columbia, so that will save you 5 hours travel time" That's not an airline scheduling system. That's a travel scheduling system. Different beast. > Regards > Marshall --Johnny
Re: an over-the-top data center
> Marshall wrote: > >This is of course off-off-topic, but I would suspect the room > >temperature ultrasonic > >misters, not dry ice or wood smoke. > > > >Regards > >Marshall > > Concur. > > As anyone who works with air conditioning knows, ultrasonic are > the low maintenance option for your humidifier units anyways. > A lot of your datacenters have those 8-) > > There are also doors between the plants and NOC and the server > rooms ... > > Having them external to the AC and pumping visible fog out into > the room instead of invisible into the air feeds is unusual, but > if the resulting humidity (in the NOC, not the server rooms) > is normal it's no big deal. You can have the floor covered in > an inch of water and the air be perfectly safe humidity for > systems (just don't drop a live power cable in the water...). > > I wouldn't do this personally, but if done right it should be safe. This discussion about plants, waterfalls and humidity is getting more and more off-tropic... > -george william herbert > [EMAIL PROTECTED] --Johnny
RE: Private use of non-RFC1918 IP space
"Paul Stewart" wrote: > What reason could you possibly have to use non RFC 1918 space on a > closed network? It's very bad practice - unfortunately I do see it done > sometimes Really really LARGE scalability testing that needs more addresses than RFC1918 gives you. In a closed lab. Yes, it is ugly. Been there. Sometimes ugly can not be avoided. > Paul --Johnny
RE: Private use of non-RFC1918 IP space
Michael Hallgren : > > Really really LARGE scalability testing that needs more addresses than > > RFC1918 gives you. > > Use IPv6. For an IPv4 scalability test? Interesting idea... Apart from the basic incompability here, my opinion of IPv6 is that it just gives you 2^96 more addresses to repeat all the old mistakes with. --Johnny
Re: interger to I P address
> Robert D. Scott wrote:
> > The harder way:
> >
> > Decimal: 1089055123
> > Hex (dashes inserted at octals): 40-E9-A9-93
> > Decimal (of each octet): 64-233-169-147
> > IP Address: 64.233.169.147
>
> The Python way
>
> >>> import socket, struct
> >>> socket.inet_ntoa(struct.pack('>l', 1089055123))
> '64.233.169.147'
The Tops-10/DDT way:
.r ddt
DDT
0! 1089055123.
lsh 4$x
<>
$10r$8o0/ 64.,233.,169.,147.,0. ^Z
.
--Johnny
Re: Email Portability Approved by Knesset Committee
Robert Bonomi wrote: > Quick! Somebody propose a snail-mail portability bill. When a renter > changes to a different landlord, his snail-mail address will be optionally > his to take along, "just like" what is proposed for ISP clients. No, a complete street address portability system. Assuming that I live on 1337 Main Street, I should be able to keep that address even if I move to a different part of town, and I should be able to use it for all purposes, including when I give my home address to a cab driver, and it should just work. Why can't we get some reasonable legislation like that enacted? --Johnny
Re: 0day Windows Network Interception Configuration Vulnerability
Nick Hilliard wrote: > The fix right now is for Microsoft to disable IPv4 by default. Yes, please. That would put a serious dent in most botnets... > Nick --Johnny
