Got a question for the geniuses!

I have two DECnet areas, area 1 and area 2. I have a VAX/VMS system running the LAT server on area 2, but I have a DECserver 200 on area 1.

Two DECnet routers on either end, nodes 2.1 and 1.1.

Is there a way to get the DECserver 200 to recognize the VAX on 2.2 so I can log into it using the DECserver? Is that supposed to happen automagically since the routers are there, or do I have to do something special? Or is it not possible?

Andy

Andy Green schrieb am Samstag, 22. Juli 2023 um 14:28:09 UTC+2:

> Is there a way to get the DECserver 200 to recognize the VAX on 2.2 so I can log into it using the DECserver? Is that supposed to happen automagically since the routers are there, or do I have to do something special? Or is it not possible?

Andy,

LAT is the abbreviation of 'Local Area Transport' and only works on the local LAN. It has nothing to do with DECnet and is not aware of DECnet routing etc. The LAT protocol does node discovery via a multicast protocol on the LAN and connects via the MAC address of the LAT service node, once it has learned about the 'LAT Service' based on the LAT multicast announcements.

So: not possible.

Volker.

PS: Except of your 2 areas are on the same LAN - which would be unusual, but possible.

Aaaah, ok - thanks for the clarification! I did have to configure a DECnet node number for the DS in the dsvconfig utility so I just assumed it was able to speak DECnet and work cross-area!

Thanks for the help, regardless!

Andy

On Saturday, July 22, 2023 at 9:06:03 AM UTC-4, Volker Halle wrote:
> Andy Green schrieb am Samstag, 22. Juli 2023 um 14:28:09 UTC+2:
>
> > Is there a way to get the DECserver 200 to recognize the VAX on 2.2 so I can log into it using the DECserver? Is that supposed to happen automagically since the routers are there, or do I have to do something special? Or is it not possible?
> Andy,
>
> LAT is the abbreviation of 'Local Area Transport' and only works on the local LAN. It has nothing to do with DECnet and is not aware of DECnet routing etc. The LAT protocol does node discovery via a multicast protocol on the LAN and connects via the MAC address of the LAT service node, once it has learned about the 'LAT Service' based on the LAT multicast announcements.
>
> So: not possible.
>
> Volker.
>
> PS: Except of your 2 areas are on the same LAN - which would be unusual, but possible.

On 7/22/2023 9:06 AM, Volker Halle wrote:
> Andy Green schrieb am Samstag, 22. Juli 2023 um 14:28:09 UTC+2:
>> Is there a way to get the DECserver 200 to recognize the VAX on 2.2
>> so I can log into it using the DECserver? Is that supposed to
>> happen automagically since the routers are there, or do I have to
>> do something special? Or is it not possible?
>
> LAT is the abbreviation of 'Local Area Transport' and only works on
> the local LAN. It has nothing to do with DECnet and is not aware of
> DECnet routing etc. The LAT protocol does node discovery via a
> multicast protocol on the LAN and connects via the MAC address of the
> LAT service node, once it has learned about the 'LAT Service' based
> on the LAT multicast announcements.

> PS: Except of your 2 areas are on the same LAN - which would be
> unusual, but possible.

Non-routed bridged-only long distance net would work around
the non-routable characteristics of LAT.

But my experience with LAT (30-35 years ago) is that it is also
where latency sensitive. Excessive delays results in timeout errors.

Arne

> Non-routed bridged-only long distance net would work around
> the non-routable characteristics of LAT.

A while ago, my then-employer leased a 9600b/s line which provided a
bridge between offices in Minnesota and California. In the Saint Paul
office, we could always tell when the power failed in Menlo Park because
when their power was restored, their DECservers would boot off our
MOP-serving VAXes, and we'd see the console messages. Our already-up
VAXes responded sooner than their still-starting VAXes.

I don't recall anyone trying to do any serious work using LAT over
the bridge, but it worked well enough for a little playing around, and
everyone's DECservers were happy.

Andy Green <agreen0868@gmail.com> wrote:
>Is there a way to get the DECserver 200 to recognize the VAX on 2.2 so I can log into it using the DECserver? Is that supposed to happen automagically since the routers are there, or do I have to do something special? Or is it not possible?

