Robustness is desirable from a security perspective. Failure to be liberal in
what you accept and not being prepared to deal with malformed input leads to
such wonders as the Microsoft bug that led to unexpected/malformed IP datagrams
mishandled as "execute payload with system authority". Rat
On Thu, Mar 12, 2015 at 05:33:19PM -0700, Dave Taht wrote:
> Had he lived, email and netnews would have remained usable by mere
> mortals and met the challenge of extreme growth and abuse. And ICANN,
> and for that netsol, wouldn't have become the ugly morass they became.
> Hell, even the IETF migh
it is true that the risk profile has changed in the last 30 years.
his core belief in interconnecting things in an open way, enabling _anyone_ to
create,build, and deploy
is the core of ISOCs “permission less innovation” thrust.
crypto/security folks are green with envy … it is somewhat “sour gr
On Mar 12, 2015, at 20:44 , Larry Sheldon wrote:
> On 3/12/2015 19:20, Jason Iannone wrote:
>> There was once a fairly common saying attributed to an early
>> networking pioneer that went something like, "be generous in what you
>> accept, and send only the stuff that should be sent." Does anyon
On 3/12/2015 19:20, Jason Iannone wrote:
There was once a fairly common saying attributed to an early
networking pioneer that went something like, "be generous in what you
accept, and send only the stuff that should be sent." Does anyone
know what I'm talking about or who said it?
Postel's L
Low hanging fruit.
On Thu, Mar 12, 2015 at 6:29 PM, Miles Fidelman
wrote:
> That was quick. :-)
>
>
> Tom Paseka wrote:
>>
>> Be conservative in what you send, be liberal in what you accept
>>
>> ^http://en.wikipedia.org/wiki/Robustness_principle
>>
>> On Thu, Mar 12, 2015 at 5:20 PM, Jason Ianno
I feel required to point out that Postel's Law was sage advice for its time,
but should now be amended with "but assume that all input is hostile."
On Thu, Mar 12, 2015 at 08:28:22PM -0400, Tim Durack wrote:
> http://en.wikipedia.org/wiki/Jon_Postel
>
> Postel's Law
> Perhaps his most famous lega
On Thu, Mar 12, 2015 at 5:27 PM, Dave Taht wrote:
> jon postel. http://en.wikipedia.org/wiki/Jon_Postel
Had he lived, email and netnews would have remained usable by mere
mortals and met the challenge of extreme growth and abuse. And ICANN,
and for that netsol, wouldn't have become the ugly moras
On 13/03/15 10:20, Jason Iannone wrote:
> There was once a fairly common saying attributed to an early
> networking pioneer that went something like, "be generous in what you
> accept, and send only the stuff that should be sent." Does anyone
> know what I'm talking about or who said it?
>
Jon P
Thanks all.
On Thu, Mar 12, 2015 at 6:28 PM, Tim Durack wrote:
> http://en.wikipedia.org/wiki/Jon_Postel
>
> Postel's Law
> Perhaps his most famous legacy is from RFC 760, which includes a Robustness
> Principle which is often labeled Postel's Law: "an implementation should be
> conservative in i
Jon Postel. I'm told that it is out of favor these days in protocol-land,
from a security standpoint if nothing else.
Mike
On 3/12/15 5:24 PM, Tom Paseka wrote:
Be conservative in what you send, be liberal in what you accept
^http://en.wikipedia.org/wiki/Robustness_principle
On Thu, Mar 12, 2
That was quick. :-)
Tom Paseka wrote:
Be conservative in what you send, be liberal in what you accept
^http://en.wikipedia.org/wiki/Robustness_principle
On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone
wrote:
There was once a fairly common saying attributed to an early
networking pioneer that
http://en.wikipedia.org/wiki/Jon_Postel
Postel's Law
Perhaps his most famous legacy is from RFC 760, which includes a Robustness
Principle which is often labeled Postel's Law: "an implementation should be
conservative in its sending behavior, and liberal in its receiving
behavior" (reworded in RFC
jon postel. http://en.wikipedia.org/wiki/Jon_Postel
On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone wrote:
> There was once a fairly common saying attributed to an early
> networking pioneer that went something like, "be generous in what you
> accept, and send only the stuff that should be sent."
Be conservative in what you send, be liberal in what you accept
^http://en.wikipedia.org/wiki/Robustness_principle
On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone
wrote:
> There was once a fairly common saying attributed to an early
> networking pioneer that went something like, "be generous in
There was once a fairly common saying attributed to an early
networking pioneer that went something like, "be generous in what you
accept, and send only the stuff that should be sent." Does anyone
know what I'm talking about or who said it?
> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes wrote:
>
>
>
> Hello NANOGers,
>
> The NANOG BCOP committee is currently considering strategies on how to best
> create a numbering scheme for the BCOP appeals. As we all know, most public
> technical references (IETF, etc) have numbers to c
> Date: Thu, 12 Mar 2015 15:48:31 -0400
> From: lo...@pari.edu
> To: nanog@nanog.org
> Subject: Unlawful transfers of content and transfers of unlawful content
> (was:Re: Verizon Policy Statement on Net Neutrality)
>
> On 02/27/2015 02:14 PM, Jim Richardson wrote:
> > What's a "lawful" web site?
Hey all,
Sorry for the x-post with j-nsp, but I'm looking for something that seems
to be a bit hard to find and I'm hoping that someone in the larger
community might be able to help.
I'm trying to find a totally broken, cheap, MX5/80 and a Cisco 2921 chassis
that I can use for demonstration train
On 03/12/2015 02:02 PM, Rob McEwen wrote:
Nevertheless, in such a circumstance, 47 USC 230(c)(2) should prevail
and trump any such interpretation of this!
(If anyone thinks that 47 USC 230(c)(2) might not prevail over such an
interpretation, please let me know... and let me know why?)
Found
On 03/12/2015 04:58 PM, Donald Kasper wrote:
More then website blocking I've been wondering what this means for
spam prevention?
That's a pretty interesting thought, and it is pretty well addressed by
paragraphs 376, 377, and 378. Basically, the FCC found that spam
blocking is a separate
Those IPs appear to be used by to Google cache servers at the QIX. It's
common for CDNs to utilize provider space and not maintain their own
layer-3. E.g. cache servers connected to switch, connected to provider,
without the requirement of a router.
/Steve
On Thu, Mar 12, 2015 at 3:58 PM, Jaso
^ my thought, they're on the QIX public block
On Thu, Mar 12, 2015 at 1:00 PM, Stephen Fulton
wrote:
> Local Google caches at QIX?
>
> -- Stephen
>
>
> On 2015-03-12 3:58 PM, Jason Lixfeld wrote:
>
>> So today, I saw this:
>>
>> BlackBox:~ jlixfeld$ host google.ca 8.8.8.8
>> Using domain server:
Look for GGC.
--
Eduardo Schoedler
2015-03-12 16:58 GMT-03:00 Jason Lixfeld :
> So today, I saw this:
>
> BlackBox:~ jlixfeld$ host google.ca 8.8.8.8
> Using domain server:
> Name: 8.8.8.8
> Address: 8.8.8.8#53
> Aliases:
>
> google.ca has address 206.126.112.166
> google.ca has address 206.126
Local Google caches at QIX?
-- Stephen
On 2015-03-12 3:58 PM, Jason Lixfeld wrote:
So today, I saw this:
BlackBox:~ jlixfeld$ host google.ca 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
google.ca has address 206.126.112.166
google.ca has address 206.126.112.177
goog
So today, I saw this:
BlackBox:~ jlixfeld$ host google.ca 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
google.ca has address 206.126.112.166
google.ca has address 206.126.112.177
google.ca has address 206.126.112.172
google.ca has address 206.126.112.187
google.ca has a
On 02/27/2015 02:14 PM, Jim Richardson wrote:
What's a "lawful" web site?
Paragraphs 304 and 305 in today's released R&O address some of this.
The wording 'Unlawful transfers of content and transfers of unlawful
content' is pretty good, and covers what the Commission wanted to cover.
On 03/12/2015 02:02 PM, Rob McEwen wrote:
On 3/12/2015 1:30 PM, William Kenny wrote:
NO BLOCKING:
A person engaged in the provision of broadband Internet access service,
insofar as such person is so engaged, shall not block lawful content,
applications, services, or nonharmful devices, subject t
I regularly had this many years ago with the old Foundry Big Irons, the
Route table on the processor would have the correct information but an
individual forwarding table on a line card would be out of sync causing
randomly occurring route loops. They never did fix it and that was the last
time I u
Totally. Also, then what if something is in the intersection of multiple
"areas".
Complexity that's not needed.
Tony
On Thu, Mar 12, 2015 at 3:12 PM, Job Snijders wrote:
> On Mar 12, 2015 8:08 PM, "joel jaeggli" wrote:
> >
> > On 3/12/15 12:01 PM, Yardiel D. Fuentes wrote:
> > > In the above
This may have less of an impact than you think on your network (though it
certainly will change your terms of service).
-Original Message-
From: NANOG [mailto:nanog-bounces+dah=franczek@nanog.org] On Behalf Of Mike
A
Sent: Thursday, March 12, 2015 1:50 PM
To: North American Network O
On Mar 12, 2015 8:08 PM, "joel jaeggli" wrote:
>
> On 3/12/15 12:01 PM, Yardiel D. Fuentes wrote:
> > In the above page, the idea is to introduce a 100-th range for each
category and as the BCOPs. This way a 100th number range generally
identifies each of the categories we currently have. An examp
On 03/12/2015 01:28 PM, Lamar Owen wrote:
On 03/12/2015 12:13 PM, Bryan Tong wrote:
I read through the introduction. This document seems like a good
thing for everyone.
I'm about 50 pages in, reading a little bit at a time. Paragraph 31
is one that anyone who does peering or exchanges shoul
On 3/12/15 12:01 PM, Yardiel D. Fuentes wrote:
>
>
> Hello NANOGers,
>
> The NANOG BCOP committee is currently considering strategies on how to best
> create a numbering scheme for the BCOP appeals. As we all know, most public
> technical references (IETF, etc) have numbers to clarify referen
Hello NANOGers,
The NANOG BCOP committee is currently considering strategies on how to best
create a numbering scheme for the BCOP appeals. As we all know, most public
technical references (IETF, etc) have numbers to clarify references. The goal
is for NANOG BCOPs to follow some sort of same
On Thu, Mar 12, 2015 at 12:30:16PM -0500, William Kenny wrote:
> Page 7 -14 looks to be pretty important. Specifcially:
>
> NO BLOCKING:
> A person engaged in the provision of broadband Internet access service,
> insofar as such person is so engaged, shall not block lawful content,
> applications,
On 3/12/2015 1:30 PM, William Kenny wrote:
NO BLOCKING:
A person engaged in the provision of broadband Internet access service,
insofar as such person is so engaged, shall not block lawful content,
applications, services, or nonharmful devices, subject to reasonable
network management.
The docu
Page 7 -14 looks to be pretty important. Specifcially:
NO BLOCKING:
A person engaged in the provision of broadband Internet access service,
insofar as such person is so engaged, shall not block lawful content,
applications, services, or nonharmful devices, subject to reasonable
network management.
I have been troubleshooting an issue with Brocade TAC in regards to our Brocade
CES that we use for some static routing. The Firmware has been upgraded and
hardware has been replaced and still the problem is occurring. I have talked
to some other carriers I work with that have previously used
Note: IANAL and this is my *personal* reading (in no way the view of my
employer). I¹m only 7 pages in as well, so this is likely under-informed
and in another 300+ pages I will become more enlightened...
Part A.16. No Throttling. "...A person engaged in the provision of
broadband Internet access
On 03/12/2015 12:13 PM, Bryan Tong wrote:
I read through the introduction. This document seems like a good thing
for everyone.
I'm about 50 pages in, reading a little bit at a time. Paragraph 31 is
one that anyone who does peering or exchanges should read and
understand. I take it to mean
I read through the introduction. This document seems like a good thing for
everyone.
If someone finds something opposing to that I would be interested to know.
I definitely didnt make it through the whole thing either :)
On Thu, Mar 12, 2015 at 9:48 AM, Lamar Owen wrote:
> On 03/12/2015 10:58 A
On 03/12/2015 10:58 AM, Ca By wrote:
For the first time to the public
http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0312/FCC-15-24A1.pdf
The actual final rules are in Appendix A, pages 283 through 290 (8
pages), although that's a bit misleading, as the existing Part 8 is not
On Mar 12, 2015 11:01 AM, "Ca By" wrote:
>
> For the first time to the public
>
http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0312/FCC-15-24A1.pdf
>
> Enjoy.
Uh yeah, I'll wait for the reviews when y'all get done trudging through
that...
For the first time to the public
http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0312/FCC-15-24A1.pdf
Enjoy.
Quick hijack: Can anyone recommend a device that will terminate to a
phone, supports SIP, *and* can fallback to SIM for emergency calls?
On Tue, Mar 10, 2015 at 8:44 AM, Pedersen, Sean wrote:
> +1
>
> Used them in a past life as a SIP ALG and NAT router for a “bring your own
> broadband” hosted
On 11/Mar/15 21:18, Jared Mauch wrote:
Similarly send-community on IOS requires beyond the basic “neighbor 1.2.3.4
remote-as 5” type config.
One has the same issue in IOS XR, where BGP communities are only
signaled by default for iBGP neighbors. One needs to enable signaling of
communitie
47 matches
Mail list logo
