The problem with this approach, and with scrubbing centers more generally,
is that while the cure might be better than the disease it doesn't result
in usable VOIP. Voice customers don't care if things are _better_ but
their MOS scores are still below 2.
Scott Helms
On Wed, Sep 22, 2021 at 11:
I'm going to be reaching out to both of the organizations you listed, but I
don't see any of their documentation mentioning SIP, RTP, or any of the
"normal" VOIP protocols or use cases.
Scott Helms
On Wed, Sep 22, 2021 at 9:18 AM Ray Orsini wrote:
> Yes there are. I was about to message Steve
On Fri, Jul 9, 2021 at 4:47 PM Michael Thomas wrote:
>
> On 7/9/21 1:36 PM, K. Scott Helms wrote:
> > Nothing will change immediately. Having said that, I do expect that
> > we will see much more effective enforcement. The investigations will
> > come from the ITG (
Nothing will change immediately. Having said that, I do expect that we
will see much more effective enforcement. The investigations will come
from the ITG (Industry Traceback Group) with enforcement coming from FCC or
FTC depending on the actual offense. The problem has been that it's been
far t
Two decent options, one on prem and the other fully hosted.
Tucows/OpenSRS has a fully hosted email offering that was built for ISPs to
resell. (They also have domain registration and some other ISP focused
services.)
https://opensrs.com/services/hosted-email/
MagicMail is an email (including w
William Herrin wrote:
> On Sat, Jun 12, 2021 at 3:55 PM K. Scott Helms
> wrote:
> > I don't think you're lying, but you are mistaken.
> >
> > "I'm not lying. Google's server at passwords.google.com
> > composed an html web page containing my
il.mit.edu/6.857/2020/projects/6-Vadari-Maccow-Lin-Baral.pdf
Scott Helms
On Sat, Jun 12, 2021 at 5:51 PM William Herrin wrote:
> On Sat, Jun 12, 2021 at 12:10 PM K. Scott Helms
> wrote:
> > Scott, Google's computer is able to compose an html document which
> > contains
inputting
it and they do not store it.
https://support.google.com/chrome/answer/165139?visit_id=637591216572649483-884903087&rd=1
Scott Helms
On Sat, Jun 12, 2021 at 10:29 AM William Herrin wrote:
> On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms
> wrote:
> > Encryption
Encryption != plain text, just because it's not a hash doesn't mean it's
problematic (if done correctly). This is the exact same method that every
single password management system uses and all are far better for the
average user than trying to reuse a single password or write them down.
Scott He
cceptable-use-policy
>
> Have these AUPs been invoked previously for these reasons, or would that be
> new territory?
>
> Sent from Mobile Device
>
> On Jan 10, 2021, at 2:52 PM, K. Scott Helms wrote:
>
>
> Right, it's not a list for content hosting.
>
> S
Right, it's not a list for content hosting.
Scott Helms
On Sun, Jan 10, 2021, 5:42 PM wrote:
> No, this is a list for Network Operators.
>
> Sent from my iPhone
>
> On Jan 10, 2021, at 5:32 PM, K. Scott Helms
> wrote:
>
>
> This is a list for pushing bits
>
> Sent from my iPhone
>
> On Jan 10, 2021, at 4:27 PM, K. Scott Helms
> wrote:
>
>
> No,
>
> It really does not. Section 230 only applies to publishers, and not to
> network providers. If this were a cloud hosting provider list then you'd
> be corr
It's not, and frankly it's disappointing to see people pushing an agenda here.
Scott Helms
On Sun, Jan 10, 2021 at 9:37 AM wrote:
>
> NANOG is a group of Operators, discussion does not have to be about
> networking. I have already explained how this represents a significant issue
> for Netwo
We've been on hold for more than an hour trying to get an update.
We see the same behavior where they continue to announce our blocks
despite all the interfaces to them being hard down.
Scott Helms
On Sun, Aug 30, 2020 at 8:58 AM Jason Kuehl wrote:
>
> Well, When I tried calling I got a fast b
Nick,
Data on blocking inbound TCP or the kinds of gear that mistakenly
labels UDP fragments as DST port 0?
Scott Helms
On Wed, Aug 26, 2020 at 9:00 AM Nick Hilliard wrote:
>
> K. Scott Helms wrote on 26/08/2020 13:55:
> > To be clear, UDP port 0 is not and probably shouldn&
ve
> > a port number. It's possible that some packet analyzers or network
> > gear will improperly "see" a partial UDP flow as port 0 but that's a
> > mischaracterization of the flow.
> >
> >
> > Scott Helms
> >
> > Scott Helms
>
That's correct, I can only blame my lack of coffee at that point for
the oversight. I went back and looked at where we have this
implemented and it's only TCP.
Scott Helms
On Tue, Aug 25, 2020 at 8:46 AM Job Snijders wrote:
>
> On Tue, Aug 25, 2020 at 08:27:24AM -0400, K. S
tt Helms
Scott Helms
On Tue, Aug 25, 2020 at 8:17 AM Job Snijders wrote:
>
> On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote:
> > I think a fairly easy thing to do is see what other large retail ISPs
> > have done. Comcast, as an example, lists all of the ports
Douglas,
I think a fairly easy thing to do is see what other large retail ISPs have
done. Comcast, as an example, lists all of the ports they block and 0 is
blocked. I do recommend that port 0 be blocked by all of the ISPs I work
with and frankly Comcast's list is a pretty good one to use in gen
The spec allows for bridging or layer 3 but none of the major or certified
manufacturers support bridging on larger platforms. (>1000 modems)
Scott Helms
On Fri, May 8, 2020 at 3:56 PM Brandon Martin
wrote:
> I'm curious...
>
> Is it part of the DOCSIS spec that the CMTS terminates L3, or ca
Javier,
There's really no good way to handle this without routing or tunneling that
I've been able to find in a very long time. (SD-WAN can help, but it's
just a fancy way to tunnel in this regard.) It's pretty amazing that this
is such an issue, but it remains so. I have tried to work around t
There are lots of options to solve that problem.
Peplink, 128T, Viptela (Cisco), Velocloud (VMWare), etc.
Scott Helms
On Tue, Jan 28, 2020 at 6:31 PM K MEKKAOUI wrote:
> Dear NANOG Community,
>
>
>
> Can anyone help with any device information that provides redundancy for
> business internet
They almost have to change the default since there are (comparatively) very
few DoH providers compared to DNS providers.
On Tue, Oct 1, 2019, 2:40 PM Damian Menscher via NANOG
wrote:
> On Tue, Oct 1, 2019 at 12:24 PM Jay R. Ashworth wrote:
>
>> - Original Message -
>> > From: "Stephane
After all, it worked for Napster
Scott Helms
On Thu, Apr 25, 2019 at 3:23 PM John Levine wrote:
> In article you write:
> >-=-=-=-=-=-
> >
> >feeling cranky, are we, job? (accusing an antispam expert of spamming
> on a mailing list by having too long a .sig?)
> >but it’s true! anne r
eved and
> decrypted by a agent or the end user via the web portal. Nothing has been
> shown that I can recall reading that proves or disproves any of that.
>
>
>
> On Thu, Apr 25, 2019 at 1:17 PM Doug Barton wrote:
>
>> On 4/25/19 8:04 AM, K. Scott Helms wrote:
>> &g
onfiguration every time it reboots, and
the vendors and associations in the provisioning and OSS space have more
input than the operators themselves.
Scott Helms
On Thu, Apr 25, 2019 at 1:16 PM Doug Barton wrote:
> On 4/25/19 8:04 AM, K. Scott Helms wrote:
> > Just so you know, if y
Just so you know, if you have an embedded router from a service provider
all of that data is _already_ being transmitted and has been for a long
long time. If it's being collected via SNMPv2c it is being transmitted in
the clear (though hopefully encrypted via BPI+ between the modem and the
CMTS).
e service
provider.
Scott Helms
On Thu, Apr 25, 2019 at 8:38 AM James R Cutler
wrote:
> On Apr 25, 2019, at 8:26 AM, K. Scott Helms
> wrote:
>
> People are missing the point here. This is _not_ a Comcast "issue" this
> same data is available to every single cable operat
People are missing the point here. This is _not_ a Comcast "issue" this
same data is available to every single cable operator in the US who deploys
bundled modem/router/APs that follow the CableLabs standard. They may or
may not expose the data to their end customers, but it's stored in their
sys
While it's correct that it's stored in the vendor proprietary MIB this
information is commonly retrieved from the CableLabs standard MIB and via
TR-181 in DSL and FTTH gear.
I wrote up an answer on the security forum originally refereneced, but for
convenience here is the same text.
The PSK pass
I really can't believe I'm going to say this, but this has been a good
SD-WAN use case for us.
Scott Helms
On Fri, Dec 28, 2018 at 2:30 PM Aaron1 wrote:
> On the topic of static ip... as a Net Eng of an ISP, and seeing the pains
> that we have to endure with our static ip customers , I wonde
I'd say that any carrier grade GPON gear is way overkill for a LAN and
you're going to have to run single mode fiber to use the consumer grade
ONTs which is a big extra expense as few structured wiring companies do
single mode. Second, Dasan Zhone is one of the vendors I'd absolutely
avoid and I'v
> Peering isn't the problem. Proximity to content is.
>
> Netflix, Google, Akamai and a few others have presence in Africa already.
> So those aren't the problem (although for those currently in Africa, not
> all of the services they offer globally are available here - just a few).
>
> A lot of use
know what that looks like in Africa.
Scott Helms
On Wed, Jul 18, 2018 at 10:00 AM Mark Tinka wrote:
>
>
> On 18/Jul/18 15:41, K. Scott Helms wrote:
>
>
>
> That's why I vastly prefer stats from the actual CDNs and content
> providers that aren't generated by spe
> - Original Message -
>
> From: "K. Scott Helms"
> To: "Mike Hammett"
> Cc: "NANOG list"
> Sent: Wednesday, July 18, 2018 8:45:22 AM
> Subject: Re: Proving Gig Speed
>
>
> Mike,
>
> What portal would that be? Do you ha
Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ----- Original Message -
>
> From: "K. Scott Helms"
> To: "mark tinka"
> Cc: "NANOG list"
> Sent: Wednesday, July 18, 2018 7:40:31 AM
&g
On Wed, Jul 18, 2018 at 9:01 AM Mark Tinka wrote:
>
> Personally, I don't think the content networks and CDN's should focus on
> developing yet-another-speed-test-server, because then they are just
> pushing the problem back to the ISP. I believe they should better spend
> their time:
>
>- De
AM Mark Tinka wrote:
>
>
> On 18/Jul/18 14:00, K. Scott Helms wrote:
>
>
> That's absolutely a concern Mark, but most of the CPE vendors that support
> doing this are providing enough juice to keep up with their max
> forwarding/routing data rates. I don't see 10 Gbps
e:
>
>
> On 17/Jul/18 14:07, K. Scott Helms wrote:
>
>
> That's absolutely true, but I don't see any real alternatives in some
> cases. I've actually built automated testing into some of the CPE we've
> deployed and that works pretty well for some models bu
That's absolutely true, but I don't see any real alternatives in some
cases. I've actually built automated testing into some of the CPE we've
deployed and that works pretty well for some models but other devices don't
seem to be able to fill a ~500 mbps link.
On Tue, Jul 17, 2018 at 8:03 AM Mark
Mark,
A couple of things, first that kind of utilization isn't feasible once
penetration rates in dense areas reach certain levels. There's a reason
that NTT Docomo moved more than 70% of their data traffic to the 3.5 GHz
band and that reason is that there's not (nor will there be) enough
wireles
A substantial percentage, perhaps 100%, of the use case can be accomplished
using micro-segmentation.
On Tue, May 29, 2018 at 2:33 PM LF OD wrote:
> Been following the articles on "intent-based" networking from Cisco and
> other vendors for a couple years now, and I have a basic grasp of the
> c
*" PS: For anyone who came into the middle of this argument, my point
isthat if you have no EU nexus, the realistic chances of the EU
takingaction against you round to zero. If you do have EU nexus, you
betterbehave."*
I'd say this is accurate with a few caveats and most of those won't apply
to N
ler_ can also be held liable, and the financial penalties in GDPR
are very stiff."*
Yep, this is better (clearer) wording than what I used and is absolutely
correct.
On Thu, May 24, 2018 at 10:21 AM Anne P. Mitchell Esq.
wrote:
>
>
> > On May 23, 2018, at 7:18 PM, K. Scott Helms
Anne,
Yep, if you're doing a decent job around securing data then you don't have
much to be worried about on that side of things. The problem for most
companies is that GDPR isn't really a security law, it's a privacy law (and
set of regulations). That's where it's hard because there are a limit
Yeah, that's not accurate. US organizations sue EU organizations in US
courts (and vice versus) on a regular basis but have EU courts collect the
damages. Congress can carve out an exemption, but I haven't heard of an
effort in that direction getting started yet. In the absence of a
legislative
; Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "K. Scott Helms"
> To: "Mike Hammett"
> Cc: "NANOG list"
> Sent: Wednesday, May 23, 2018 7:46:1
Sadly this isn't true. While I doubt the EU regulators are going to come
head hunting for companies any time soon they do have mechanisms in place
to sanction companies who don't do business in the EU and the scope is
clearly intended to reach where ever the data of EU natural persons is
being hel
ts on DSL) so anyway
unrelated to any client’s address space. Also, french triple play ISPs use
RFC1918 space for IPTV but again isolated of any customer network so
doesn’t really matter.
> On 2 Mar 2018, at 22:18, K. Scott Helms wrote:
>
> I won't comment on the sanity of doing so
I won't comment on the sanity of doing so, but _many_ service providers use
EMTAs, ATAs, and other voice devices over RFC1918 space back to their core.
On Fri, Mar 2, 2018 at 4:11 PM, Mark Andrews wrote:
> Are you insane. ISPs should never use RFC 1918 addresses for stuff that
> talks to their c
Matthew,
Sadly, open source + SNMP traps != simple.
The simplest option that I've personally used in the past is SNMPTT with
Nagios.
https://paulgporter.net/2013/09/16/nagios-snmp-traps/
http://www.snmptt.org/docs/snmptt.shtml
The main problem is that SNMP traps, like most of SNMP, aren't simp
That sounds like giving up an awful lot of utility for a (at least in most
places) something that's an exceedingly rare corner case. The other
problem is that even if the record is immutable there's nothing that
prevents governments from being coercive in other ways. At the end of the
day there's
Mike,
While that's true today it's changing rapidly. Linear viewership is,
depending on your take on things, either in the beginning or the middle of
it's long tail phase. You're right in that we'll have people using linear
viewing habits for a long time, but that model only looks sustainable ov
the
>
> ISPs some pizza sized box (lets call it an "Appliance") and that box
>
> then provides unicast delivery to each customer watching the Superbowl.
>
>
>
>
>
> *Sent from my iPhone*
>
> On Nov 21, 2017, at 8:22 AM, K. Scott Helms wrote:
>
>
des
and/or direct (low cost) connections to their CDN. That's far more
efficient than allowing multicast across WAN links.
K. Scott Helms
On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory
wrote:
> I’m not paying anything for local resources with regards to local edge
> delivery, that’s
55 matches
Mail list logo