LAT is not decnet. Vaxcluster isn't decnet either. LAT is its own protocol,
and it's one that doesn't route. You might be able to write some sort of
LAT bridge but I have never seen one in place before because really the L
in LAT is for Local.

BUT.... if you're okay with telnet, I probably have some Lantronix terminal
servers sitting in the junk bin here.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 7/22/2023 7:07 PM, Scott Dorsey wrote:
> Andy Green <agreen0868@gmail.com> wrote:
>> Is there a way to get the DECserver 200 to recognize the VAX on 2.2 so I can log into it using the DECserver? Is that supposed to happen automagically since the routers are there, or do I have to do something special? Or is it not possible?
>
> LAT is not decnet. Vaxcluster isn't decnet either. LAT is its own protocol,
> and it's one that doesn't route. You might be able to write some sort of
> LAT bridge but I have never seen one in place before because really the L
> in LAT is for Local.

In the olden days, a terminal server needed a DECnet address in order to be MOP
downline-loaded.

That is, when an unsolicited MOP request would come in, Phase IV DECnet would
search its volatile database looking for a MAC address match with the incoming
request.

If a match was found, and there was a file defined with which that node node
could be loaded, then that node would attempt to fulfill the MOP request.

Later on, the advent of LANCP allowed MOP clients to be defined that had no
relationship with DECnet.

I am less familiar with how Phase V sorts out MOP stuff; mercifully, I've never
had to debug the Phase V MOP implementation.

Neither the DECnet nor LAT protocols have anything to do with how a terminal
server is loaded via MOP.

--

--- Rob

On 7/22/2023 7:07 PM, Scott Dorsey wrote:
> LAT is not decnet. Vaxcluster isn't decnet either. LAT is its own protocol,

Yes.

0800 IPv4
0806 ARP
6001 MOP load
6003 DECnet
6004 LAT
6007 SCA/LAVC

Arne

On 2023-07-22 23:53:18 +0000, Robert A. Brooks said:

> In the olden days, a terminal server needed a DECnet address in order
> to be MOP downline-loaded.
>
> That is, when an unsolicited MOP request would come in, Phase IV DECnet
> would search its volatile database looking for a MAC address match with
> the incoming request.
>
> If a match was found, and there was a file defined with which that node
> node could be loaded, then that node would attempt to fulfill the MOP
> request.

Sort of.

With the DECnet Phase IV design with DECnet and MOP comingled, the
DECnet address was "merely" the storage address for a database entry
within an RMS file containing a few boot-related strings.

That MOP implementation "borrowed" persistent storage from DECnet.

And that wad of storage needed an address within the existing DECnet
database containing DECnet addresses and host names and related details.

When the MOP boot request arrived, each MOP server listening on the
segment scanned its own local database for a matching MAC address,
using that MAC to locate the boot-related data, and—if a MAC match was
found—served up the boot response.

> Later on, the advent of LANCP allowed MOP clients to be defined that
> had no relationship with DECnet.

At OpenVMS V6.2, as part of the work migrating DECnet Phase IV from an
integrated to an optional and separately-installed component of OpenVMS.

> I am less familiar with how Phase V sorts out MOP stuff; mercifully,
> I've never had to debug the Phase V MOP implementation.

A common recommendation back then was to move MOP processing from
either DECnet to LANCP.

> Neither the DECnet nor LAT protocols have anything to do with how a
> terminal server is loaded via MOP.

Ayup. Or how an OpenVMS system is loaded via MOP, for that matter.

Apropros of nothing, LAT uses Ethernet 60-04. MOP uses 60-01, and
60-02. 60-06 is reserved for customer fun and games. Probably also
60-00, 60-08, and 60-09 now, too.

And apropos of a different MOP-related implementation:
https://blogs.cisco.com/security/router-spring-cleaning-no-mop-required-again

--
Pure Personal Opinion | HoffmanLabs LLC

On 7/22/2023 8:18 PM, Arne Vajhøj wrote:
> On 7/22/2023 7:07 PM, Scott Dorsey wrote:
>> LAT is not decnet. Vaxcluster isn't decnet either. LAT is its own protocol,
>
> Yes.
>
> 0800 IPv4
> 0806 ARP
> 6001 MOP load
> 6003 DECnet
> 6004 LAT
> 6007 SCA/LAVC
>
> Arne
>
>

