Re: Log4j mitigation

> On Dec 14, 2021, at 14:43 , Nick Hilliard wrote: > > The log4j people have updated their security advisory to say that these two > mitigation measures are not sufficient to protect against the recent > vulnerability: > >> 2. start java with "-D log4j2.formatMsgNoLookups=true" (v2.10+ only

Re: Telia is now Arelion

I think it’s more in the hopes that previously irritated customers might not realize they’re once again dealing with the same schmucks that pissed them off years back. It helps keep then incoming churn of new customers to replace the churn from other customers rage quitting. Owen > On Jan 1

Re: New minimum speed for US broadband connections

> On Jun 2, 2021, at 02:10 , Mark Tinka wrote: > > > > On 6/2/21 11:04, Owen DeLong wrote: > >> I disagree… If it could be forced into a standardized format using a >> standardized approach to data acquisition and reliable comparable results >> across providers, it could be a very useful

Re: New minimum speed for US broadband connections

e as > you asked for. > > On Thu, Feb 10, 2022 at 3:57 PM Josh Luthman <mailto:j...@imaginenetworksllc.com>> wrote: > >There are plenty of urban and suburban areas in America that are far worse > >off from a broadband perspective than “rural America”. > >

Re: New minimum speed for US broadband connections

ls. > > This is not to say that rural America is a mecca of connectivity; there is a > long way to go all the way around regardless. But it is a direct example as > you asked for. > > On Thu, Feb 10, 2022 at 3:57 PM Josh Luthman <mailto:j...@imaginenetworksllc.com>> wrote: > &g

Re: junos config commit question

> On Feb 11, 2022, at 14:18 , Lyndon Nerenberg (VE7TFX/VE6BBM) > wrote: > > On an EX4300 switch running JunOS 14.1 let's imagine I typed > > config > delete interfaces > > before coming to my senses. How am I supposed to back out of that > mess? top rollback > For the life

Re: junos config commit question

> > > If I skip the egg timer, then I *will* forget, and it will automatically roll > back. One of my largest annoyances with the Juniper CLI (other than the fact > that it won't format large numbers into a human readable format in things > like 'monitor interface traffic') is that it beeps th

Re: New minimum speed for US broadband connections

> On Feb 16, 2022, at 10:13 , Aaron Wendel wrote: > > The reason government incentives exist is because, in a lot of rural America, > a business case can't be made to connect to Grandma's farm that's 10 miles > from the nearest splice box. If you believe that broad band is a basic > servic

Re: New minimum speed for US broadband connections

tps://www.youtube.com/watch?v=Twe6uTwOyJo&ab_channel=NANOG >>>>>> >>>>>> Our good friend Jared could only get 1.5M DSL living just outside Ann >>>>>> Arbor, MI, so he had to start his own CLEC. >>>>>> >>>&

Re: junos config commit question

Then you didn’t use “commit confirm” as in the post this replied to. Owen > On Feb 16, 2022, at 12:23, Jay Hennigan wrote: > > On 2/16/22 09:56, Owen DeLong via NANOG wrote: > >> You can also do: >> config >> >> commit >> rollback 1 >> c

Re: New minimum speed for US broadband connections

I have to give a shout out here for Mike’s organization (Ridge Wireless). They do provide excellent customer service and decent speeds, though they are sub-fiber and at somewhat of a premium/Mbps vs. terrestrial fiber solutions. I’m currently using Ridge as my primary connectivity with Comcast a

Re: junos config commit question

played, meaning your changes have been discarded. Don't run > "commit confirm x" when the change is "delete interfaces" > > Regards > Paschal Masha | Engineering > Skype ID: paschal.masha > > -Original Message- > From: "Owen DeLo

Re: Cogent cutting links to Russia?

> On Mar 4, 2022, at 13:14 , Bryan Fields wrote: > > On 3/4/22 3:52 PM, Martin Hannigan wrote: >> I would argue they don't have much of a choice: >> >> "The economic sanctions put in place as a result of the invasion and the >> increasingly uncertain security situation make it impossible for

Re: Cogent cutting links to Russia?

> On Mar 4, 2022, at 14:03 , Matthew Petach wrote: > > > > On Fri, Mar 4, 2022 at 12:55 PM Martin Hannigan > wrote: > > I would argue they don't have much of a choice: > > "The economic sanctions put in place as a result of the invasion and the > increasingly un

Re: Russia to disconnect from global Internet

> On Mar 7, 2022, at 11:52 , Hank Nussbacher wrote: > > Bill Woodcock wrote: > > > > This applies exclusively to Russian federal government networks, not ISPs > > or telecom operators. > > > https://twitter.com/krisnova/status/1500590779047170048?s=12 > > says otherwise. And then contra

Re: Cogent cutting links to Russia?

> On Mar 7, 2022, at 07:07 , Masataka Ohta > wrote: > > JeffP wrote: > >> Actually, try this: >> https://home.treasury.gov/news/press-releases/jy0628 > > Are you saying "sanctioning numerous Russian elites and their > family members" has something to do with NANOG? > >

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

One thing is for certain… If folks had put 0.10 as much effort into deploying IPv6 as has been put into arguing about whether or not ~17 /8s worth of IPv4 makes a meaningful difference to the internet as a whole, IPv4 would long since have become irrelevant as it must eventually be. Owen > On

Re: Not Making Use of 240/4 NetBlock

Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able to claim some detailed knowledge on the subject. In general, the RIRs themselves maintain neutrality about such things, looking to their respective communities for input on what to do. However, so long as the IETF and has

Re: Dropping support for the .ru top level domain

I’m reminded of a quote from “2010 The year we make contact”: “Just because our governments are behaving like asses doesn’t mean we have to.” (Roy Scheider as Dr. Heywood Floyd) Breaking any communications facility is, IMHO, counterproductive to all sides. Communication is almost always

Re: "Permanent" DST

> "My flight leaves at 6 AM local time and lasts 90 minutes, but I'm crossing 3 > timezones heading west...so you need to pick me up at...uh4:30 AM your > time? Oh waitare you currently in DST or not because we don't do DST > here, but I think you doso you either need to pick me u

Re: "Permanent" DST

No development really necessary… Just pick the corresponding standard-time timezone and turn off the DST flip flopping. E.g. if you are in California and go always-on, then simply mark it as MST year round. (i.e. just like you’re in Arizona today, which is MST year round, no DST). Owen > On M

Re: V6 still not supported

> > What struck me is how NONE of those challenges in doing IPv6 deployment > in the field had anything to do with fending off attempts to make IPv4 > better. > > Let me say that again. Among all the reasons why IPv6 didn't take > over the world, NONE of them is "because we spent all our time >

Re: "Permanent" DST

> On Mar 15, 2022, at 22:16 , Doug Barton wrote: > > All of this. The reason that the proposal is always worded "Permanent > Daylight Savings Time" is that there are a non-trivial number of people who > genuinely believe that with DST we get more sunlight. Not more sunlight > during the hou

Re: Not Making Use of 240/4 NetBlock

> On Mar 15, 2022, at 19:23 , Mark Andrews wrote: > > > >> On 16 Mar 2022, at 02:54, Owen DeLong via NANOG wrote: >> >> Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able >> to claim some detailed knowledge on the subject. &g

Re: "Permanent" DST

> On Mar 15, 2022, at 17:34 , Chris Adams wrote: > > Once upon a time, Dave said: >> Folks for most systems, this is a change to a single file. Not a really hard >> thing to accomplish > > For lots of up-to-date servers running a current and well-maintained > operating system, this will be

Re: "Permanent" DST

> On Mar 15, 2022, at 15:05 , Jan Schaumann via NANOG wrote: > > Dave wrote: >> Folks for most systems, this is a change to a single file. Not a really hard >> thing to accomplish > > Oh, hah, good one. > > I twitch with mild PTSD thinking about the last time > there was change to DST in t

Re: "Permanent" DST

15 degrees east is Jay’s snarky way of describing permanently putting everyone on a timezone that was formerly applicable to a position roughly 15º east of their current position. In other words, Permanent Daylight Savings time. Owen > On Mar 15, 2022, at 12:19 , Mel Beckman wrote: > > I do

Re: "Permanent" DST

> On Mar 15, 2022, at 12:44 , Jay Hennigan wrote: > > On 3/15/22 12:26, Ray Van Dolson via NANOG wrote: >> I think this is essentially the bill: >> https://www.congress.gov/bill/117th-congress/house-bill/69/text >> Not finding anything about 15 degrees. > > The 15 degrees is kind of a joke. I

Re: "Permanent" DST

> On Mar 16, 2022, at 10:41 , Jay R. Ashworth wrote: > > - Original Message - >> From: "Owen DeLong" > >> No development really necessary… Just pick the corresponding standard-time >> timezone and turn off the DST flip flopping. >> >> E.g. if you are in California and go always-on,

Re: V6 still not supported

e is no logical reason why this > range of v4 subnets wasn’t made available to the world a decade (or two) ago. > The next best time to do it is now though. > > On Wed, Mar 16, 2022 at 12:21 PM Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote: > > > > What st

Re: "Permanent" DST

> On Mar 16, 2022, at 12:24 , Chris Adams wrote: > > Once upon a time, Owen DeLong said: >> You’re right… Two changes to a single file in most cases: >> >> 1. Set the correct new timezone (e.g. MST for California). > > And now your system displays wrong info 100% of the time, since as I >

Re: V6 still not supported

> What I would LOVE to see that someone will pop in with new IP protocol > that is much more similar to IPv4, just extends address space and fixes > some well know issues. (for example remove netmask and use prefixlen/CIDR). This shows a fundamental lack of understanding… Netmask and Prefixlen/C

Re: IPv6 "bloat"

DHCPv6 includes the DEVICE Unique Identifier (DUID). DUID can be any one of several things. By far, the most common ones actually do include the MAC address. Some systems allow you to choose which type of DUID they supply. Macs use a long string that includes the EUI-64 at the end: (an expert f

Re: IPv6 "bloat"

> On Mar 20, 2022, at 07:17, Lady Benjamin Cannon of Glencoe > wrote: > > It seems sketchy to me to even retain client MAC information, no? Genuine > question. > > Didn’t we go to a distinct unique identifier system for this very reason? > > Am I in the 1990s here or? > > We’re just handin

Re: IPv6 "bloat"

> On Mar 20, 2022, at 22:41, Masataka Ohta > wrote: > > Michael Thomas wrote: > >> So out of the current discussions a lot of people have claimed that ipv6 is >> bloated or suffers from second system syndrome, etc. > > IPv6 optional header chain, even after it was widely recognized > that

Re: V6 still not supported

At the IP level, packets are stateless. This means that there is no such thing as a “unidirectional” flow of packets. Virtually every useful flow of packets in one direction requires a relatively symmetrical flow of packets in the other direction. Thus, even if you can “increase the size of the

Re: V6 still not supported

> On Mar 21, 2022, at 12:21, Bjørn Mork wrote: > > Owen DeLong via NANOG writes: > >> Virtually every useful flow of packets in one direction requires a >> relatively symmetrical flow of packets in the other direction. > > Packet captures are useful without

Re: V6 still not supported

> On Mar 23, 2022, at 11:53 , Joe Maimon wrote: > > > > Michael Thomas wrote: >> >>> >> SIP won't displace all legacy PSTN any time soon. So it's a failure by your >> definition. And by your definition IPv6 was a failure before it was even >> born because the internet became popular -- s

Re: V6 still not supported

> On Mar 24, 2022, at 04:43 , Mark Delany wrote: > > On 24Mar22, Vasilenko Eduard allegedly wrote: >> Hence, the primary blocking entity for IPv6 adoption is Google: they do not >> support DHCPv6 for the most popular OS. > > No. The primary "blocking entity" is that "legacy" ipv4 works just

Re: V6 still not supported

> On Mar 24, 2022, at 03:36 , Joe Maimon wrote: > > > > Mark Delany wrote: >> On 23Mar22, Owen DeLong via NANOG allegedly wrote: >> >>> I would not say that IPv6 has been and continues to be a failure >> Even if one might ask that question, wha

Re: V6 still not supported

d=huawei@nanog.org] On > Behalf Of Mark Delany > Sent: Thursday, March 24, 2022 11:35 AM > To: nanog@nanog.org > Subject: Re: V6 still not supported > > On 23Mar22, Owen DeLong via NANOG allegedly wrote: > >> I would not say that IPv6 has been and continues to be a

Re: V6 still not supported

> On Mar 24, 2022, at 14:46 , Michael Thomas wrote: > > > On 3/24/22 1:59 PM, Owen DeLong via NANOG wrote: >> >> Home users aren’t the long tail here. Enterprise is the long tail here. >> Android phones are, >> indeed, part of the enterprise problem,

Re: V6 still not supported

> On Mar 24, 2022, at 14:49 , Michael Thomas wrote: > > > On 3/24/22 2:13 PM, Owen DeLong via NANOG wrote: >> >>> On Mar 24, 2022, at 02:04 , Vasilenko Eduard via NANOG >>> wrote: >>> >>> Hi all, >>>> From 10k me

Re: V6 still not supported

> On Mar 24, 2022, at 15:16 , Michael Thomas wrote: > > > On 3/24/22 3:13 PM, Owen DeLong wrote: >> >>> On Mar 24, 2022, at 14:46 , Michael Thomas wrote: >>> >>> >>> On 3/24/22 1:59 PM, Owen DeLong via NANOG wrote: >>>>

Re: V6 still not supported

> On Mar 24, 2022, at 15:49, Joe Maimon wrote: > > > > Owen DeLong wrote: >> >>> On Mar 24, 2022, at 03:36 , Joe Maimon wrote: >>> >>> >>> >>> In my view that takes the form of a multi-pronged strategy. >>> >>> Do what it takes to keep IPv4 as usable as possible for as long as possible

Re: V6 still not supported

> On Mar 24, 2022, at 21:18 , James R Cutler > wrote: > > On Mar 24, 2022, at 9:25 PM, Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote: >> >> I think that we’re still OK on allocation policies. What I’d like to see is >> an end to the IPv4

Re: V6 still not supported

> On Mar 25, 2022, at 06:30 , Jared Brown wrote: > > Owen DeLong via NANOG wrote: >> When your ISP starts charging $X/Month for legacy protocol support > > Out of interest, how would this come about? ISPs are facing ever growing costs to continue providing IPv4 servic

Re: Let's Focus on Moving Forward Re: V6 still not supported

> On Mar 25, 2022, at 18:47 , Abraham Y. Chen wrote: > > ** Resend to go through NANOG ** > > > On 2022-03-25 12:24, Abraham Y. Chen wrote: >> Dear Owen: >> >> 0)You rapid fired a few posts in succession yesterday. Some are >> interesting and crucial views that I would like to

Re: Let's Focus on Moving Forward Re: V6 still not supported

> On Mar 26, 2022, at 06:35 , Abraham Y. Chen wrote: > > Hi, Owen: > > 0)Re: Ur. Pt. 2):This topic is such a tongue-twister. Let's put it > aside for now, until I can properly convey the EzIP concept and scheme to you. > > 00)Re: Ur. Pt. 4):Okay, I was concerned about how to

