Re: DSLAMs

[Nick Edwards]

Thanks all for the input, huawei is ruled out due to politics, looks
like for costs we'll stick to the 48 ports from planet



On 1/1/20, Clayton Zekelman  wrote:
>
> I'd recommend avoiding the C7 - ADSL2+
> performance on them isn't the best.   Look for
> something with a Broadcom chipset.  Even an old
> Calix B6 would be better than C7 - although the
> B6 gear is getting old, and reliability is
> sketchy.  The power converter modules on board seem to go.
>
> At 01:51 PM 31/12/2019, Shawn L via NANOG wrote:
>
>>That's a tough one.  48 port dslams with
>>internal splitters are easy.  When you're
>>looking for more density you're almost always
>>looking at external splitter shelves.  Could
>>also look at the calix c7 platform -- tons
>>around on the used market -- but then again, no splitters.
>>
>>
>>
>>
>>-Original Message-
>>From: "Dennis Lundström" 
>>Sent: Tuesday, December 31, 2019 12:32pm
>>To: "Nick Edwards" 
>>Cc: "NANOG" 
>>Subject: Re: DSLAMs
>>
>>Found this one:
>>ftp://ftp2.dlink.com/SUPPORT/End_of_Life_Product_List_091519.pdf
>>Stating EOL 2015-04-14 for HW revision A1.
>>—Dennis
>>
>>On Tue, Dec 31, 2019 at 10:27 Nick Edwards
>><nick.z.edwa...@gmail.com> wrote:
>>Howdy y'all
>>
>>Chasing some info, does dlink still sell DAS4672 - 672 port adsl2+ dslams?
>>
>>after simple IP based  units with pppoe pass through.
>>We could buy a bunch of planet 48 ports, which we used before, but we
>>hoping someone still puts out high capacity (320 plus port) units with
>>inbuilt pots splitters
>>
>>thanks
>
> --
>
> Clayton Zekelman
> Managed Network Systems Inc. (MNSi)
> 3363 Tecumseh Rd. E
> Windsor, Ontario
> N8W 1H4
>
> tel. 519-985-8410
> fax. 519-985-8409

Re: 5G roadblock: labor

[Mark Milhollan]

On Mon, 30 Dec 2019, Brian J. Murrell wrote:


I'm not saying that maybe one day we won't need 25Mb/s to a hand-held
device, but hologram telephone calling, Netflixing and even video
calling, are not the use-cases, IMHO.


Actually you went on to say that future innovations shouldn't exist 
because that's just crass consumerism, and that we should be satisfied 
with (in particular) HDMI instead of desiring better -- sorry, people 
will want better, e.g., the realism of 4k, 8k and 16k which the devices 
and networks of today either cannot provide (that HDMI flatscreen 
display probably cannot handle even 4k much less 8k+) or would struggle 
to provide (carrying 25+ Mb/s to dozens or hundreds of nodes -- remember 
even pico cells server multiple nodes).


Video to tablets and phones/phablets are indeed a major use case, for 
the majority not you or I -- you don't want high bandwidth video calling 
yet others might, i.e., Facetime is quite the thing and perhaps in 2 
years with enough bandwidth available those holographic calls would be 
too.  Even I might change my mind if my customers began demanding 
high-fidelity video conferencing even while mobile.


Some messages back mention was made of SSH being nice over the reduced 
latency 5G brings which might appeal to you but would be meaningless to 
most users.  I had no issue with SSH even over 1xRTT so I guess 3G need 
not have been deployed.


IoT will need lots of bandwidth but not the low latency nor the reduced 
jitter that 5G can provide.  A single thing generally won't need much 
but that isn't the measure since the idea is there will eventually be 
hundreds of things per household and thousands or millions per business, 
of which dozens, hundreds or thousands will be within the service area 
of a group of cells.  And even if that's still low in toto it translates 
to needing headroom so the things that do need significant individual 
streams won't starve.  Besides we aren't the customers for most of 
these, we're the product.


But there's no need to imagine a killer use case nor even a significant 
set of cases -- they will come if the ability is there.  In NA the key 
will be probably the cost, as another message pointed out.  The 
transition from 3G to 4G didn't proportionally increase the usage 
allowed, at least IME, but it was enough that many make video calls from 
their mobile device and some do watch videos on them.



/mark

Re: GPS Sync Outage

[Forrest Christian (List Account)]

One of my hats is to design/manufacture/sell GPS third party timing
receivers for Cambium Radios.It seems like something happened around
2PM MST today which caused (at a minimum) certain Globaltop/Sierra Wireless
GPS modules to quit receiving signals from the GPS constellations.
 Because these modules are pretty well respected as far as the quality of
the timing signal (normally) and relative low cost, they tend to be
integrated in a lot of devices, including my products, the official Cambium
Products, and I understand the gear from other manufacturers.

So far, a power cycle/reset of the GPS module seems to solve the problem.

I haven't had enough time to process all of the data I have to know more
details yet, but I can confirm the widespread nature of this event.

On Tue, Dec 31, 2019 at 5:39 PM Jared Mauch  wrote:

>
>
> > On Dec 31, 2019, at 5:32 PM, Andreas Ott  wrote:
> >
> > On Tue, Dec 31, 2019 at 05:08:17PM -0500, Matt Hoppes wrote:
> >> Is anyone else seeing GPS timing source outages across the U. S. In the
> last two hours?
> >
> > On what hardware/firmware are you seeing this?
> >
> > Nothing unusual in the Bay Area so far, in other words "All Quiet on the
> > Western Front". I am seeing receivers synced to at least 6 or 7 sats. Two
> > different locations; one Garmin 18LVC, one uBlox 6M hardware. There is
> > also no chatter about it on the time-nuts list where I would suspect to
> > see it first.
>
> There’s a fair amount of hardware that uses GPS sync for wireless and I’m
> guessing this is likely a vendor bug w/ UBNT hardware, but it’s also good
> to know if it’s broader than that.
>
> I know there’s some interesting java bugs related to the switchover for
> 2020 as well, eg:
>
> https://twitter.com/NmVAson/status/1207820284268597249
>
> I know of at least once place that was hit by this.
>
> - Jared
>
>

-- 
- Forrest

Re: GPS Sync Outage

[Jared Mauch]

> On Dec 31, 2019, at 5:32 PM, Andreas Ott  wrote:
> 
> On Tue, Dec 31, 2019 at 05:08:17PM -0500, Matt Hoppes wrote:
>> Is anyone else seeing GPS timing source outages across the U. S. In the last 
>> two hours?
> 
> On what hardware/firmware are you seeing this?
> 
> Nothing unusual in the Bay Area so far, in other words "All Quiet on the
> Western Front". I am seeing receivers synced to at least 6 or 7 sats. Two
> different locations; one Garmin 18LVC, one uBlox 6M hardware. There is
> also no chatter about it on the time-nuts list where I would suspect to
> see it first.

There’s a fair amount of hardware that uses GPS sync for wireless and I’m 
guessing this is likely a vendor bug w/ UBNT hardware, but it’s also good to 
know if it’s broader than that.

I know there’s some interesting java bugs related to the switchover for 2020 as 
well, eg:

https://twitter.com/NmVAson/status/1207820284268597249

I know of at least once place that was hit by this.

- Jared

Re: Paging anyone from ntpd.org

[Harlan Stenn]

On 12/31/2019 7:21 AM, Seth Mattinen wrote:
> On 12/31/19 1:32 AM, Harlan Stenn wrote:
>> On 12/30/2019 8:32 PM, Seth Mattinen wrote:
>>> On 12/30/19 8:22 PM, Seth Mattinen wrote:
 Is anyone from ntpd.org on here? You're pointing DNS at me for some
 reason. That zone (ntpd.org) isn't in our system. Your NS looks odd
 too, *.darkness-reigns.net and .nl? Is that legit? I don't know what
 it was before because I've never looked, but that seems off.


>>>
>>> nevermind, I'm tired and confused ntpd.org with ntp.org. Just going to
>>> wildcard *.ntpd.org to 127.0.0.1 and go back to sleep.
>>
>> I did think about replying, saying "Just to be clear, this isn't about
>> ntp.org."
>>
> 
> 
> What I did learn though there are a lot of people configuring their NTP
> with servers that are identical to the legitimate *.ntp.org names,
> except they're mistyping ntpd instead of ntp. Enough to generate >2Gbps
> worth of query traffic (pointed at a DNS server with a 1gbps interface).
> 
> I have to admit I'm kind of curious how many unique clients that would
> be if I answered back with a working IP address instead of localhost.

If the folks who registered ntpd.org are OK with it, we'd be happy to
take that domain over and do right by it.

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

Re: GPS Sync Outage

[Andreas Ott]

On Tue, Dec 31, 2019 at 05:08:17PM -0500, Matt Hoppes wrote:
> Is anyone else seeing GPS timing source outages across the U. S. In the last 
> two hours?

On what hardware/firmware are you seeing this?