Just out of curiosity, what do the 4 digit numbers signify?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 7/22/2023 9:07 PM, Dave Froble wrote:
> On 7/22/2023 8:18 PM, Arne Vajhøj wrote:
>> On 7/22/2023 7:07 PM, Scott Dorsey wrote:
>>> LAT is not decnet.  Vaxcluster isn't decnet either.  LAT is its own
>>> protocol,
>>
>> Yes.
>>
>> 0800 IPv4
>> 0806 ARP
>> 6001 MOP load
>> 6003 DECnet
>> 6004 LAT
>> 6007 SCA/LAVC
>
> Just out of curiosity, what do the 4 digit numbers signify?

The ethernet protocol. 2 bytes in the ethernet header specifying what
the ethernet packet payload contains.

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>On 7/22/2023 7:07 PM, Scott Dorsey wrote:
>> LAT is not decnet. Vaxcluster isn't decnet either. LAT is its own protocol,
>
>Yes.
>0800 IPv4
>0806 ARP
>6001 MOP load
>6003 DECnet
>6004 LAT
>6007 SCA/LAVC

This is culturally very different than modern systems where everything is
running IP and only what is on top of TCP or UDP is different. In the
early era of Ethernet, all kinds of different packet types could be found
over the same Ethernet segment. How they travelled from segment to segment
(or didn't) varied depending on the environment and the protocol. It was
not unusual to find multiple buildings networked together with IP routers
but which also had Appletalk routers running in parallel with the IP routers
to carry Appletalk traffic as well as IP traffic.

The way described with VMS is more efficient and has much less overhead than
encapsulating everything into IP, but it doesn't scale very well because of
the routing difficulties. Back in the eighties we saw giant bridged networks
of a thousand or more nodes and it became pretty clear this was a bad idea.
But if you route instead of bridge, you need to route all the different kinds
of protocols....
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Scott Dorsey wrote:

> This is culturally very different than modern systems where everything
> is running IP and only what is on top of TCP or UDP is different.

We're pretty close to the next stage where everything is running on top
of HTTPS, aren't we?

Andy Burns <usenet@andyburns.uk> wrote:
>Scott Dorsey wrote:
>
>> This is culturally very different than modern systems where everything
>> is running IP and only what is on top of TCP or UDP is different.
>
>We're pretty close to the next stage where everything is running on top
>of HTTPS, aren't we?

Please don't remind me. It's a horrible idea to contemplate, isn't it?
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Saturday, July 22, 2023 at 7:53:21 PM UTC-4, Robert A. Brooks wrote:
> In the olden days, a terminal server needed a DECnet address in order to be MOP
> downline-loaded.

The DECnet address is also used for OPCOM messages which are
emitted in the standard Phase IV format.

DECservers can specify a an image file they want, or they can expect
the load host to send them the right image based on their Ethernet
address. Some can go either way, some insist on one or the other.
"Serve image based on MAC address" was added for the DECserver
500/550 because the configuration is bundled into the load image as
the 11/53 processors in those systems only had a few dozen bytes
of available non-volatile memory - nowhere near enough to store the
config.

30+ years ago (Yikes!) Digital Canada paid me to write a MOP imple-
mentation for RSTS/E. Since the system programming language on
RSTS/E is Basic-Plus 2, that's what it is written in (except for a tiny
piece of Macro-11 needed to enable multicast reception). It is com-
pletely standalone. As long as the RSTS/E version supports Ethernet,
it will work. Doesn't need a DECnet license or anything like that. It
faithfully minics the OPCOM messages on VAX/VMS:

Event type 0.3, Automatic line service
Occurred 06-Jul-90 02:48 AM on node 3.4 (SPC11D)
Circuit UNA-0, Load, Successful, Node = 2.6 (LT2006)
File = PR0801ENG.SYS, Operating system
Ethernet address = 08-00-2B-0A-FD-30

