scott via NANOG writes:
> What if someone originates a /15? That's one of the prefix sizes we
> originate. They need a 'less than or equal to' thingie in there.
I've asked the maintainer of this service (whom I recently met and who
might not be on NANOG) to clarify this.
Michael Thomas writes:
> I wonder if the right thing to do is to create a standards track RFC that
> makes the experimental space officially an add on to rfc 1918. If it works
> for you, great, if not your problem. It would at least stop all of these
> recurring arguments that we could salvage it
Matthew Petach writes:
> I would go a step further; for any system of compression hoping to gain a
> net positive space savings,
> Godel's incompleteness theorem guarantees that there is at least one input
> to the system that will result in no space savings whatsoever.
This is rather the
Jan Schaumann via NANOG writes:
> Mark Stevens wrote:
> > Is anyone else getting the following error when trying to access any of
> > google's services?
> > SSL_ERROR_RX_RECORD_TOO_LONG
>
> Isn't this usually a sign of a protocol mismatch?
> I.e., TLS 1.3 vs TLS 1.2.
The most common protocol
Owen DeLong via NANOG writes:
> Just because there is a small code snippet you found that prevents casting
> 240/4 as unicast on an interface doesn’t mean that removing that code will
> magically make 240/4 usable in the entire stack.
>
> [...]
>
> The code you found may just be a safety
John R. Levine writes:
> This still doesn't mean that screwing around with 240/4 or, an even worse
> 127/8 minus 127/24, is a good idea.
I hope you'll be slightly mollified to learn that it's actually 127/8
minus 127/16.
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-127/
That's
John Levine writes:
> FWIW, I also don't think that repurposing 240/4 is a good idea.
As people will be aware, we have a different draft on this issue, so
I'm also going to pipe up here.
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
(Our draft offers no specific plan for
I also imagine (without data) that most DoS attacks continue to be
performed by botnets, using other people's connections, rather than
directly by their ultimate perpetrators. So, the most effective and
meaningful mitigation would be trying to clean up bots, and prevent
ongoing bot infections,
Matthew Crocker writes:
> I have many customers that have registered their domains against my
> authoritative servers (DNS-AUTH3.CROCKER.COM).I need to move that machine
> to a different network/IP address.I’ve made the updates in my domain
> (crocker.com) but I think I also need to
pdates and (eventually)
https://community.letsencrypt.org/c/incidents
for a postmortem.
--
Seth David Schoen | Qué empresa fácil no pensar
http://www.loyalty.org/~schoen/| en un tigre, reflexioné.
8F08B027A5DB06ECF993B4660FD4F0CD2B11D2F9 |-- Borges, "El Zahir"
/legacy/events/sec05/tech/full_papers/chow/chow.pdf
This is for the RAM case rather than the disk case; maybe disk is worse
because writes are more expensive.
--
Seth David Schoen sch...@loyalty.org | No haiku patents
http://www.loyalty.org/~schoen/| means I've no incentive
Jay Ashworth writes:
This just in from Lauren Weinstein. This is, of course, today.
Have people actually deployed changes to support this?
Six Strikes is not a law; it's a private agreement.
http://www.scribd.com/doc/91987640/CCI-MOU
--
Seth David Schoen sch...@loyalty.org
://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state_static.json?view=markup
--
Seth David Schoen sch...@loyalty.org | No haiku patents
http://www.loyalty.org/~schoen/| means I've no incentive to
FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150
/topic.html#Traffic_20analysis
This bibliography is updated periodically. It's a pretty big, complex
topic, and the open literature could use lots more publications.
--
Seth David Schoen sch...@loyalty.org | Qué empresa fácil no pensar en
http://www.loyalty.org/~schoen/ | un tigre, reflexioné
14 matches
Mail list logo