Nothing unusual in the Bay Area so far, in other words "All Quiet on the
Western Front". I am seeing receivers synced to at least 6 or 7 sats. Two
different locations; one Garmin 18LVC, one uBlox 6M hardware. There is
also no chatter about it on the time-nuts list where I would suspect to
see it first.

-andreas

Re: GPS Sync Outage

[Mike Hammett]

I've heard from people having the issue in South Africa as well. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Matt Hoppes"  
To: nanog@nanog.org 
Sent: Tuesday, December 31, 2019 4:08:17 PM 
Subject: GPS Sync Outage 

Is anyone else seeing GPS timing source outages across the U. S. In the last 
two hours? 

GPS Sync Outage

[Matt Hoppes]

Is anyone else seeing GPS timing source outages across the U. S. In the last 
two hours?

Re: DSLAMs

[Clayton Zekelman]

I'd recommend avoiding the C7 - ADSL2+ 
performance on them isn't the best.   Look for 
something with a Broadcom chipset.  Even an old 
Calix B6 would be better than C7 - although the 
B6 gear is getting old, and reliability is 
sketchy.  The power converter modules on board seem to go.


At 01:51 PM 31/12/2019, Shawn L via NANOG wrote:

That's a tough one.  48 port dslams with 
internal splitters are easy.  When you're 
looking for more density you're almost always 
looking at external splitter shelves.  Could 
also look at the calix c7 platform -- tons 
around on the used market -- but then again, no splitters.





-Original Message-
From: "Dennis Lundström" 
Sent: Tuesday, December 31, 2019 12:32pm
To: "Nick Edwards" 
Cc: "NANOG" 
Subject: Re: DSLAMs

Found this one:
ftp://ftp2.dlink.com/SUPPORT/End_of_Life_Product_List_091519.pdf
Stating EOL 2015-04-14 for HW revision A1.
—Dennis

On Tue, Dec 31, 2019 at 10:27 Nick Edwards 
<nick.z.edwa...@gmail.com> wrote:

Howdy y'all

Chasing some info, does dlink still sell DAS4672 - 672 port adsl2+ dslams?

after simple IP based  units with pppoe pass through.
We could buy a bunch of planet 48 ports, which we used before, but we
hoping someone still puts out high capacity (320 plus port) units with
inbuilt pots splitters

thanks


--

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409

Re: DSLAMs

[Shawn L via NANOG]

That's a tough one.  48 port dslams with internal splitters are easy.  When 
you're looking for more density you're almost always looking at external 
splitter shelves.  Could also look at the calix c7 platform -- tons around on 
the used market -- but then again, no splitters.
 

-Original Message-
From: "Dennis Lundström" 
Sent: Tuesday, December 31, 2019 12:32pm
To: "Nick Edwards" 
Cc: "NANOG" 
Subject: Re: DSLAMs




Found this one:

[ ftp://ftp2.dlink.com/SUPPORT/End_of_Life_Product_List_091519.pdf ]( 
ftp://ftp2.dlink.com/SUPPORT/End_of_Life_Product_List_091519.pdf )
Stating EOL 2015-04-14 for HW revision A1.
—Dennis



On Tue, Dec 31, 2019 at 10:27 Nick Edwards <[ nick.z.edwa...@gmail.com ]( 
mailto:nick.z.edwa...@gmail.com )> wrote:Howdy y'all

 Chasing some info, does dlink still sell DAS4672 - 672 port adsl2+ dslams?

 after simple IP based  units with pppoe pass through.
 We could buy a bunch of planet 48 ports, which we used before, but we
 hoping someone still puts out high capacity (320 plus port) units with
 inbuilt pots splitters

 thanks

Re: ServiceFinder: Ärendenummer 185392

[Dennis Lundström]

Contacted servicefinder, describing the problem in Swedish, kindly asking
them to unsubscribe.

Best regards.

—Dennis

On Sun, Dec 29, 2019 at 17:24 J. Hellenthal via NANOG 
wrote:

> Well if that ain’t just plain spam I don’t know what is!
>
> --
>  J. Hellenthal
>
> The fact that there's a highway to Hell but only a stairway to Heaven says
> a lot about anticipated traffic volume.
>
> On Dec 29, 2019, at 16:18, i...@servicefinder.com wrote:
>
> 
> __
> Vänligen skriv endast ovanför denna markering när du svarar på meddelandet.
> Hej Scott Weeks,
> Tack för din fråga!
>
> Vi har nu registrerat ditt ärende och du kommer inom kort att bli
> kontaktad av oss på Kundservice.
>
> Du kan också få hjälp själv via vårt Support Center på
> www.support.servicefinder.se. 
>
> Du har ärendenummer *185392* – och alla våra ärenden hanteras i den
> turordning som de kommer in.
>
> Vi kontaktar dig så snart vi bara kan, din fråga är viktig för oss.
>
> Ha en fortsatt bra dag,
> --
>
>
> Med vänliga hälsningar
> *Kundservice*
>
> Öppettider: Vardagar 9-17 | Växel: 08-653 00 00 <+468653>
> Hemsida: www.servicefinder.se [image: ServiceFinder.se]
> --
>
> Detta meddelande skickades till sur...@mauigateway.com med hänvisning
> till ärende 185392.
> [[a6e862e24e9f255dfb1e2e9c14f288dfee770f40-1483209862]]
>
>

Re: ServiceFinder: Ärendenummer 185600

[Dennis Lundström]

Hej. Kan ni vänligen avregistrera i...@servicefinder.com på nanog@nanog.org
mailing-listan?

I skrivande stund får alla dom postar till denna lista detta svar tillbaka
vilket är lite irriterande.

Mvh.

—Dennis Lundström

On Tue, Dec 31, 2019 at 12:33 NANOG  wrote:

> __
> Vänligen skriv endast ovanför denna markering när du svarar på meddelandet.
> Hej Nick Edwards,
> Tack för din fråga!
>
> Vi har nu registrerat ditt ärende och du kommer inom kort att bli
> kontaktad av oss på Kundservice.
>
> Du kan också få hjälp själv via vårt Support Center på
> www.support.servicefinder.se. 
>
> Du har ärendenummer *185600* – och alla våra ärenden hanteras i den
> turordning som de kommer in.
>
> Vi kontaktar dig så snart vi bara kan, din fråga är viktig för oss.
>
> Ha en fortsatt bra dag,
> --
>
>
> Med vänliga hälsningar
> *Kundservice*
>
> Öppettider: Vardagar 9-17 | Växel: 08-653 00 00 <+468653>
> Hemsida: www.servicefinder.se [image: ServiceFinder.se]
> --
>
> Detta meddelande skickades till nick.z.edwa...@gmail.com med hänvisning
> till ärende 185600.
> [[de728c7f1b871ccabccf286b44e42e8f0097f0a7-1483568274]]

Re: DSLAMs

[Dennis Lundström]

Found this one:
ftp://ftp2.dlink.com/SUPPORT/End_of_Life_Product_List_091519.pdf


Stating EOL 2015-04-14 for HW revision A1.

—Dennis

On Tue, Dec 31, 2019 at 10:27 Nick Edwards  wrote:

> Howdy y'all
>
> Chasing some info, does dlink still sell DAS4672 - 672 port adsl2+ dslams?
>
> after simple IP based  units with pppoe pass through.
> We could buy a bunch of planet 48 ports, which we used before, but we
> hoping someone still puts out high capacity (320 plus port) units with
> inbuilt pots splitters
>
> thanks
>

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[joel jaeggli]

On 12/31/19 08:25, Seth Mattinen wrote:
> On 12/31/19 8:10 AM, joel jaeggli wrote:
>> Argumentation on the basis of a tu quoque fallacy doesn't really add
>> much to the dicussion. Depreciating potentialy dangerous and definitely
>> obsolete protocols does not make you a hypocrite.
> 
> 
> Then how about privilege?
> 
> If someone is living in a less-privileged situation (oppressive regime,
> state controlled ISP, extreme poverty, whatever) there's also a good
> chance that such people may not able to acquire newer/updated technology
> easily, perhaps not even legally at great risk. I will disagree with
> anyone's assertion that people in such conditions deserve to be
> disenfranchised.

You cite a hypothetical situation that may, but does not in my
experience exist, I work with customers who had populations of impacted
devices, so the consequences and timing of these transitions are
directly consequential to our customers.

Most CDNs turned off tls 1.0 by early to mid-2018. The  mobile devices
that still required it at the time and did not have an alternative were
a vanishingly small portion of the population then in use (for example
legacy docomo i-mode handsets), and the ones that cannot support it now
are still smaller,  Lacking support for SNI was a signification consumer
of address consumption in CDNs and that contributes to accessibility
cost and usability issues for websites  attempts at universal tls
deployment as well so we should be clear that there are plenty of people
who were disenfranchised by or burdened with otherwise unnecessary costs
by the need to support tls 1.0.

Most populations have recourse to application alternatives that can and
did extend their useful service life to tls 1.2 (current firefox
supports back to android 4.1 for example, Opera mini /mobile have much
larger market shares in bandwidth constrained environments and superior
performance on low end devices). tls 1.1 is not really far on the heels
of 1.0. hence you see this now.





signature.asc
Description: OpenPGP digital signature

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Royce Williams]