I did get a "bug" report. A customer tried it on a LAN that also had a
VAX 8978. The poor little 11/23+ with its MOP written in BP2 was
answering before the big, bad VAX. I had to add a delay option to the
configuration file so the RSTS/E system would wait a second or so
before servicing the request, to give the VAX time to get around to
it.

I threw in an implementation of "NCP CONNECT NODE" for free, too.

You can find it at https://www.glaver.org/ftp/tmk-software/mop-server
Give that server a little time to respond - it is hauling a virtual Alpha
out of the freezer to serve those files.

I also wrote a DECserver 5x0 configuration utility for RSTS/E. That
isn't available, though, as the way the config was stored in the image
was covered under NDA.

Op 23.jul..2023 om 02:18 schreef Arne Vajhøj:
> On 7/22/2023 7:07 PM, Scott Dorsey wrote:
>> LAT is not decnet.  Vaxcluster isn't decnet either.  LAT is its own
>> protocol,
>
> Yes.
>
> 0800 IPv4
> 0806 ARP
> 6001 MOP load
> 6003 DECnet
> 6004 LAT
> 6007 SCA/LAVC
>
> Arne
>
>

86DD IPv6

For a complete list see https://en.wikipedia.org/wiki/EtherType

On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
> Andy Burns <usenet@andyburns.uk> wrote:
>>Scott Dorsey wrote:
>>
>>> This is culturally very different than modern systems where everything
>>> is running IP and only what is on top of TCP or UDP is different.
>>
>>We're pretty close to the next stage where everything is running on top
>>of HTTPS, aren't we?
>

Good.

> Please don't remind me. It's a horrible idea to contemplate, isn't it?

From a security point of view, it (or something similar) is a really
good idea.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-07-22 20:41, Arne Vajhøj wrote:
> Non-routed bridged-only long distance net would work around
> the non-routable characteristics of LAT.
>
> But my experience with LAT (30-35 years ago) is that it is also
> where latency sensitive. Excessive delays results in timeout errors.

Been using bridge to run LAT across the whole world, carried over UDP.
Works just fine everywhere I've tried.

The internet is sooo fast these days that LAT timeouts are close to
eternity in comparison.

Johnny

On 2023-07-23 01:07, Scott Dorsey wrote:
> Andy Green <agreen0868@gmail.com> wrote:
>> Is there a way to get the DECserver 200 to recognize the VAX on 2.2 so I can log into it using the DECserver? Is that supposed to happen automagically since the routers are there, or do I have to do something special? Or is it not possible?
>
> LAT is not decnet. Vaxcluster isn't decnet either. LAT is its own protocol,
> and it's one that doesn't route. You might be able to write some sort of
> LAT bridge but I have never seen one in place before because really the L
> in LAT is for Local.

The bridge program I wrote about 20 years ago do bridge LAT. It can be
found in various places if you google for it. It also bridges MOP if you
want, so you can get your DECservers booted.
All done with UDP as the carrier.

Johnny

On 2023-07-23 01:53, Robert A. Brooks wrote:
> On 7/22/2023 7:07 PM, Scott Dorsey wrote:
>> Andy Green  <agreen0868@gmail.com> wrote:
>>> Is there a way to get the DECserver 200 to recognize the VAX on 2.2
>>> so I can log into it using the DECserver?  Is that supposed to happen
>>> automagically since the routers are there, or do I have to do
>>> something special?  Or is it not possible?
>>
>> LAT is not decnet.  Vaxcluster isn't decnet either.  LAT is its own
>> protocol,
>> and it's one that doesn't route.  You might be able to write some sort of
>> LAT bridge but I have never seen one in place before because really the L
>> in LAT is for Local.
>
> In the olden days, a terminal server needed a DECnet address in order to
> be MOP downline-loaded.

Umm. In VMS maybe. Not in RSX.

You can boot anything unknown via MOP from RSX, as long as you have the
required image on the system in the right directory.

Johnny

