Re: Phone adapter with router
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 speder...@io.com wrote: +1 Used them in a past life as a SIP ALG and NAT router for a “bring your own broadband” hosted SIP service. Worked well enough. You might get more suggestions if you provide a little bit more about what your requirements are, how they’re being deployed (one-off, ISP, etc.), or what the others didn’t do well. On 3/9/15, 11:16 PM, Joe Hamelin j...@nethead.com wrote: I've run into a few of these and they seem to do a good job. ftp://ftp.edgewaternetworks.com/pub/docs/CD_contents/DOCS/EdgeMarc/200/200%20Series%20Datasheet.pdf -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Mon, Mar 9, 2015 at 4:07 PM, A MEKKAOUI amekka...@mektel.ca wrote: Hi Do you know any good router with phone adapters to provide home phone and internet? We tried couple of them like Linksys, Thomson, etc. and no one does the job perfectly. Any comment will be appreciated. Thank you Karim Founded in 2007, IO provides the data center as a service to businesses and governments around the world. The communication contained in this e-mail is confidential and is intended only for the named recipient(s) and may contain information that is privileged, proprietary, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Please immediately notify the sender of the error, and delete this communication including any attached files from your system. Thank you for your cooperation.
Re: distinguishing eBGP from show ip BGP
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 communities to eBGP neighbors. Junos does the right thing :-). Mark.
FCC releases Open Internet document
For the first time to the public http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0312/FCC-15-24A1.pdf Enjoy.
RE: Searching for a quote
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. Rather than sloppiness you could also attribute the error to malice -- that it was injected at the specific request of certain government agencies, perhaps under threat, perhaps with just a wink and a nod ... --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Michael Thomas Sent: Thursday, 12 March, 2015 18:32 To: nanog@nanog.org Subject: Re: Searching for a quote 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, 2015 at 5:20 PM, Jason Iannone jason.iann...@gmail.com 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?
Re: Searching for a quote
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 might have remained viable. Indeed. That sentiment, and his memory, deserve a toast of MacAllan 18-year. And they shall have it momentarily. ---rsk
Re: FCC releases Open Internet document
On Mar 12, 2015 11:01 AM, Ca By cb.li...@gmail.com 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...
Brocade CES Routing Table Issue
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 Brocade gear and switched because of odd issues that could not be resolved. Curious if anyone on this list has had other odd Layer 3 issues with Brocade/Foundry Networks gear? My issue seems to be somehow related to the table in memory that the ARP and next-hop entries are stored in, entries will point to the wrong mac address or the wrong port for the next-hop, it happens about every 60 days like clockwork. Jordan Hamilton Telecommunications Engineer Empire District Electric Co. 720 Schifferdecker PO Box 127 Joplin, MO 64802 Ph: 417-625-4223 Cell: 417-388-3351 -- Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments. Check your e-mail security settings to determine how attachments are handled. -- This e-mail and any files transmitted with it are the property of THE EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this message in error, please delete this message immediately from your computer and contact the sender by telephone at (417)-625-5100. Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited.
Re: FCC releases Open Internet document
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 something like 'Guys who abuse peering and engage in peering disputes, take note of what we just did to the last mile people; you have been warned.' But, having read Commission RO's before on the broadcast (Media Bureau) side of the house for years, maybe I'm a bit cynical. Paragraphs 37 through 40, including footnotes, appear tailored as a reply to Verizon's creative Morse reply. It's impossible to know which was first, but it is an interesting thought. The 'Verizon Court' is mentioned numerous times. Paragraph43 and footnote 40 mention the 'Brand X' decision of the Supreme Court, mentioning that that decision left open the reclassification avenue. This could cause any legislation that attempted to thwart this RO to eventually be ruled unconstitutional, citing Brand X. Prior to reading this RO I wasn't familiar with this decision, so I've already learned something new.and I think the reference in paragraph 43, footnote 41, is rather interesting as well. And Justice Scalia's pizza delivery analogy makes a humorous (in the political context!) appearance. Delightful. Paragraphs 60 through 74 give a concise history of the action, and are a great read. And it also shows me that I should have paid a bit closer attention to the Part 8 I read a few days back; that's the part 8 from the RO of 2010; the part 8 as of today in the eCFR has not been updated with the new sections, including 8.18. So the rules as set into place by this RO were not public earlier; I stand corrected. Paragraphs 78 through 85 and associated footnotes (I found footnote 131 particularly relevant) state in a nutshell why the FCC thought that this action had to be taken. And I am just in awe of the first sentence of paragraph 92. And paragraph 99 is spot-on on wireless carrier switching costs. One of the more interesting side effects of this is that it would appear that a mass-market BIAS (the FCC's term, not mine, for Broadband Internet Access Service) provider cannot block outbound port 25 (RO paragraph 105 and footnote 241 in particular). Well, it does depend upon what Paragraph 113 means about a device that 'does not harm the network.' Whether you agree with the RO or not, I believe that you will find it a very readable document. Some will no doubt strongly disagree.
Re: FCC releases Open Internet document
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 service, insofar as such person is so engaged, shall not impair or degrade lawful Internet traffic on the basis of Internet content,application, or service, or use of a non-harmful device, subject to reasonable network management. They then say in A.17 (which is not the rule I don¹t think but still probably carries weight in some way) ...It prohibits the degrading of Internet traffic based on source, destination, or content. Unfortunately the rule itself only seems to speak to content, not source or destination. Did someone miss adding that to the rule? - Jason
Re: FCC releases Open Internet document
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. NO THROTTLING: A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not impair or degrade lawful Internet traffic on the basis of Internet content, application, or service, or use of a non-harmful device, subject to reasonable network management. NO PAID PRIORITIZATION: A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not engage in paid prioritization. There is also an interesting bit on gatekeeping: Any person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not unreasonably interfere with or unreasonably disadvantage (i) end users’ ability to select, access, and use broadband Internet access service or the lawful Internet content, applications, services, or devices of their choice, or (ii) edge providers’ ability to make lawful content, applications, services, or devices available to end users. Reasonable network management shall not be considered a violation of this rule. I think there are going to be a lot of complex implications of this announcement (canidate for most obvious statement aware winner!). On Thu, Mar 12, 2015 at 10:32 AM, shawn wilson ag4ve...@gmail.com wrote: On Mar 12, 2015 11:01 AM, Ca By cb.li...@gmail.com 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...
Re: Unlawful transfers of content and transfers of unlawful content
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 add-on information service. It may be that the consumer now must opt-in to that service after clear disclosure of what the service entails. The FCC even found that DNS is not an information service (paragraphs 366-371), and the argument is compelling. This Commission is not technically illiterate, that's for sure, whether you agree with the RO or not.
Re: FCC releases Open Internet document
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 it; paragraph 532 addresses 230(c). In a nutshell, the applicability does not change due to the reclassification of BIAS providers as telecommunications services.
Re: FCC releases Open Internet document
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 included in full in that Appendix.There are also three amendments to Part 20, as well, in the Definitions, which means other paragraphs of Part 20 may apply. It's interesting that pages 321 through 400 (80 pages) are taken up entirely by the dissenting Commissioner's statements, and Tom Wheeler's statement begins on page 314. This will indeed be an interesting read.
Google served from non-google IPs?
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 address 206.126.112.151 google.ca has address 206.126.112.158 google.ca has address 206.126.112.157 google.ca has address 206.126.112.173 google.ca has address 206.126.112.181 google.ca has address 206.126.112.155 google.ca has address 206.126.112.147 google.ca has address 206.126.112.185 google.ca has address 206.126.112.143 google.ca has address 206.126.112.170 google.ca has address 206.126.112.162 google.ca has IPv6 address 2607:f8b0:4006:808::100f google.ca mail is handled by 50 alt4.aspmx.l.google.com. google.ca mail is handled by 30 alt2.aspmx.l.google.com. google.ca mail is handled by 20 alt1.aspmx.l.google.com. google.ca mail is handled by 10 aspmx.l.google.com. google.ca mail is handled by 40 alt3.aspmx.l.google.com. BlackBox:~ jlixfeld$ That is not Google IPv4 address space, and those IPv4 IPs are not being announced by 15169. Am I dumb in thinking that this is weird or is this sort of thing commonplace?
Re: Google served from non-google IPs?
Look for GGC. -- Eduardo Schoedler 2015-03-12 16:58 GMT-03:00 Jason Lixfeld ja...@lixfeld.ca: 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 address 206.126.112.151 google.ca has address 206.126.112.158 google.ca has address 206.126.112.157 google.ca has address 206.126.112.173 google.ca has address 206.126.112.181 google.ca has address 206.126.112.155 google.ca has address 206.126.112.147 google.ca has address 206.126.112.185 google.ca has address 206.126.112.143 google.ca has address 206.126.112.170 google.ca has address 206.126.112.162 google.ca has IPv6 address 2607:f8b0:4006:808::100f google.ca mail is handled by 50 alt4.aspmx.l.google.com. google.ca mail is handled by 30 alt2.aspmx.l.google.com. google.ca mail is handled by 20 alt1.aspmx.l.google.com. google.ca mail is handled by 10 aspmx.l.google.com. google.ca mail is handled by 40 alt3.aspmx.l.google.com. BlackBox:~ jlixfeld$ That is not Google IPv4 address space, and those IPv4 IPs are not being announced by 15169. Am I dumb in thinking that this is weird or is this sort of thing commonplace? -- Eduardo Schoedler
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? Paragraphs 304 and 305 in today's released RO 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.
Re: Google served from non-google IPs?
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 google.ca has address 206.126.112.172 google.ca has address 206.126.112.187 google.ca has address 206.126.112.151 google.ca has address 206.126.112.158 google.ca has address 206.126.112.157 google.ca has address 206.126.112.173 google.ca has address 206.126.112.181 google.ca has address 206.126.112.155 google.ca has address 206.126.112.147 google.ca has address 206.126.112.185 google.ca has address 206.126.112.143 google.ca has address 206.126.112.170 google.ca has address 206.126.112.162 google.ca has IPv6 address 2607:f8b0:4006:808::100f google.ca mail is handled by 50 alt4.aspmx.l.google.com. google.ca mail is handled by 30 alt2.aspmx.l.google.com. google.ca mail is handled by 20 alt1.aspmx.l.google.com. google.ca mail is handled by 10 aspmx.l.google.com. google.ca mail is handled by 40 alt3.aspmx.l.google.com. BlackBox:~ jlixfeld$ That is not Google IPv4 address space, and those IPv4 IPs are not being announced by 15169. Am I dumb in thinking that this is weird or is this sort of thing commonplace?
Re: Google served from non-google IPs?
^ my thought, they're on the QIX public block On Thu, Mar 12, 2015 at 1:00 PM, Stephen Fulton s...@lists.esoteric.ca 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: 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 address 206.126.112.151 google.ca has address 206.126.112.158 google.ca has address 206.126.112.157 google.ca has address 206.126.112.173 google.ca has address 206.126.112.181 google.ca has address 206.126.112.155 google.ca has address 206.126.112.147 google.ca has address 206.126.112.185 google.ca has address 206.126.112.143 google.ca has address 206.126.112.170 google.ca has address 206.126.112.162 google.ca has IPv6 address 2607:f8b0:4006:808::100f google.ca mail is handled by 50 alt4.aspmx.l.google.com. google.ca mail is handled by 30 alt2.aspmx.l.google.com. google.ca mail is handled by 20 alt1.aspmx.l.google.com. google.ca mail is handled by 10 aspmx.l.google.com. google.ca mail is handled by 40 alt3.aspmx.l.google.com. BlackBox:~ jlixfeld$ That is not Google IPv4 address space, and those IPv4 IPs are not being announced by 15169. Am I dumb in thinking that this is weird or is this sort of thing commonplace? -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: Google served from non-google IPs?
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, Jason Lixfeld ja...@lixfeld.ca 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 google.ca has address 206.126.112.172 google.ca has address 206.126.112.187 google.ca has address 206.126.112.151 google.ca has address 206.126.112.158 google.ca has address 206.126.112.157 google.ca has address 206.126.112.173 google.ca has address 206.126.112.181 google.ca has address 206.126.112.155 google.ca has address 206.126.112.147 google.ca has address 206.126.112.185 google.ca has address 206.126.112.143 google.ca has address 206.126.112.170 google.ca has address 206.126.112.162 google.ca has IPv6 address 2607:f8b0:4006:808::100f google.ca mail is handled by 50 alt4.aspmx.l.google.com. google.ca mail is handled by 30 alt2.aspmx.l.google.com. google.ca mail is handled by 20 alt1.aspmx.l.google.com. google.ca mail is handled by 10 aspmx.l.google.com. google.ca mail is handled by 40 alt3.aspmx.l.google.com. BlackBox:~ jlixfeld$ That is not Google IPv4 address space, and those IPv4 IPs are not being announced by 15169. Am I dumb in thinking that this is weird or is this sort of thing commonplace? -- Steven J. Schecter (m) 917.676.1646
Re: FCC releases Open Internet document
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 should read and understand. I take it to mean something like 'Guys who abuse peering and engage in peering disputes, take note of what we just did to the last mile people; you have been warned.' But, having read Commission RO's before on the broadcast (Media Bureau) side of the house for years, maybe I'm a bit cynical. Another 40 pages, and found the detailed paragraphs related to this introductory paragraph. Those here who know how peering works in the real world, read paragraphs 194 through 206 of this RO, including footnotes, and see if the FCC 'gets it' when it comes to how peering works.
RE: Brocade CES Routing Table Issue
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 used them with full internet route tables. This being said I saw similar issues (that were resolved) on Unisphere (now Juniper) and Extreme kit. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jordan Hamilton Sent: Friday, 13 March 2015 2:48 a.m. To: nanog@nanog.org Subject: Brocade CES Routing Table Issue 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 Brocade gear and switched because of odd issues that could not be resolved. Curious if anyone on this list has had other odd Layer 3 issues with Brocade/Foundry Networks gear? My issue seems to be somehow related to the table in memory that the ARP and next-hop entries are stored in, entries will point to the wrong mac address or the wrong port for the next-hop, it happens about every 60 days like clockwork.
Re: FCC releases Open Internet document
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 document (if I read it correctly) states that reasonable network management includes spam filtering (yeah!) However, in spite of that... it seems to give the MISTAKEN impression that: (1) ALL spam is ALWAYS... NOT-lawful content (2) ALL lawful content is NEVER spam. (again, I'm not saying the document says this directly... only that it seems to give that impression at times!) But, in fact, there is actually MUCH spam that is 100% legal, but also 100% unsolicited/undesired and therefore frequently blocked by spam filters, and rightly so. I just hope that nobody argues in a court of law that their exceptions for spam filtering only applies to UNLAWFUL spam!!! THAT would be a DISASTER!!! 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?) -- Rob McEwen
Re: FCC releases Open Internet document
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, services, or nonharmful devices, subject to reasonable network management. NO THROTTLING: A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not impair or degrade lawful Internet traffic on the basis of Internet content, application, or service, or use of a non-harmful device, subject to reasonable network management. NO PAID PRIORITIZATION: A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not engage in paid prioritization. There is also an interesting bit on gatekeeping: Any person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not unreasonably interfere with or unreasonably disadvantage (i) end users’ ability to select, access, and use broadband Internet access service or the lawful Internet content, applications, services, or devices of their choice, or (ii) edge providers’ ability to make lawful content, applications, services, or devices available to end users. Reasonable network management shall not be considered a violation of this rule. I think there are going to be a lot of complex implications of this announcement (canidate for most obvious statement aware winner!). On Thu, Mar 12, 2015 at 10:32 AM, shawn wilson ag4ve...@gmail.com wrote: On Mar 12, 2015 11:01 AM, Ca By cb.li...@gmail.com 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... This will be interesting, in the context of cable providers providing inbound access to subscriber-address server ports only for commercial accounts. -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
BCOP appeals numbering scheme -- feedback requested
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 style. The BCOP committee is looking for feedback and comments on this topic. Currently, the below numbering scheme is being considered: A proposed numbering scheme can be based on how the appeals appeals in the BCOP topics are presented as shown below: http://bcop.nanog.org/index.php/Appeals 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 example is: BCP Range Area of Practice 100 - 199 EBGPs 200 - 299 IGPs 300 - 399 Ethernet 400 - 499 Class of Service 500 - 599 Network Information Processing 600 - 699 Security 700 - 799 MPLS 800 - 899 Generalized An arguable objection could be that the range is limited...but a counter-argument is that considering more than 100 BCOPs would be either a great success or just a sign of failure for the NANOG community ... Comments or Thoughts ? Yardiel Fuentes
Re: BCOP appeals numbering scheme -- feedback requested
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 references. The goal is for NANOG BCOPs to follow some sort of same style. The BCOP committee is looking for feedback and comments on this topic. Currently, the below numbering scheme is being considered: A proposed numbering scheme can be based on how the appeals appeals in the BCOP topics are presented as shown below: http://bcop.nanog.org/index.php/Appeals 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 example is: identifier/locator overload. giving intergers intrinsic meaning is generally a mistake imho. BCP Range Area of Practice 100 - 199 EBGPs 200 - 299 IGPs 300 - 399 Ethernet 400 - 499 Class of Service 500 - 599 Network Information Processing 600 - 699 Security 700 - 799 MPLS 800 - 899 Generalized An arguable objection could be that the range is limited...but a counter-argument is that considering more than 100 BCOPs would be either a great success or just a sign of failure for the NANOG community ... Comments or Thoughts ? Yardiel Fuentes signature.asc Description: OpenPGP digital signature
Re: BCOP appeals numbering scheme -- feedback requested
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 j...@instituut.net wrote: On Mar 12, 2015 8:08 PM, joel jaeggli joe...@bogus.com 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 example is: identifier/locator overload. giving intergers intrinsic meaning is generally a mistake imho. I agree with Joel
Re: FCC releases Open Internet document
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 to reasonable network management. The document (if I read it correctly) states that reasonable network management includes spam filtering (yeah!) However, in spite of that... it seems to give the MISTAKEN impression that: (1) ALL spam is ALWAYS... NOT-lawful content (2) ALL lawful content is NEVER spam. I think the issue is adequately addressed by the RO's paragraph 222 and its neighbors, with footnotes 571, 572, and 573 elucidating. The short version: the FCC is not going to rigidly define this and leave it up to the providers, but they will address it on a case-by-case basis if need be. At least that was my takeaway. 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?) It would seem, but I am not a lawyer, that perhaps it would. It's not directly addressed in the portions of the RO that I've read thus far, and that specific paragraph is not cited that I could find. A Good Samaritan law, in 47 USC. fun stuff.
Searching for a quote
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?
Re: Searching for a quote
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 jason.iann...@gmail.com 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?
Re: Searching for a quote
jon postel. http://en.wikipedia.org/wiki/Jon_Postel On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone jason.iann...@gmail.com 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? -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
Re: Searching for a quote
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 1122 as Be liberal in what you accept, and conservative in what you send). On Thu, Mar 12, 2015 at 8:20 PM, Jason Iannone jason.iann...@gmail.com 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? -- Tim:
Re: Searching for a quote
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 jason.iann...@gmail.com 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? -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: Searching for a quote
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, 2015 at 5:20 PM, Jason Iannone jason.iann...@gmail.com 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?
Re: Searching for a quote
Thanks all. On Thu, Mar 12, 2015 at 6:28 PM, Tim Durack tdur...@gmail.com 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 its sending behavior, and liberal in its receiving behavior (reworded in RFC 1122 as Be liberal in what you accept, and conservative in what you send). On Thu, Mar 12, 2015 at 8:20 PM, Jason Iannone jason.iann...@gmail.com 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? -- Tim:
Re: Searching for a quote
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 Postel's Robustness Principal. http://en.wikipedia.org/wiki/Jon_Postel
Re: Searching for a quote
On Thu, Mar 12, 2015 at 5:27 PM, Dave Taht dave.t...@gmail.com 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 morass they became. Hell, even the IETF might have remained viable. I have few heroes. He was one of them. On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone jason.iann...@gmail.com 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? -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
Re: Searching for a quote
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 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 1122 as Be liberal in what you accept, and conservative in what you send).
Re: Searching for a quote
Low hanging fruit. On Thu, Mar 12, 2015 at 6:29 PM, Miles Fidelman mfidel...@meetinghouse.net 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 Iannone jason.iann...@gmail.com 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? -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: Searching for a quote
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 Law: Be generous in what you accept; strict in what you send.* *From aging memory, but I think that is close. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Broken/trashed/junk Juniper MX5/80 and Cisco 2921 chassis?
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 trainings with our edge technicians. We're currently running the demos with spare gear, but even though we transport this gear in shock-mounted cases, I'd much rather be transporting dummy equipment. Our SEs don't have a line on this kind of gear either. Aparently this type of gear is destroyed or refurbished, but there isn't much demand for broken equipment sitting around staying broken. If you have a line on some of this gear that you'd be willing to share, I'd appreciate it. Thanks, Dan
RE: Unlawful transfers of content and transfers of unlawful content (was:Re: Verizon Policy Statement on Net Neutrality)
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? Paragraphs 304 and 305 in today's released RO 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. More then website blocking I've been wondering what this means for spam prevention?
Re: BCOP appeals numbering scheme -- feedback requested
On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes yard...@gmail.com 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 references. The goal is for NANOG BCOPs to follow some sort of same style. The BCOP committee is looking for feedback and comments on this topic. Currently, the below numbering scheme is being considered: A proposed numbering scheme can be based on how the appeals appeals in the BCOP topics are presented as shown below: http://bcop.nanog.org/index.php/Appeals 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 example is: BCP Range Area of Practice 100 - 199 EBGPs 200 - 299 IGPs 300 - 399 Ethernet 400 - 499 Class of Service 500 - 599 Network Information Processing 600 - 699 Security 700 - 799 MPLS 800 - 899 Generalized An arguable objection could be that the range is limited...but a counter-argument is that considering more than 100 BCOPs would be either a great success or just a sign of failure for the NANOG community ... Comments or Thoughts ? The problem with any such numbering scheme is how you handle the situation when you exhaust the avaialble number space. What happens with the 101st EBGP BCOP, for example? I also agree with Joel’s comment about identifier/locator overload. Have we learned nothing from the issues created by doing this in IPv4 and IPv6? Instead, how about maintaining a BCOP subject index which contains titular and numeric information for each BCOP applicable to the subjects above. e.g.: BCOP Subject Index: Subjects: 1. EBGP 2. IGP 3. Ethernet 4. Class of Service 5. Network Information Processing 6. Security 7. MPLS 8. Generalized 1. EBGP 104 lorem ipsum 423 ipsum lorem Then, just like the RFCs, maintain the BCOP appeal numbering as a sequential monotonically increasing number and make the BCOP editor responsible for updating the index with the publishing of each new or revised BCOP. Note, IMHO, a revised BCOP should get a new number and the previous revision should be marked “obsoleted by X” and it’s document status should reflect “Obsoletes , , and ” for all previous revisions. The index should probably reflect only BCOPs which have not been obsoleted. Just my $0.02. Owen
Re: Searching for a quote
On Mar 12, 2015, at 20:44 , Larry Sheldon larryshel...@cox.net 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 anyone know what I'm talking about or who said it? Postel's Law: Be generous in what you accept; strict in what you send.* *From aging memory, but I think that is close. https://en.wikipedia.org/wiki/Robustness_principle Be conservative in what you do, be liberal in what you accept from others (often reworded as Be conservative in what you send, be liberal in what you accept). -- TTFN, patrick
Re: Searching for a quote
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 grapes” no? I count my time working for him as one of the highlights of my life. In some respects, I still do… :) /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 12March2015Thursday, at 17:31, Michael Thomas m...@mtcc.com wrote: 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, 2015 at 5:20 PM, Jason Iannone jason.iann...@gmail.com 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?