On Tue, Dec 31, 2019 at 7:46 AM Matt Harris  wrote:

>
> On Tue, Dec 31, 2019 at 10:34 AM Royce Williams 
> wrote:
>
>> On Tue, Dec 31, 2019 at 7:17 AM Matt Harris  wrote:
>>
>>>
>>> The better solution here isn't to continue to support known-flawed
>>> protocols, which perhaps puts those same populations you're referring to
>>> here at greatest risk, but rather to enable access to open technologies for
>>> those populations which ensures that they can continue to receive security
>>> updates from a vendor that doesn't have a big financial motive to deprecate
>>> devices and force users to purchase upgraded hardware instead of just
>>> receiving security updates to their existing devices.
>>>
>>
>> Unfortunately, this is the high-tech privilege equivalent of saying "let
>> them eat cake" - because of upgrade friction on mobile in under-resources
>> areas (including, I might add, specific sub-populations of US consumers!)
>>
>
> Perhaps more unfortunately, the other option - to continue supporting
> known-flawed protocols - is simply saying "let them be victimized."
>

With the rise of state-level disinformation at scale, I see your point.


> Accepting that we should instead support technologies that place those
> very same populations at risk is coming from a place of privilege for the
> reasons I mentioned previously: you live somewhere with relatively
> peaceful/democratic governance, usually have at least some ISP choice, and
> are likely not otherwise under the thumb of an oppressive regime at some
> level of another - so when your browser makes a TLS1.0 connection, you
> probably don't even think about it, much less worry about it, because you
> don't have to. The populations we're discussing here, on the other hand,
> all too often do.
>
> What it comes down to is a question of whether we want to solve what we
> know today is a real problem or let it fester until abuse reaches an
> untenable level in some big, news-headline-making way. One way we can
> combat this specific issue is to make open technologies accessible. But
> that requires major investment on our side of the world, and prior attempts
> to do so (Ubuntu's open source phone OS for example) have largely been
> commercial flops.
>

Indeed. Though a non-commercial (grass-roots, sponsored, or legislative)
solution seems similarly unlikely.

Royce

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Peter Beckman]

On Dec 31, 2019, at 00:30, Matt Hoppes  
wrote:

Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why 
not either let it fall back to 1.0 or to HTTP.

This seems like security for no valid reason.


On Dec 31, 2019, at 04:04, John Adams  wrote:

because no one should know what you read about or check out at wikipedia


On Tue, 31 Dec 2019, Mike Hammett wrote:


If you care that bad, you work towards meeting the requirement. If you don't 
care, then you don't.


 What happens when you care but your current environment, one in which a
 new-ish phone, tablet, laptop or desktop is not readily available or at a
 price point that you cannot afford without starving yourself and your
 family?

 If there are technically and free-speech reasons to force TLSv1.2, provide
 an HTTP version that restricts edits or whatever technical reasons
 Wikimedia Corp is changing for.

 This may only affect 1% of Wikipedia users, but 1% in a world of 4.48
 billion Internet-using humans, where the US population is 4.27% of the
 world population, 1% is a HUGE number. 1% is about the size of Uganda or
 Argentina.

 You and I, sitting comfortably in North America, sipping our Starbucks
 Latte while casually surfing on our iPads and Lenovos, may have zero
 problem accessing everything using TLSv1.2. But my iPhone from 2007 won't,
 despite it still being functional.

 Let us stand for freedom, free speech, openness and sharing in a world
 that seems to forget how we got here in the first place.

Beckman
---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Job Snijders]

On Tue, Dec 31, 2019 at 17:26 Seth Mattinen  wrote:

> On 12/31/19 8:10 AM, joel jaeggli wrote:
> > Argumentation on the basis of a tu quoque fallacy doesn't really add
> > much to the dicussion. Depreciating potentialy dangerous and definitely
> > obsolete protocols does not make you a hypocrite.
>
>
> Then how about privilege?
>
> If someone is living in a less-privileged situation (oppressive regime,
> state controlled ISP, extreme poverty, whatever) there's also a good
> chance that such people may not able to acquire newer/updated technology
> easily, perhaps not even legally at great risk. I will disagree with
> anyone's assertion that people in such conditions deserve to be
> disenfranchised.



I’m not entirely sure an argument based on privilege applies cleanly here.
There are freely supported (open source) TLS 1.2 / TLS 1.3 implementations
available for download - at no cost - that run on commodity hardware, even
as old as i386 cpu chips.

Kind regards,

Job

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Matt Harris]

On Tue, Dec 31, 2019 at 10:34 AM Royce Williams 
wrote:

> On Tue, Dec 31, 2019 at 7:17 AM Matt Harris  wrote:
>
>>
>> The better solution here isn't to continue to support known-flawed
>> protocols, which perhaps puts those same populations you're referring to
>> here at greatest risk, but rather to enable access to open technologies for
>> those populations which ensures that they can continue to receive security
>> updates from a vendor that doesn't have a big financial motive to deprecate
>> devices and force users to purchase upgraded hardware instead of just
>> receiving security updates to their existing devices.
>>
>
> Unfortunately, this is the high-tech privilege equivalent of saying "let
> them eat cake" - because of upgrade friction on mobile in under-resources
> areas (including, I might add, specific sub-populations of US consumers!)
>

Perhaps more unfortunately, the other option - to continue supporting
known-flawed protocols - is simply saying "let them be victimized."

Accepting that we should instead support technologies that place those very
same populations at risk is coming from a place of privilege for the
reasons I mentioned previously: you live somewhere with relatively
peaceful/democratic governance, usually have at least some ISP choice, and
are likely not otherwise under the thumb of an oppressive regime at some
level of another - so when your browser makes a TLS1.0 connection, you
probably don't even think about it, much less worry about it, because you
don't have to. The populations we're discussing here, on the other hand,
all too often do.

What it comes down to is a question of whether we want to solve what we
know today is a real problem or let it fester until abuse reaches an
untenable level in some big, news-headline-making way. One way we can
combat this specific issue is to make open technologies accessible. But
that requires major investment on our side of the world, and prior attempts
to do so (Ubuntu's open source phone OS for example) have largely been
commercial flops.

- mdh

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Royce Williams]

On Tue, Dec 31, 2019 at 7:32 AM Royce Williams 
wrote:

> On Tue, Dec 31, 2019 at 7:17 AM Matt Harris  wrote:
>
>> On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen  wrote:
>>
>>> On 12/31/19 12:50 AM, Ryan Hamel wrote:
>>> > Just let the old platforms ride off into the sunset as originally
>>> > planned like the SSL implementations in older JRE installs, XP, etc.
>>> You
>>> > shouldn't be holding onto the past.
>>>
>>>
>>> Because poor people anywhere on earth that might not have access to the
>>> newer technology don't deserve access to Wikipedia, right? Gotta make
>>> sure information is only accessible to those with means to keep "lesser"
>>> people out.
>>>
>>
>> The better solution here isn't to continue to support known-flawed
>> protocols, which perhaps puts those same populations you're referring to
>> here at greatest risk, but rather to enable access to open technologies for
>> those populations which ensures that they can continue to receive security
>> updates from a vendor that doesn't have a big financial motive to deprecate
>> devices and force users to purchase upgraded hardware instead of just
>> receiving security updates to their existing devices.
>>
>
> Unfortunately, this is the high-tech privilege equivalent of saying "let
> them eat cake" - because of upgrade friction on mobile in under-resources
> areas (including, I might add, specific sub-populations of US consumers!)
>
> If there were reliable, official, clean replacement Androrid ROMs for
> older hardware, the cottage industry of end-user phone repair in many
> countries could take a perfectly good phone and get basic modern services
> working on it.
>
> But there aren't - and there's little financial motivation for the phone
> OEMs to provide one. And there isn't really much you can do to replace the
> OS on an old iPhone, either.
>
> One of the best things that Google could do for the security of the
> Android ecosystem is to provide clean, OEM-bloat-free, reference ROMs for
> older phones with minimal backported security updates. I would expect that
> such ROMs must actually exist internally, as needed for OEM patch
> integration testing.
>
> The answer to why such ROMs will likely not be made publicly available is
> left as an exercise for the reader.
>

But perhaps you were suggesting that a *grass-roots* effort to create such
ROMs might be in order?

I would love to donate to such a project.

But short of a million-dollar grant, or legislation, I am not optimistic.

Royce

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Josh Luthman]

No one mentioned the passwords need to be encrypted?

Why have an old encryption method that isn't secure?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Tue, Dec 31, 2019 at 11:34 AM Royce Williams 
wrote:

> On Tue, Dec 31, 2019 at 7:17 AM Matt Harris  wrote:
>
>> On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen  wrote:
>>
>>> On 12/31/19 12:50 AM, Ryan Hamel wrote:
>>> > Just let the old platforms ride off into the sunset as originally
>>> > planned like the SSL implementations in older JRE installs, XP, etc.
>>> You
>>> > shouldn't be holding onto the past.
>>>
>>>
>>> Because poor people anywhere on earth that might not have access to the
>>> newer technology don't deserve access to Wikipedia, right? Gotta make
>>> sure information is only accessible to those with means to keep "lesser"
>>> people out.
>>>
>>
>> The better solution here isn't to continue to support known-flawed
>> protocols, which perhaps puts those same populations you're referring to
>> here at greatest risk, but rather to enable access to open technologies for
>> those populations which ensures that they can continue to receive security
>> updates from a vendor that doesn't have a big financial motive to deprecate
>> devices and force users to purchase upgraded hardware instead of just
>> receiving security updates to their existing devices.
>>
>
> Unfortunately, this is the high-tech privilege equivalent of saying "let
> them eat cake" - because of upgrade friction on mobile in under-resources
> areas (including, I might add, specific sub-populations of US consumers!)
>
> If there were reliable, official, clean replacement Androrid ROMs for
> older hardware, the cottage industry of end-user phone repair in many
> countries could take a perfectly good phone and get basic modern services
> working on it.
>
> But there aren't - and there's little financial motivation for the phone
> OEMs to provide one. And there isn't really much you can do to replace the
> OS on an old iPhone, either.
>
> One of the best things that Google could do for the security of the
> Android ecosystem is to provide clean, OEM-bloat-free, reference ROMs for
> older phones with minimal backported security updates. I would expect that
> such ROMs must actually exist internally, as needed for OEM patch
> integration testing.
>
> The answer to why such ROMs will likely not be made publicly available is
> left as an exercise for the reader.
>
> Royce
>

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Royce Williams]

On Tue, Dec 31, 2019 at 7:17 AM Matt Harris  wrote:

> On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen  wrote:
>
>> On 12/31/19 12:50 AM, Ryan Hamel wrote:
>> > Just let the old platforms ride off into the sunset as originally
>> > planned like the SSL implementations in older JRE installs, XP, etc.
>> You
>> > shouldn't be holding onto the past.
>>
>>
>> Because poor people anywhere on earth that might not have access to the
>> newer technology don't deserve access to Wikipedia, right? Gotta make
>> sure information is only accessible to those with means to keep "lesser"
>> people out.
>>
>
> The better solution here isn't to continue to support known-flawed
> protocols, which perhaps puts those same populations you're referring to
> here at greatest risk, but rather to enable access to open technologies for
> those populations which ensures that they can continue to receive security
> updates from a vendor that doesn't have a big financial motive to deprecate
> devices and force users to purchase upgraded hardware instead of just
> receiving security updates to their existing devices.
>

Unfortunately, this is the high-tech privilege equivalent of saying "let
them eat cake" - because of upgrade friction on mobile in under-resources
areas (including, I might add, specific sub-populations of US consumers!)

If there were reliable, official, clean replacement Androrid ROMs for older
hardware, the cottage industry of end-user phone repair in many countries
could take a perfectly good phone and get basic modern services working on
it.

But there aren't - and there's little financial motivation for the phone
OEMs to provide one. And there isn't really much you can do to replace the
OS on an old iPhone, either.

One of the best things that Google could do for the security of the Android
ecosystem is to provide clean, OEM-bloat-free, reference ROMs for older
phones with minimal backported security updates. I would expect that such
ROMs must actually exist internally, as needed for OEM patch integration
testing.

The answer to why such ROMs will likely not be made publicly available is
left as an exercise for the reader.

Royce

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[John Von Essen]

There are really two arguments here.

1. TLSv1.0 is insecure and should never be used in an HTTPS scenario - cant 
argue with this
2. Alot of static content sites are forcing HTTPS even though “technically” 
there is nothing that needs to be secured in transit - this is where the 
argument lies.

Why does access to wikipedia need to go over https? There is no login, no 
credit card  or SSNs being transferred, etc.,. Part of the blame is google, 
they started penalize sites in their index if they didn’t do https, as a 
result, almost every website now does ssl - everything from allrecipes.com 
 to a mommy blog, literally you cant find a non-ssl 
website anymore, everybody wants the better google rank, so they all gave in 
and went 100% ssl.

There is a reason however for search engines to enforce https, its a privacy 
issue, everyone is snooping on you, so if you dont want your ISP knowing what 
your searching for (http://search.com/?q=looking+for+a+divorce+lawyer) and then 
selling that info to advertisers, you need https - and yes Wiki is sort of 
search engine.

What I foresee happening is people will come up with a 3rd party solution, 
basically, you’ll start seeing people offer http->https proxy services, it will 
be interesting to see if the content source providers try to clamp down on this 
or let it happen…

-John


> On Dec 31, 2019, at 11:11 AM, Royce Williams  wrote:
> 
> On Tue, Dec 31, 2019 at 6:12 AM Seth Mattinen  > wrote:
> On 12/31/19 12:50 AM, Ryan Hamel wrote:
> > Just let the old platforms ride off into the sunset as originally 
> > planned like the SSL implementations in older JRE installs, XP, etc. You 
> > shouldn't be holding onto the past.
> 
> 
> Because poor people anywhere on earth that might not have access to the 
> newer technology don't deserve access to Wikipedia, right? Gotta make 
> sure information is only accessible to those with means to keep "lesser" 
> people out.
> 
> This. 
> 
> I visited a rural school in South Africa around 2008. 
> 
> For many things - such as using their cellphone provider's billing 
> infrastructure to pay for third-party services via SMS - a switch to TLS 1.2 
> only would probably have no impact. 
> 
> But for educational purposes, their reliance on Wikipedia was dramatic - and 
> they could *only* get to it from outdated phones that had been donated, 
> scavenged, or cobbled together from parts.
> 
> In the intervening years, the disposable-electronics culture has probably 
> been a great boon to them, bringing better and more tech - but much of it is 
> probably still pre Android 4.4.2
> 
> But perhaps Wikipedia's decision is based on actual data. I'd love to see 
> percentages of their negotiated TLS ciphers, per country and per client type. 
> Back in 2015,  you could see them as discussed here:
> 
> https://news.ycombinator.com/item?id=10194258 
> 
> 
> ... but I'm not sure where the equivalent data would be in the new Grafana 
> data:
> 
> https://grafana.wikimedia.org/?orgId=1 
> 
> 
> Royce

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Seth Mattinen]

On 12/31/19 8:10 AM, joel jaeggli wrote:

Argumentation on the basis of a tu quoque fallacy doesn't really add
much to the dicussion. Depreciating potentialy dangerous and definitely
obsolete protocols does not make you a hypocrite.



Then how about privilege?

If someone is living in a less-privileged situation (oppressive regime, 
state controlled ISP, extreme poverty, whatever) there's also a good 
chance that such people may not able to acquire newer/updated technology 
easily, perhaps not even legally at great risk. I will disagree with 
anyone's assertion that people in such conditions deserve to be 
disenfranchised.

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Nick Hilliard]

joel jaeggli wrote on 31/12/2019 18:10:

TLS1.0  is genuinely hard to support at this point. Doing  so limits the
tooling you can use, It limits the CDNs that you can use. It forces you
to use obsolete codes bases.


not just that, TLS 1.2 has been around since 2008, i.e. 1 month before 
android 1.0 was released.  Seems odd that it took until 2015 for it to 
be included by default.


Nick

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Matt Harris]

On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen  wrote:

> On 12/31/19 12:50 AM, Ryan Hamel wrote:
> > Just let the old platforms ride off into the sunset as originally
> > planned like the SSL implementations in older JRE installs, XP, etc. You
> > shouldn't be holding onto the past.
>
>
> Because poor people anywhere on earth that might not have access to the
> newer technology don't deserve access to Wikipedia, right? Gotta make
> sure information is only accessible to those with means to keep "lesser"
> people out.
>

The better solution here isn't to continue to support known-flawed
protocols, which perhaps puts those same populations you're referring to
here at greatest risk, but rather to enable access to open technologies for
those populations which ensures that they can continue to receive security
updates from a vendor that doesn't have a big financial motive to deprecate
devices and force users to purchase upgraded hardware instead of just
receiving security updates to their existing devices.

On Tue, Dec 31, 2019 at 10:07 AM Mike Hammett  wrote:

> If you want the increased security and can afford so, by all means use it.
>
> If you cannot afford the increased security, I guess the response is to
> just bugger off...  we don't need your kind?
>

I'm curious how increased security necessarily costs significant amounts of
money. The bandwidth used to download a package or the source code for the
latest version of OpenSSL (or any number of other crypto libraries) is
relatively negligible. The issue only arises when folks are trapped in
expensive upgrade cycles by vendors with the aforementioned financial
motives.

I don't have a great solution to income inequality and economic disparity
on a whole, but the solution to this specific issue is definitely not to
put those populations at risk by encouraging them and others to continue
using known-flawed technology.

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Royce Williams]

On Tue, Dec 31, 2019 at 6:12 AM Seth Mattinen  wrote:

> On 12/31/19 12:50 AM, Ryan Hamel wrote:
> > Just let the old platforms ride off into the sunset as originally
> > planned like the SSL implementations in older JRE installs, XP, etc. You
> > shouldn't be holding onto the past.
>
>
> Because poor people anywhere on earth that might not have access to the
> newer technology don't deserve access to Wikipedia, right? Gotta make
> sure information is only accessible to those with means to keep "lesser"
> people out.
>

This.

I visited a rural school in South Africa around 2008.

For many things - such as using their cellphone provider's billing
infrastructure to pay for third-party services via SMS - a switch to TLS
1.2 only would probably have no impact.

But for educational purposes, their reliance on Wikipedia was dramatic -
and they could *only* get to it from outdated phones that had been donated,
scavenged, or cobbled together from parts.

In the intervening years, the disposable-electronics culture has probably
been a great boon to them, bringing better and more tech - but much of it
is probably still pre Android 4.4.2

But perhaps Wikipedia's decision is based on actual data. I'd love to see
percentages of their negotiated TLS ciphers, per country and per client
type. Back in 2015,  you could see them as discussed here:

https://news.ycombinator.com/item?id=10194258

... but I'm not sure where the equivalent data would be in the new Grafana
data:

https://grafana.wikimedia.org/?orgId=1

Royce

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[joel jaeggli]

On 12/31/19 07:10, Seth Mattinen wrote:
> On 12/31/19 12:50 AM, Ryan Hamel wrote:
>> Just let the old platforms ride off into the sunset as originally
>> planned like the SSL implementations in older JRE installs, XP, etc.
>> You shouldn't be holding onto the past.
> 
> 
> Because poor people anywhere on earth that might not have access to the
> newer technology don't deserve access to Wikipedia, right? Gotta make
> sure information is only accessible to those with means to keep "lesser"
> people out.

Argumentation on the basis of a tu quoque fallacy doesn't really add
much to the dicussion. Depreciating potentialy dangerous and definitely
obsolete protocols does not make you a hypocrite.

TLS 1.0 is genuinely hard to support at this point. Doing  so limits the
tooling you can use, It limits the CDNs that you can use. It forces you
to use obsolete codes bases.




signature.asc
Description: OpenPGP digital signature

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Mike Hammett]

If you want the increased security and can afford so, by all means use it. 

If you cannot afford the increased security, I guess the response is to just 
bugger off... we don't need your kind? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Matt Harris"  
To: "Matt Hoppes"  
Cc: "Constantine A. Murenin" , "North American Network 
Operators' Group"  
Sent: Tuesday, December 31, 2019 10:02:26 AM 
Subject: Re: Wikipedia drops support for old Android smartphones; mandates 
TLSv1.2 to read 



On Tue, Dec 31, 2019 at 2:30 AM Matt Hoppes < mattli...@rivervalleyinternet.net 
> wrote: 



Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why 
not either let it fall back to 1.0 or to HTTP. 

This seems like security for no valid reason. 




Being able to authenticate that the content you've requested is coming from the 
source from which you requested it seems like a pretty valid reason to me. If 
you live in a privileged nation with democratic governance, and you have ISP 
choice and your ISP doesn't and won't hijack your connections and you're not 
otherwise in an environment where your connections may be hijacked for any 
number of reasons by any number of parties, then you may not think about this 
very much. Employing the best (popular, well-supported, well-documented, 
completely open) current standard, TLS 1.2, instead of supporting deprecated, 
known-flawed previous versions of that protocol also seems like an entirely 
reasonable idea, too. 


If you don't like that this potentially disenfranchises users of old devices 
(and there's perhaps a case to be made here), then the ire should be imho 
directed towards the device vendors for not issuing security updates for 
whatever version you wish were able to support modern technology. Not at free 
web-based services for ending support for deprecated, known-flawed 
protocols/ciphers/etc. If google wanted to issue an update for older android 
versions to support TLS1.2 then they absolutely could, though users may see 
some detrimental performance impact to using modern technology on an outdated 
device. 


This isn't a new issue, and we as the greater internet community have generally 
tackled it by taking aggressive measures towards deprecating known-flawed 
technologies on a conservative timeline. 


RFC5246 was published over a decade ago. 


- mdh 

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Matt Harris]

On Tue, Dec 31, 2019 at 2:30 AM Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:

> Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t
> work why not either let it fall back to 1.0 or to HTTP.
>
> This seems like security for no valid reason.


Being able to authenticate that the content you've requested is coming from
the source from which you requested it seems like a pretty valid reason to
me. If you live in a privileged nation with democratic governance, and you
have ISP choice and your ISP doesn't and won't hijack your connections and
you're not otherwise in an environment where your connections may be
hijacked for any number of reasons by any number of parties, then you may
not think about this very much. Employing the best (popular,
well-supported, well-documented, completely open) current standard, TLS
1.2, instead of supporting deprecated, known-flawed previous versions of
that protocol also seems like an entirely reasonable idea, too.