On 2023-07-24 05:54, terry-...@glaver.org wrote:
> On Saturday, July 22, 2023 at 7:53:21 PM UTC-4, Robert A. Brooks wrote:
>> In the olden days, a terminal server needed a DECnet address in order to be MOP
>> downline-loaded.
>
> The DECnet address is also used for OPCOM messages which are
> emitted in the standard Phase IV format.
>
> DECservers can specify a an image file they want, or they can expect
> the load host to send them the right image based on their Ethernet
> address. Some can go either way, some insist on one or the other.
> "Serve image based on MAC address" was added for the DECserver
> 500/550 because the configuration is bundled into the load image as
> the 11/53 processors in those systems only had a few dozen bytes
> of available non-volatile memory - nowhere near enough to store the
> config.
>
> 30+ years ago (Yikes!) Digital Canada paid me to write a MOP imple-
> mentation for RSTS/E. Since the system programming language on
> RSTS/E is Basic-Plus 2, that's what it is written in (except for a tiny
> piece of Macro-11 needed to enable multicast reception). It is com-
> pletely standalone. As long as the RSTS/E version supports Ethernet,
> it will work. Doesn't need a DECnet license or anything like that. It
> faithfully minics the OPCOM messages on VAX/VMS:
>
> Event type 0.3, Automatic line service
> Occurred 06-Jul-90 02:48 AM on node 3.4 (SPC11D)
> Circuit UNA-0, Load, Successful, Node = 2.6 (LT2006)
> File = PR0801ENG.SYS, Operating system
> Ethernet address = 08-00-2B-0A-FD-30

In RSX, it is reported like this:

01:21:24 Event type 0.3, Automatic service
Occurred 18-OCT-05 01:21:24 on node 1.15 (PONDUS)
Circuit QNA-0
Service type = Load
Status = Requested
File = DU0:[5,54]PR0801ENG, Software type = System
Source ethernet address = 08002B068B3D
01:21:28 Event type 0.3, Automatic service
Occurred 18-OCT-05 01:21:28 on node 1.15 (PONDUS)
Circuit QNA-0
Service type = Load
Status = Successful
File = DU0:[5,54]PR0801ENG, Software type = System
Source ethernet address = 08002B068B3D

So, no DECnet address. Just the MAC address of the host requesting the
boot image.

But you can also register a DECnet node for the whole thing, and I
suspect with a DECserver 500, you would have to.

> I did get a "bug" report. A customer tried it on a LAN that also had a
> VAX 8978. The poor little 11/23+ with its MOP written in BP2 was
> answering before the big, bad VAX. I had to add a delay option to the
> configuration file so the RSTS/E system would wait a second or so
> before servicing the request, to give the VAX time to get around to
> it.

Ah yes. Same "problem" with RSX. It is way faster than VMS was/is at
responding.

> I threw in an implementation of "NCP CONNECT NODE" for free, too.
>
> You can find it at https://www.glaver.org/ftp/tmk-software/mop-server
> Give that server a little time to respond - it is hauling a virtual Alpha
> out of the freezer to serve those files.

That is really cool. Something to spread to the RSTS/E managers on HECnet...

Johnny