Re: Let's Focus on Moving Forward Re: V6 still not supported

> On Mar 26, 2022, at 09:37 , Tom Beecher wrote: > > Have you ever considered that this may be in fact: > > */writing/* and */deploying/* the code that will allow the use of 240/4 the > way you expect > > While Mr. Chen may have considered that, he has repeatedly hand waved that > it's 'not

Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 20220326125.AYC

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. It’s also important to note that there are at least a dozen IPv4 stacks in common use with diffe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Submit an Internet draft, same as any other IP related enhancement gets introduced. What you’re really complaining about is that it’s been virtually impossible to gain consensus to move anything IPv4 related forward in the IETF since at least 2015. Well… It’s a consensus process. If your idea

Re: Let's Focus on Moving Forward Re: V6 still not supported

> On Mar 26, 2022, at 17:30 , Masataka Ohta > wrote: > > Owen DeLong via NANOG wrote: > >> It still looks like NAT to me. > > Almost all the people, perhaps other than you, accept NAT > as is to keep IPv4 Internet or as part of transition > plan from IPv4 t

Re: V6 still not supported

I think this message is 4 days early. Owen > On Mar 28, 2022, at 11:03 , Ryland Kremeier > wrote: > > > > Hmm. > > -Original Message- > From: NANOG > On Behalf Of > Pascal Thubert (pthubert) via NANOG > Sent: Monday, M

Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

ill going to be dual stack > IPv4/IPv6? > When are we going to give up on IPv4? > People can run IPv4 all they want inside their networks for 1000s of years. > What will it take to be IPv6 only? > > 😊 > > From: NANOG <mailto:nanog-bounces+jacques.latour=cira...@nan

Re: Let's Focus on Moving Forward Re: V6 still not supported

> On Mar 29, 2022, at 17:51 , Masataka Ohta > wrote: > > Owen DeLong wrote: > >>> As I repeatedly pointed out, end to end NAT is clean preserving >>> the universal peer to peer nature of the Internet. >> Nope… It really isn’t. > > Wrong. > >> The problem of audit trail opacity is still a m

Re: V6 still not supported

> On Mar 30, 2022, at 08:09 , Jared Brown wrote: > > Owen DeLong via NANOG wrote: >>>> When your ISP starts charging $X/Month for legacy protocol support >>> >>> Out of interest, how would this come about? >> >> ISPs are facing eve

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

> On Mar 30, 2022, at 09:16 , Joe Maimon wrote: > > > > Owen DeLong via NANOG wrote: >> What you’re really complaining about is that it’s been virtually impossible >> to gain consensus to move anything IPv4 related forward in the IETF since at >> least 20

Re: V6 still not supported

> On Mar 30, 2022, at 10:09 , Jared Brown wrote: > > Randy Carpenter wrote: >>>>>>>> Owen DeLong via NANOG wrote: >>>>>>>> When your ISP starts charging $X/Month for legacy protocol support >>>>>>> >>&

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

> On Mar 30, 2022, at 17:00 , Joe Maimon wrote: > > > > Tom Beecher wrote: >> >>If the IETF has really been unable to achieve consensus on properly >>supporting the currently still dominant internet protocol, that is >>seriously problematic and a huge process failure. >> >> >>

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

> But as anyone who has tried to deploy IPv6-only networks quickly discovers, > at the present time, you can't deploy an IPv6-only network with any > success on the global internet today. There's too many IPv6-ish networks > out there that haven't fully established their infrastructure to be re

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

> On Mar 31, 2022, at 15:32 , Joe Maimon wrote: > > > > Matthew Petach wrote: >> >> >> In short, at the moment, you *can't* deploy IPv6 without also having IPv4 >> somewhere in your network. IPv6 hasn't solved the problem of IPv4 >> address shortage, because you can't functionally deploy

Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

wrote: > > https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/ > > <https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/> > >> On 1 Apr 2022, at 06:44, Owen D

Re: What's a "normal" ratio of web sites to IP addresses...

> On Mar 31, 2022, at 16:47 , Bill Woodcock wrote: > > > >> On Apr 1, 2022, at 12:15 AM, Bill Woodcock wrote: >> …in a run-of-the-mill web hoster? >> I’m happy to take private replies and summarize/anonymize back to the list, >> if people prefer. > > I asked the same question on Twitter, a

Re: Let's Focus on Moving Forward Re: V6 still not supported

> On Mar 31, 2022, at 20:51, Masataka Ohta > wrote: > > Owen DeLong wrote: > >> It still suffers from a certain amount of opacity across administrative >> domains. > > So, if an IPv6 prefix is assigned to an apartment building and > the building has no logging mechanism on how addresses ar

Re: Gmail (thus Nanog) rejecting ipv6 email

I’ve not experienced this problem sending emails via IPv6 to gmail destinations from my personal domain. (delong.com ) Likely this email will, in fact, get sent to GMAIL via IPv6. I do have good SPF and DKIM records and signing and a reasonable DMARC policy set up. If ISC

Re: V6 still not supported

> On Apr 4, 2022, at 05:06 , Joe Maimon wrote: > > > > JORDI PALET MARTINEZ via NANOG wrote: >> No, isn't only a Sony problem, becomes a problem for every ISP that has >> customers using Sony PSN and have CGN (NAT444), their IP blocks are >> black-listed when they are detected as used CGN.

Re: V6 still not supported

CGN, and use that money to transfer up-front more IPv4 addresses at > once, you will get a better price than if you transfer them every few months. > > >Regards, >Jordi >@jordipalet > > > >El 30/3/22, 18:38, "NANOG en nombre de Jared Bro

Re: Gmail (thus Nanog) rejecting ipv6 email

> On Apr 4, 2022, at 08:13 , Robert Kisteleki wrote: > > > On 2022-04-03 07:18, Owen DeLong via NANOG wrote: >> I’ve not experienced this problem sending emails via IPv6 to gmail >> destinations from my personal domain. >> (delong.com <http://delong.com>

Re: antique CGN complaints, was V6 still not supported

> On Apr 4, 2022, at 11:56 , John Levine wrote: > > It appears that JORDI PALET MARTINEZ via NANOG > said: >> Related to the LEA agencies and CGN: >> >> https://www.europol.europa.eu/media-press/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-g

Re: [nanog] 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40

> On Apr 4, 2022, at 17:40 , John Curran wrote: > > >> On 4 Apr 2022, at 7:42 PM, Dan Mahoney (Gushi) > > wrote: >> >> On Tue, 5 Apr 2022, Job Snijders via NANOG wrote: >> >>> I think all of us recognize a need to declaw "third party" IRR databases >>> like RADB

Re: [nanog] 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40

> On Apr 5, 2022, at 15:04 , John Curran wrote: > > >> On 5 Apr 2022, at 5:31 PM, Owen DeLong > > wrote: >>> On Apr 4, 2022, at 17:40 , John Curran >> > wrote: >>> ... >> >>> Interesting – as ARIN’s fee schedule was designed specifically so t

Re: ARIN fee structure (was: re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT)

> On Apr 6, 2022, at 04:48 , John Curran wrote: > > On 5 Apr 2022, at 11:57 PM, William Herrin > wrote: >> >> On 5 Apr 2022, at 8:38 PM, Dan Mahoney (Gushi) > > wrote: >>> But say they sign an LRSA: Those $0 fees would go up to 150, this yea

Re: ARIN fee structure (was: re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT)

> > Indeed - you only emphasize why it is important for organizations to get > involved in ARIN’s governance… It is not intended that your sole interaction > with ARIN be via contractual mechanisms, but rather that network operators > actually participate as members of the organization. Per

Re: [nanog] 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40

> On Apr 7, 2022, at 03:21 , John Curran wrote: > > On 7 Apr 2022, at 1:05 AM, Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote: >> >>> On Apr 5, 2022, at 15:04 , John Curran >> <mailto:jcur...@arin.net>> wrote: >>> ... >&g

Re: ARIN fee structure (was: re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT)

> On Apr 7, 2022, at 07:25 , John Curran wrote: > > >> On 7 Apr 2022, at 2:08 AM, Owen DeLong > > wrote: >> >>> Indeed - you only emphasize why it is important for organizations to get >>> involved in ARIN’s governance… It is not intended that your sole >>> interact

Re: ARIN fee structure (was: re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT)

> On Apr 7, 2022, at 08:16 , John Curran wrote: > > On 7 Apr 2022, at 1:58 AM, Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote: >> … >> Yes, but if you don’t have a contract with ARIN, ARIN’s ability to revoke >> your resources because the

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

Is it? What’s the bandwidth of a good quality 4K stream? What about 4 of them + various additional interactive technologies, software downloads, media downloads, etc.? Looking at the graphs, my household (which isn’t average by any stretch of the imagination, but it is a household) doesn’t nee

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

I think a gig is not an unreasonable target… It’s 100Mbps plus adequate headroom for the likely oversubscription models and the occasional downloads that are modern day reality. Nobody is going to consistently use 1Gbps, but the difference in wire time for a large download between 100Mbps and 1

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

> On May 23, 2022, at 15:59, james.cut...@consultant.com wrote: > > On May 23, 2022, at 6:39 PM, Michael Thomas wrote: >> >> >> On 5/23/22 3:26 PM, Owen DeLong wrote: >>> Is it? >>> >>> What’s the bandwidth of a good quality 4K stream? What about 4 of them + >>> various additional interact

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

> I agree that it probably doesn't change much for the ISP's (my rural ISP > installing fiber apparently disagrees tho). The thing is that if you're > talking about downloads, the game manufacturers will just fill to whatever > available capacity the pipes will give so it probably won't ever g

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

> On May 23, 2022, at 17:20, Sean Donelan wrote: > > > Remember, this rulemaking is for 1.1 million locations with the "worst" > return on investment. The end of the tail of the long tail. Rural and tribal > locations which aren't profitable to provide higher speed broadband. Yes… Places

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

> files. (Let's not talk about 16/1.5 ADSL, going even further back, that was > time for a quick snooze...) One doesn’t have to go back… In San Jose, CA, the best DSL available at my location is still 1.5M/384K on a good day. Add water (rain) and it drops to something more like 768K/128K.

Re: FYI - 2FA to be come mandatory for ARIN Online? (was: Fwd: [arin-announce] Consultation on Requiring Two-Factor Authentication (2FA) for ARIN Online Accounts

I use google auth for several forced 2FA sites and a few sites where what I am protecting is worth the hassle. One difficulty that quickly emerges is managing and finding the correct Totp in the long unsorted list. It’s no big deal when you have 6 or even 10, but as it approaches 100 different

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

Forgive me if I have little or no sympathy for them. Owen > On May 29, 2022, at 14:10, Eric Kuhnke wrote: > > This is going to be very painful and difficult for a number of DOCSIS3 > operators, including some of the largest ISPs in the USA with multi-millions > of subscribers with tons of le

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com <http://www.ics-il.com/> > > Midwest-IX > http://www.midwest-ix.com <http://www.midwest-ix.com/> > > From: "Owen DeLong via NANOG" > To: "Michael Thomas" > Cc: nanog

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

> On Jun 1, 2022, at 20:49 , Seth Mattinen wrote: > > On 6/1/22 8:12 PM, Mitchell Tanenbaum via NANOG wrote: >> Believe it or not, there is cable within 500 yards, but they won’t extend >> it. (: > > > 50 feet across the street from me on the east side of the road is AT&T FTTH > territory.

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

> On Jun 2, 2022, at 06:41 , Masataka Ohta > wrote: > > Sean Donelan wrote: > >>> USF is great for rural, but it has turned medium density and suburban areas >>> into connectivity wastelands. >> Carrier & cable lobbying organizations say that free market competition by >> multiple provider

Re: Aftermarket switches that were manufactured in any sort of quantity?

Depending on what you need, I will point out that Hula has pretty good pricing on Juniper EX4200-48P switches at this time. Last I looked, they were going for $250/ea. Owen > On Jun 10, 2022, at 08:13 , Robert Blayzor via NANOG wrote: > > On 6/9/22 15:07, Saku Ytti wrote: >> They're not reall

Re: Scanning the Internet for Vulnerabilities

I would still consider an uninvited scan of my network antisocial. Other operators are, of course, free to make their own choices. Owen > On Jun 19, 2022, at 03:13 , Ronald F. Guilmette > wrote: > > I would like to solicit the opinions of network operators on the practice > of scanning all

Re: Scanning the Internet for Vulnerabilities

shadow server (to the best of my knowledge) only scans sites that have invited them to do so. Owen > On Jun 19, 2022, at 10:43 , Forrest Christian (List Account) > wrote: > > See shadowserver.net > On Sun, Jun 19, 2022, 4:13 AM Ronald F. Guilmette

Re: What say you, nanog re: Starlink vs 5G?

> On Jun 24, 2022, at 12:33 , Michael Thomas wrote: > > > On 6/24/22 9:09 AM, Chris Wright wrote: >> The term "5G" among technical circles started vague, became better defined >> over the course of several years, and is becoming vague again. This nuance >> was never well understood in the p

Re: What say you, nanog re: Starlink vs 5G?

> On Jun 24, 2022, at 13:12 , Michael Thomas wrote: > > > On 6/24/22 12:38 PM, Owen DeLong wrote: >> >>> On Jun 24, 2022, at 12:33 , Michael Thomas wrote: >>> >>> >>> On 6/24/22 9:09 AM, Chris Wright wrote: The term "5G" among technical circles started vague, became better defined >>

Re: IoT - The end of the internet

Break, probably not… Require IPv6 eventually? Probably. Owen > On Aug 9, 2022, at 19:22 , Christopher Wolff wrote: > > Hi folks, > > Has anyone proposed that the adoption of billions of IoT devices will > ultimately ‘break’ the Internet? > > It’s not a rhetorical question I promise, just

Re: IoT - The end of the internet

> On Aug 9, 2022, at 20:06 , Mel Beckman wrote: > > LOL! You’re not the first person to underestimate the resilience of the > Internet: > > “There is no reason anyone would want a computer in their home.” – Ken Olsen, > CEO of Digital Equipment Corporation (now defunct), 1977 Technically no

Re: IoT - The end of the internet

> On Aug 10, 2022, at 15:29 , Christopher Wolff wrote: > > Hi NANOG; > > I appreciate all the thoughtful replies and I apologize for vague posting > when I should be sleeping. > > Let me paint a little more context and hopefully this will help inform the > conversation. > > Use Case 1: Au

Re: IoT - The end of the internet

> On Aug 10, 2022, at 15:51 , Mel Beckman wrote: > > Christopher, > > What you’re really observing here is that today's technology does not yet > enable these your chosen use cases. It may someday, but not today, not for > any amount of money. 1990s modem technology didn’t enable streaming

Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 2023)

I highly recommend that legacy holders who wish to ensure that their rights are respected transfer their registrations to RIPE-NCC, whether they have signed the LRSA or not. Transferring to RIPE-NCC as Legacy without Contract will afford you full respect for your rights in your resources in per

Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 2023)

> Moving to RIPE is not an unalloyed good; Europeans invented bureaucracy, > and RIPE pursues it with vigor. And getting the above treatment may > require firmly asserting to RIPE that you want it, rather than accepting > the defaults. But their motives are more benevolent than ARIN's toward > le

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 20

I could be mistaken, but I believe that RIPE NCC provides RPKI services for Legacy without Contract resource holders. Owen > On Sep 15, 2022, at 15:55 , Rubens Kuhl wrote: > > You could try suggesting IANA/PTI/ICANN to have a different RPKI trust > anchor and provide such services to legacy b

<    1   2   3   4   5   >