If you don't like that this potentially disenfranchises users of old
devices (and there's perhaps a case to be made here), then the ire should
be imho directed towards the device vendors for not issuing security
updates for whatever version you wish were able to support modern
technology. Not at free web-based services for ending support for
deprecated, known-flawed protocols/ciphers/etc. If google wanted to issue
an update for older android versions to support TLS1.2 then they absolutely
could, though users may see some detrimental performance impact to using
modern technology on an outdated device.

This isn't a new issue, and we as the greater internet community have
generally tackled it by taking aggressive measures towards deprecating
known-flawed technologies on a conservative timeline.

RFC5246 was published over a decade ago.

- mdh

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[DaKnOb]

I still don’t see any multi-million dollar donation receipts though.. 

So if we want to do this, do we sacrifice security for the 99.9% or do we have 
Wikimedia pay the bill?

Oh, BTW, I have some network equipment with only 16-bit ASN support, or no 
large communities, or no IPv6, or no AES, or no BGP4, or no RPKI, or no [...] 
so I don’t know if it’s late but maybe we should revert at least some of those, 
because they’re not really needed.. The internet is broken anyways, so we don’t 
need more ASNs, or security, or connectivity anyways.. Oh, and it can do only 
10 Mbit Ethernet, so my buffers fill up with anything at GbE or above, can we 
scrap them too? 

On a serious note, I don’t think TLS does not provide validation of the server 
just because the Web PKI system is broken, and I don’t think TLS doesn’t 
provide security or privacy. And I also believe they are needed. There are many 
scenarios where they are vital.. 

- They protect against modifying content: now if an anonymous edit is made, 
everyone will see and revert it, without TLS everyone could see a different 
thing and we wouldn’t know. 
- They protect against knowing what people browse (privacy): I don’t want 
others to know what information I look up on Wikipedia, or at least more people 
than necessary. Someone mentioned that if I have this requirement I should work 
towards it. I think most people have this requirement and it’s easier if 
Wikipedia works towards it, than everyone setting up a network and peering 
directly with every website they want to use. 

I am usually in favor of replacing things if possible that hold back everyone 
else, even if it hurts. We’re not throwing away last year’s phones, but devices 
closing 10 years in life. If we want devices we want to keep, and reduce 
e-waste and all that, we should find a way to keep them up to date, not demand 
that nobody makes any progress.. If Android could get updates (I think it can 
now) we could just add TLS 1.2 and TLS 1.3 by backporting. No new features, 
just essentials. But for some reason, someone, not necessarily in the Android 
team, and for some reason, decided that it’s not a priority.

Would we accept network equipment that doesn’t receive updates? Maybe, due to 
cost. But should we, or just maybe put some pressure on the manufacturer to 
support it for more than 3 months?

There’s a debate on how long the new cars should receive software updates. 
People keep them for over 15 years. Should we replace our cars every 2? No. The 
manufacturers should support them for a reasonable period, and then we should 
accept that some features will stop working. 

Now you may say if the car manufacturer stops producing parts after 2 years, 
you can find some third party ones. Well, nobody stops you from operating a 
reverse proxy for Wikipedia at unsafewikipedia.org, but the pros and cons there 
are different.. 

> On 31 Dec 2019, at 17:12, Seth Mattinen  wrote:
> 
> On 12/31/19 12:50 AM, Ryan Hamel wrote:
>> Just let the old platforms ride off into the sunset as originally planned 
>> like the SSL implementations in older JRE installs, XP, etc. You shouldn't 
>> be holding onto the past.
> 
> 
> Because poor people anywhere on earth that might not have access to the newer 
> technology don't deserve access to Wikipedia, right? Gotta make sure 
> information is only accessible to those with means to keep "lesser" people 
> out.

Re: 5G roadblock: labor

[Mike Hammett]

I do not disupte the fact that 5G NR is better than 4G LTE. However, it isn't 
going to have monumental spectral efficiency improvements that aren't available 
in the LTE world. Mostly the capacity improvements are coming from moving from 
2x2 MIMO to something like 64x64 MuMIMO (which is available in the LTE world) 
or through new spectrum. 


Rural fixed service is best served by fixed operators (WISPs), not mobile 
companies. The mobile companies keep trying to do fixed service, but it always 
sucks... badly. Generally they come in, announce some new, spectacularly 
awesome service. Customers leave the local company for the mobile company. They 
often return within 60 days because the service was so bad. In those areas 
where the mobile companies aren't doing 4G at the moment, you might as well 
discard any hope that they'll ever do anything useful for you and look for the 
local WISP to solve your need. 


Post-600MHz auction, US operators generally have some reasonable amount of 
spectrum below 1 GHz, which is good for good building penetration. They 
generally have pretty good amount of spectrum from 1.7 GHz - 2.3 GHz. Really 
only Sprint uses anything between 2.3 and 10 GHz. Anything above that is going 
to be short-range LOS only. 


I'm not sure what hype train is winning the race, IoT or 5G. Most IoT devices 
are not going to have high bandwidth requirements, but will need low power 
usage. 







- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Brandon Butterworth"  
To: "Mike Hammett"  
Cc: "Shane Ronan" , "nanog"  
Sent: Tuesday, December 31, 2019 9:29:30 AM 
Subject: Re: 5G roadblock: labor 

On Tue Dec 31, 2019 at 08:10:20AM -0600, Mike Hammett wrote: 
> I would still find it hard to believe you would need that kind 
> of speed, today, in any reasonable situation. 

Who said it's all for you? Marketing may tell you it is to 
get you to buy but it's really for everyone else. In some places 
4G is quite congested, a lack of enough low spectrum leads to 
congestion and the expensive clearance and recycling of 700Mhz 
from TV to mobile (UK currently doing this) 

Moving as many as possible to 5G gets operators out of a hole, 
equipment manufacturers are doing dual 4/5G kit to make dynamic 
use of the limited low spectrum 

So you don't need it but they need you to believe you do. 

> Also, today's infrastructure can more than handle that in most places 

Rural for lack of anything better is being sold (in UK) LTE 
home routers and VOD is popular so the sooner they can move 
low (they will never get high) spectrum to 5G the better. We 
do still have a lot of rural without 2G though so it's not 
clear what they will do there 

There is also a 5G land grab of other uses making it out as 
good for lots of things (IoT, factories, rural access), I 
presume that is the same elsewhere? 

> I'm not saying what we have will work for us forever, but it 
> will solve no current problems. There is no need to rush like 
> the network is on fire. 

It is in places, they predict it will be elsewhere if they get 
the customer base they are aiming for. So they do want it to put 
out the fires they are starting plus with equimpment cycles their 
best hope it to get as many to upgrade with the newness hype 
otherwise they will join the long tail and be difficult to move 
later once they find it wasn't necessary. 

brandon 

Re: 5G roadblock: labor

[Brandon Butterworth]

On Tue Dec 31, 2019 at 08:10:20AM -0600, Mike Hammett wrote:
> I would still find it hard to believe you would need that kind
> of speed, today, in any reasonable situation.

Who said it's all for you? Marketing may tell you it is to
get you to buy but it's really for everyone else. In some places
4G is quite congested, a lack of enough low spectrum leads to
congestion and the expensive clearance and recycling of 700Mhz
from TV to mobile (UK currently doing this)

Moving as many as possible to 5G gets operators out of a hole,
equipment manufacturers are doing dual 4/5G kit to make dynamic
use of the limited low spectrum

So you don't need it but they need you to believe you do.

> Also, today's infrastructure can more than handle that in most places

Rural for lack of anything better is being sold (in UK) LTE
home routers and VOD is popular so the sooner they can move
low (they will never get high) spectrum to 5G the better. We
do still have a lot of rural without 2G though so it's not
clear what they will do there

There is also a 5G land grab of other uses making it out as
good for lots of things (IoT, factories, rural access), I
presume that is the same elsewhere?

> I'm not saying what we have will work for us forever, but it
> will solve no current problems. There is no need to rush like
> the network is on fire. 

It is in places, they predict it will be elsewhere if they get
the customer base they are aiming for. So they do want it to put
out the fires they are starting plus with equimpment cycles their
best hope it to get as many to upgrade with the newness hype
otherwise they will join the long tail and be difficult to move
later once they find it wasn't necessary.

brandon

DSLAMs

[Nick Edwards]

Howdy y'all

Chasing some info, does dlink still sell DAS4672 - 672 port adsl2+ dslams?

after simple IP based  units with pppoe pass through.
We could buy a bunch of planet 48 ports, which we used before, but we
hoping someone still puts out high capacity (320 plus port) units with
inbuilt pots splitters

thanks

Re: Paging anyone from ntpd.org

[Seth Mattinen]

On 12/31/19 1:32 AM, Harlan Stenn wrote:

On 12/30/2019 8:32 PM, Seth Mattinen wrote:

On 12/30/19 8:22 PM, Seth Mattinen wrote:

Is anyone from ntpd.org on here? You're pointing DNS at me for some
reason. That zone (ntpd.org) isn't in our system. Your NS looks odd
too, *.darkness-reigns.net and .nl? Is that legit? I don't know what
it was before because I've never looked, but that seems off.




nevermind, I'm tired and confused ntpd.org with ntp.org. Just going to
wildcard *.ntpd.org to 127.0.0.1 and go back to sleep.


I did think about replying, saying "Just to be clear, this isn't about
ntp.org."




What I did learn though there are a lot of people configuring their NTP 
with servers that are identical to the legitimate *.ntp.org names, 
except they're mistyping ntpd instead of ntp. Enough to generate >2Gbps 
worth of query traffic (pointed at a DNS server with a 1gbps interface).


I have to admit I'm kind of curious how many unique clients that would 
be if I answered back with a working IP address instead of localhost.

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Seth Mattinen]

On 12/31/19 12:50 AM, Ryan Hamel wrote:
Just let the old platforms ride off into the sunset as originally 
planned like the SSL implementations in older JRE installs, XP, etc. You 
shouldn't be holding onto the past.



Because poor people anywhere on earth that might not have access to the 
newer technology don't deserve access to Wikipedia, right? Gotta make 
sure information is only accessible to those with means to keep "lesser" 
people out.

Re: 5G roadblock: labor

[Mike Hammett]

Perhaps in some cases, but not in most. For example, I live in a brick house 
with a metal roof on a farm, near the edge of most mobile providers' cells for 
the respective towers. 

https://www.speedtest.net/result/a/5615500436 
https://www.speedtest.net/result/a/5615504363 
https://www.speedtest.net/result/a/5615508821 


Same spot in the house, same device, T-Mobile, Sprint, and US Cellular all 
delivered reasonable performance to the speedtest.net server of choice for that 
test. 




As I go further rural, the impact is mostly due to coverage, not a lack of 
capacity. Most 5G won't fix that, with the exception of T-Mobile, who is 
deploying 5G on a lower frequency. 


As I go further suburban and urban, the performances generally increases. 5G 
will likely be there first, but there generally isn't a performance issue in 
those situations. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: sro...@ronan-online.com 
To: "Mike Hammett"  
Cc: "Shane Ronan" , "Sabri Berisha" 
, "nanog"  
Sent: Tuesday, December 31, 2019 8:14:16 AM 
Subject: Re: 5G roadblock: labor 

I think you are overestimating the existing network in most cases. And I say 
this based on first hand experience at $dayjob MNO. 

Shane 

> On Dec 31, 2019, at 9:10 AM, Mike Hammett  wrote: 
> 
> devices. 

Re: 5G roadblock: labor

[Mike Hammett]

I would still find it hard to believe you would need that kind of speed, today, 
in any reasonable situation. Also, today's infrastructure can more than handle 
that in most places. Where it can't, 5G isn't going to be there for a very long 
time or some other method would fix it first (such as improved backhaul or site 
densification with existing technologies). 


I'm not saying what we have will work for us forever, but it will solve no 
current problems. There is no need to rush like the network is on fire. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Shane Ronan"  
To: "Mike Hammett"  
Cc: "Sabri Berisha" , "nanog"  
Sent: Tuesday, December 31, 2019 8:02:08 AM 
Subject: Re: 5G roadblock: labor 


Phones aren't the only devices supported by mobile networks. There are many 
other devices. My laptop for example has a 4G SIM card, as does my MiFi. 
Sometimes my phone needs to be used as a hotspot to support multiple devices. 


All of these are based on current use cases, ignoring use cases that will 
become available in the future based on the ability to support higher 
bandwidths. 


Shane 







On Tue, Dec 31, 2019, 8:56 AM Mike Hammett < na...@ics-il.net > wrote: 




I figured someone would bring that likely misquote out at some point. I say 
likely misquote because there is no evidence that he actually said it. 




Now... now very, very few have any "need" for 25 megabit/s via mobile service 
to their phone. You would be hard-pressed to find an actual need for more than 
5 megabit/s to a phone and yet in most areas, you can get well into 
double-digits on your phone with existing technology and infrastructure. Hell, 
I can often get over 100 megabit/s on my phone. Seems to work for me. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Sabri Berisha" < sa...@cluecentral.net > 
To: "Brian J. Murrell" < br...@interlinx.bc.ca > 
Cc: "nanog" < nanog@nanog.org > 
Sent: Monday, December 30, 2019 6:52:55 PM 
Subject: Re: 5G roadblock: labor 