On 2023-07-23 13:03, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>> On 7/22/2023 7:07 PM, Scott Dorsey wrote:
>>> LAT is not decnet. Vaxcluster isn't decnet either. LAT is its own protocol,
>>
>> Yes.
>> 0800 IPv4
>> 0806 ARP
>> 6001 MOP load
>> 6003 DECnet
>> 6004 LAT
>> 6007 SCA/LAVC
>
> This is culturally very different than modern systems where everything is
> running IP and only what is on top of TCP or UDP is different. In the
> early era of Ethernet, all kinds of different packet types could be found
> over the same Ethernet segment. How they travelled from segment to segment
> (or didn't) varied depending on the environment and the protocol. It was
> not unusual to find multiple buildings networked together with IP routers
> but which also had Appletalk routers running in parallel with the IP routers
> to carry Appletalk traffic as well as IP traffic.

Well. Not entirely true, but sortof. You still have (obviously) both ARP
and IP (v4). But you also have things like RARP, IPv6, various VLAN
stuff, MPLS, PTP, RDMA, and some other stuff.

So it's not like "it's all just IP".

Johnny

On 2023-07-24 14:56, Simon Clubley wrote:
> On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
>> Andy Burns <usenet@andyburns.uk> wrote:
>>> Scott Dorsey wrote:
>>>
>>>> This is culturally very different than modern systems where everything
>>>> is running IP and only what is on top of TCP or UDP is different.
>>>
>>> We're pretty close to the next stage where everything is running on top
>>> of HTTPS, aren't we?
>>
>
> Good.

Not.

>> Please don't remind me. It's a horrible idea to contemplate, isn't it?
>
> From a security point of view, it (or something similar) is a really
> good idea.

Have you ever heard of "all eggs in one basket"? It's generally not a
good idea. When a security issue appears, *everything* is then
voulnerable. Having multiple solutions, implementations and technologies
carries a cost, but it also reduces risks in one way. Yes, you might
have a higher chance of having an exploit, but the consequences are much
less damaging. And you will always have exploits. And thus, any argument
about the number of exploits have to acknowledge that first of all,
there will be exlpoits. So, talking about limiting the damages is the
more reasonable/interesting thing to do.

Not to mention the overhead of running it all over http. I know that
there have even been implementations of IP over http...

It's turtles all the way down.

Johnny

On 7/24/2023 9:58 AM, Johnny Billquist wrote:
> On 2023-07-24 14:56, Simon Clubley wrote:
>> On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
>>> Andy Burns <usenet@andyburns.uk> wrote:
>>>> Scott Dorsey wrote:
>>>>
>>>>> This is culturally very different than modern systems where everything
>>>>> is running IP and only what is on top of TCP or UDP is different.
>>>>
>>>> We're pretty close to the next stage where everything is running on top
>>>> of HTTPS, aren't we?
>>>
>>
>> Good.
>
> Not.
>
>>> Please don't remind me. It's a horrible idea to contemplate, isn't it?
>>
>> From a security point of view, it (or something similar) is a really
>> good idea.
>
> Have you ever heard of "all eggs in one basket"? It's generally not a good idea.
> When a security issue appears, *everything* is then voulnerable. Having multiple
> solutions, implementations and technologies carries a cost, but it also reduces
> risks in one way. Yes, you might have a higher chance of having an exploit, but
> the consequences are much less damaging. And you will always have exploits. And
> thus, any argument about the number of exploits have to acknowledge that first
> of all, there will be exlpoits. So, talking about limiting the damages is the
> more reasonable/interesting thing to do.
>
> Not to mention the overhead of running it all over http. I know that there have
> even been implementations of IP over http...
>
> It's turtles all the way down.
>
> Johnny
>

Ok, you people are confusing me. (Not hard to do these days.)

Is it being claimed that there are implementations of HTTP/HTTPS that do not use
sockets?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Monday, July 24, 2023 at 9:58:52 AM UTC-4, Johnny Billquist wrote:
> Have you ever heard of "all eggs in one basket"? It's generally not a
> good idea. When a security issue appears, *everything* is then
> voulnerable. Having multiple solutions, implementations and technologies
> carries a cost, but it also reduces risks in one way. Yes, you might
> have a higher chance of having an exploit, but the consequences are much
> less damaging. And you will always have exploits. And thus, any argument
> about the number of exploits have to acknowledge that first of all,
> there will be exlpoits. So, talking about limiting the damages is the
> more reasonable/interesting thing to do.
>
> Not to mention the overhead of running it all over http. I know that
> there have even been implementations of IP over http...

And of course there are "standards" bodies that decree that certain
things are now forbidden, or behave differently and unpredictably.
From my blog article "Is no crypto always better than bad crypto?",
found here: https://www.glaver.org/blog/?p=853 I'll give one example:
"A certificate issued on December 31st, 2015 at 23:59:59 is treated
differently than one issued one second later on January 1st, 2016 at
00:00:00."

We can't forget that certificate lifetimes have become shorter and
shorter - you can't buy a SSL certificate with a longer expiration date
than 1 year + any time remaining on the existing certificate. I think the
only reason they haven't shortened it further is that once they get it
down to 180 days, there's pretty much no reason not to use Lets
Encrypt unless you're a bank or similar institution. I think the SSL
certificate vendors would complain that their customer base would
leave if they did that.

If Microsoft can forget to renew their SSL certificate:
https://www.theregister.com/2022/06/10/microsoft_insider_certificate
most people using SSL will commit the same blunder at least once.

> It's turtles all the way down.

I was thinking of another word that starts with "tur" and ends in "s".