- On Dec 30, 2019, at 12:54 PM, Brian J. Murrell br...@interlinx.bc.ca 
wrote: 

> Who needs 25mbits to their phone? 

Who needs more than 640Kb of memory? 

We don't know what the future holds. This is an interesting read, featuring 5g 
to perform a "hologram" phone call: 
https://www.bbc.com/news/business-45009458 

Thanks, 

Sabri 

Re: 5G roadblock: labor

[Mike Hammett]

I figured someone would bring that likely misquote out at some point. I say 
likely misquote because there is no evidence that he actually said it. 




Now... now very, very few have any "need" for 25 megabit/s via mobile service 
to their phone. You would be hard-pressed to find an actual need for more than 
5 megabit/s to a phone and yet in most areas, you can get well into 
double-digits on your phone with existing technology and infrastructure. Hell, 
I can often get over 100 megabit/s on my phone. Seems to work for me. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Sabri Berisha"  
To: "Brian J. Murrell"  
Cc: "nanog"  
Sent: Monday, December 30, 2019 6:52:55 PM 
Subject: Re: 5G roadblock: labor 

- On Dec 30, 2019, at 12:54 PM, Brian J. Murrell br...@interlinx.bc.ca 
wrote: 

> Who needs 25mbits to their phone? 

Who needs more than 640Kb of memory? 

We don't know what the future holds. This is an interesting read, featuring 5g 
to perform a "hologram" phone call: 
https://www.bbc.com/news/business-45009458 

Thanks, 

Sabri 

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Jared Mauch]

> On Dec 31, 2019, at 8:37 AM, Mike Hammett  wrote:
> 
> Silicon Valley is typically out of touch with reality.
> 


I think this is a bit over the top and troll-ish but there is a big thing going 
on in circles where transport integrity and secrecy are tied together when it’s 
not necessary.

Not all mutual authentication needs to be done with certificates (for example).

Forcing all of wikipedia to be https is an example of the side-effects of this 
practice when combined with deprecating older versions of TLS and older 
ciphers, you will inevitably make the content inaccessible as a result.  The 
thought that we should all upgrade our devices (that work just fine) is a bit 
of a problem. 

If I have an old tablet that my kids use to do wikipedia and are now locked 
out, that’s forcing an expense on the end-user of that tech and creates more 
e-waste etc than necessary.  I’m not a fan of that either, but the painting a 
broad brush is not helpful to the conversation.

- Jared

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Mike Hammett]

If you care that bad, you work towards meeting the requirement. If you don't 
care, then you don't. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "John Adams"  
To: "Matt Hoppes"  
Cc: "Constantine A. Murenin" , "North American Network 
Operators' Group"  
Sent: Tuesday, December 31, 2019 4:04:54 AM 
Subject: Re: Wikipedia drops support for old Android smartphones; mandates 
TLSv1.2 to read 

because no one should know what you read about or check out at wikipedia 

Sent from my iPhone 

> On Dec 31, 2019, at 00:30, Matt Hoppes  
> wrote: 
> 
> Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work 
> why not either let it fall back to 1.0 or to HTTP. 
> 
> This seems like security for no valid reason. 

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Mike Hammett]

Some don't have the fiscal or logistical ability to do better. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Ryan Hamel"  
To: "Constantine A. Murenin"  
Cc: "North American Network Operators' Group"  
Sent: Tuesday, December 31, 2019 2:50:55 AM 
Subject: Re: Wikipedia drops support for old Android smartphones; mandates 
TLSv1.2 to read 


Just let the old platforms ride off into the sunset as originally planned like 
the SSL implementations in older JRE installs, XP, etc. You shouldn't be 
holding onto the past. 


Ryan 


On Tue, Dec 31, 2019, 12:41 AM Constantine A. Murenin < muren...@gmail.com > 
wrote: 






On Tue, 31 Dec 2019 at 02:29, Matt Hoppes < mattli...@rivervalleyinternet.net > 
wrote: 



Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why 
not either let it fall back to 1.0 or to HTTP. 

This seems like security for no valid reason. 


Exactly. I used the wording from their own page; but I think it's actually 
misleading. They're actually going out of their way to prevent users of "old 
Android smartphones" from accessing Wikipedia; if they did nothing, everyone 
would still be able to read happily over HTTP. 


C. 

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Mike Hammett]

" the sheer amount of ppl left that have the older phones most likely are not 
going to Wikipedia anyway." 

Why? 





- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "J. Hellenthal via NANOG"  
To: "John Adams"  
Cc: "Constantine A. Murenin" , "North American Network 
Operators' Group"  
Sent: Tuesday, December 31, 2019 5:30:58 AM 
Subject: Re: Wikipedia drops support for old Android smartphones; mandates 
TLSv1.2 to read 

... because you should be able to verify the site you are at is actually the 
site you intended to be at... 

Let the old crap go. Besides the sheer amount of ppl left that have the older 
phones most likely are not going to Wikipedia anyway. 

-- 
J. Hellenthal 

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume. 

> On Dec 31, 2019, at 04:05, John Adams  wrote: 
> 
> because no one should know what you read about or check out at wikipedia 
> 
> Sent from my iPhone 
> 
>> On Dec 31, 2019, at 00:30, Matt Hoppes  
>> wrote: 
>> 
>> Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work 
>> why not either let it fall back to 1.0 or to HTTP. 
>> 
>> This seems like security for no valid reason. 

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Mike Hammett]

"obvious reasons" 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Antonios Chariton"  
To: "North American Network Operators' Group"  
Sent: Tuesday, December 31, 2019 3:47:58 AM 
Subject: Re: Wikipedia drops support for old Android smartphones; mandates 
TLSv1.2 to read 

Ignoring the obvious reasons why TLS is needed and HTTP should not be used, I 
guess people who want an HTTP version of Wikipedia that is read-only and 
knowingly insecure, censorable, modifiable, etc. can donate a few million 
dollars to the Wikimedia Foundation, before the tax year is over, for the 
engineers, infrastructure, and everything, and write a special note, and maybe 
Wikipedia may consider this.. Worst case, you just funded a secure encyclopedia 
and helped it grow in 2020 and years to come.. :) 



Let’s see those receipts coming! 




On 31 Dec 2019, at 09:50, Ryan Hamel < r...@rkhtech.org > wrote: 


Just let the old platforms ride off into the sunset as originally planned like 
the SSL implementations in older JRE installs, XP, etc. You shouldn't be 
holding onto the past. 


Ryan 


On Tue, Dec 31, 2019, 12:41 AM Constantine A. Murenin < muren...@gmail.com > 
wrote: 






On Tue, 31 Dec 2019 at 02:29, Matt Hoppes < mattli...@rivervalleyinternet.net > 
wrote: 



Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why 
not either let it fall back to 1.0 or to HTTP. 

This seems like security for no valid reason. 


Exactly. I used the wording from their own page; but I think it's actually 
misleading. They're actually going out of their way to prevent users of "old 
Android smartphones" from accessing Wikipedia; if they did nothing, everyone 
would still be able to read happily over HTTP. 


C. 

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Mike Hammett]

Silicon Valley is typically out of touch with reality. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Constantine A. Murenin"  
To: "North American Network Operators' Group"  
Sent: Tuesday, December 31, 2019 1:34:19 AM 
Subject: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 
to read 


Dear all, 

It came to my attention that anyone visiting en.wikipedia.org site from an "old 
Android smartphone", as Wikipedia puts it, will be redirected to 
https://en.wikipedia.org/sec-warning ( 
http://web.archive.org/web/20191217154700/https://en.wikipedia.org/sec-warning 
), which, amongst other things, reads the following: 

 

: 中文: 
维基百科正在使网站更加安全。您正在使用旧的浏览器，这在将来无法连接维基百科。请更新您的设备或联络您的IT管理员。以下提供更长，更具技术性的更新（仅英语）。 
: 
: We are removing support for insecure TLS protocol versions, specifically 
TLSv1.0 and TLSv1.1, which your browser software relies on to connect to our 
sites. This is usually caused by using some ancient browser or user agents like 
old Android smartphones. Also it could be interference from corporate or 
personal "Web Security" software which actually downgrades connection security. 
: You must upgrade your browser or otherwise fix this issue to access our 
sites. This message will remain until Jan 1, 2020. After that date, your 
browser will not be able to establish a connection to our servers at all. 
: See also the HTTPS Browser Recommendations page on Wikitech for more-detailed 
information. 

 

This is yet another assault on the less fortunate folk for absolutely no valid 
technical reason. Yet another assault on the free flow of information. 

Everyone should be able to access an encyclopaedia without any such 
restrictions; wasn't that the whole original premise behind Wikipedia in the 
first place? Why are they now precluding valid users from having access? What 
happened with the idea of following Postel's law? 
http://web.archive.org/web/20191212212040/https://en.wikipedia.org/wiki/Robustness_principle
 

If you have an old iPad device lying around, why should you be precluded from 
having access to an encyclopaedia? A Google search reveals that there's already 
iOS users receiving these messages, too. (BTW, Google Search itself still works 
fine over plain HTTP — FYI — as does Bing and Baidu, but not Yandex.) 

If anyone is aware of a tracking-free TLS-free mirror, LMK. I cannot link to 
Wikipedia in good conscience anymore knowing that they block folks left and 
right now. 

C. 

RE: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Keith Medcalf]

On Tuesday, 31 December, 2019 04:44, Constantine A. Murenin 
 wrote:

>Just to make it clear: are you suggesting that it should be a requirement
>to always verify the site where anonymous people make anonymous edits?
>Let that sink in.

TLS 1.2 as deployed in Web Browsers does not authenticate the end-point.  What 
it does is present an "Advertizing ID" that is akin to the "Advertizing ID" 
that the telco's sold as "Caller ID", because they new that y'all proles would 
not pay if there were truth in naming.  By the same token the general 
certificate system will "say" whatever he who pays wants it to say.  It does 
not verify anything other than the fact that the remote end-point went to the 
bother of buying (or the trouble of fiddling about with) advertizing 
certificates.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Keith Medcalf]

On Tuesday, 31 December, 2019 02:48, Antonios Chariton  
wrote:

>Ignoring the obvious reasons why TLS is needed and HTTP should not be
>used,

I am curious -- what exactly are those "obvious reasons"?  (And for the record 
HTTP *IS* being used, it is just being tunneled inside a TLS connection).

I certainly cannot fathom any "obvious reasons" ...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Constantine A. Murenin]

Just to make it clear: are you suggesting that it should be a requirement
to always verify the site where anonymous people make anonymous edits?  Let
that sink in.

C.

On Tue, 31 Dec 2019 at 05:31, J. Hellenthal  wrote:

> ... because you should be able to verify the site you are at is actually
> the site you intended to be at...
>
> Let the old crap go. Besides the sheer amount of ppl left that have the
> older phones most likely are not going to Wikipedia anyway.
>
> --
>  J. Hellenthal
>
> The fact that there's a highway to Hell but only a stairway to Heaven says
> a lot about anticipated traffic volume.
>
> > On Dec 31, 2019, at 04:05, John Adams  wrote:
> >
> > because no one should know what you read about or check out at wikipedia
> >
> > Sent from my iPhone
> >
> >> On Dec 31, 2019, at 00:30, Matt Hoppes <
> mattli...@rivervalleyinternet.net> wrote:
> >>
> >> Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t
> work why not either let it fall back to 1.0 or to HTTP.
> >>
> >> This seems like security for no valid reason.
>

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Constantine A. Murenin]

Well, that would be nothing, because they're blocking your device from
having any access.

C.

On Tue, 31 Dec 2019 at 04:04, John Adams  wrote:

> because no one should know what you read about or check out at wikipedia
>
> Sent from my iPhone
>
> > On Dec 31, 2019, at 00:30, Matt Hoppes <
> mattli...@rivervalleyinternet.net> wrote:
> >
> > Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t
> work why not either let it fall back to 1.0 or to HTTP.
> >
> > This seems like security for no valid reason.
>

Re: 5G roadblock: labor

[Etienne-Victor Depasquale]

I think that the argument about the need for basic research should be
orthogonal to individuals' vision of demand.

I would say that this holds true for applied research and development too.
I'd add that we tend to place too much importance on our individual visions.

On the other hand, applied research should be conditioned by the facility
of adoption of the presumed development in the market.



On Mon, Dec 30, 2019 at 3:41 PM  wrote:

> Ultimately this will come down to market demand.
>
> Having led two efforts in IEEE to develop a next speed of Ethernet - I have
> heard the argument about needing the next speed of Ethernet.  Ultimately,
> market demand showed that it was necessary and we had done the right thing
> developing the next speed.
>
> So given the cost of deployment - will the business case to deploy 5G
> happen?  Had lots of conversations with people on this.  Would like to
> better understand this as we start to look beyond 400GbE - as bandwidth
> related to 5G is frequently brought up.
>
> -Original Message-
> From: NANOG  On Behalf Of Matt Hoppes
> Sent: Monday, December 30, 2019 9:24 AM
> To: Mark Tinka 
> Cc: nanog@nanog.org
> Subject: Re: 5G roadblock: labor
>
> We saw this with Femtocells. Why build the network when the end user will
> build it with their broadband connection?
>
> With 5G - if I need fiber to the pole already and the pole has to be
> within.
> Few hundred feet of the end user, why not just deploy fiber to the home?
> Do I really need a gigabit per second on my mobile device?
>
>

-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[J. Hellenthal via NANOG]

... because you should be able to verify the site you are at is actually the 
site you intended to be at...

Let the old crap go. Besides the sheer amount of ppl left that have the older 
phones most likely are not going to Wikipedia anyway.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Dec 31, 2019, at 04:05, John Adams  wrote:
> 
> because no one should know what you read about or check out at wikipedia
> 
> Sent from my iPhone
> 
>> On Dec 31, 2019, at 00:30, Matt Hoppes  
>> wrote:
>> 
>> Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t work 
>> why not either let it fall back to 1.0 or to HTTP. 
>> 
>> This seems like security for no valid reason.


smime.p7s
Description: S/MIME cryptographic signature

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[John Adams]

because no one should know what you read about or check out at wikipedia

Sent from my iPhone

> On Dec 31, 2019, at 00:30, Matt Hoppes  
> wrote:
> 
> Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t work 
> why not either let it fall back to 1.0 or to HTTP. 
> 
> This seems like security for no valid reason.

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Antonios Chariton]

Ignoring the obvious reasons why TLS is needed and HTTP should not be used, I 
guess people who want an HTTP version of Wikipedia that is read-only and 
knowingly insecure, censorable, modifiable, etc. can donate a few million 
dollars to the Wikimedia Foundation, before the tax year is over, for the 
engineers, infrastructure, and everything, and write a special note, and maybe 
Wikipedia may consider this.. Worst case, you just funded a secure encyclopedia 
and helped it grow in 2020 and years to come.. :)

Let’s see those receipts coming!

> On 31 Dec 2019, at 09:50, Ryan Hamel  wrote:
> 
> Just let the old platforms ride off into the sunset as originally planned 
> like the SSL implementations in older JRE installs, XP, etc. You shouldn't be 
> holding onto the past.
> 
> Ryan
> 
> On Tue, Dec 31, 2019, 12:41 AM Constantine A. Murenin  > wrote:
> On Tue, 31 Dec 2019 at 02:29, Matt Hoppes  > wrote:
> Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t work 
> why not either let it fall back to 1.0 or to HTTP. 
> 
> This seems like security for no valid reason.
> 
> Exactly.  I used the wording from their own page; but I think it's actually 
> misleading.  They're actually going out of their way to prevent users of "old 
> Android smartphones" from accessing Wikipedia; if they did nothing, everyone 
> would still be able to read happily over HTTP.
> 
> C.

Re: Paging anyone from ntpd.org

[Harlan Stenn]

On 12/30/2019 8:32 PM, Seth Mattinen wrote:
> On 12/30/19 8:22 PM, Seth Mattinen wrote:
>> Is anyone from ntpd.org on here? You're pointing DNS at me for some
>> reason. That zone (ntpd.org) isn't in our system. Your NS looks odd
>> too, *.darkness-reigns.net and .nl? Is that legit? I don't know what
>> it was before because I've never looked, but that seems off.
>>
>>
> 
> nevermind, I'm tired and confused ntpd.org with ntp.org. Just going to
> wildcard *.ntpd.org to 127.0.0.1 and go back to sleep.

I did think about replying, saying "Just to be clear, this isn't about
ntp.org."

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Ryan Hamel]

Just let the old platforms ride off into the sunset as originally planned
like the SSL implementations in older JRE installs, XP, etc. You shouldn't
be holding onto the past.

Ryan

On Tue, Dec 31, 2019, 12:41 AM Constantine A. Murenin 
wrote:

> On Tue, 31 Dec 2019 at 02:29, Matt Hoppes <
> mattli...@rivervalleyinternet.net> wrote:
>
>> Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t
>> work why not either let it fall back to 1.0 or to HTTP.
>>
>> This seems like security for no valid reason.
>
>
> Exactly.  I used the wording from their own page; but I think it's
> actually misleading.  They're actually going out of their way to prevent
> users of "old Android smartphones" from accessing Wikipedia; if they did
> nothing, everyone would still be able to read happily over HTTP.
>
> C.
>

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Constantine A. Murenin]

On Tue, 31 Dec 2019 at 02:29, Matt Hoppes 
wrote:

> Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t
> work why not either let it fall back to 1.0 or to HTTP.
>
> This seems like security for no valid reason.


Exactly.  I used the wording from their own page; but I think it's actually
misleading.  They're actually going out of their way to prevent users of
"old Android smartphones" from accessing Wikipedia; if they did nothing,
everyone would still be able to read happily over HTTP.

C.

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Matt Hoppes]

Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t work why 
not either let it fall back to 1.0 or to HTTP. 

This seems like security for no valid reason.