Discussion:
An alternative history of computing
(too old to reply)
Simon Clubley
2021-07-14 17:40:36 UTC
Permalink
https://www.theregister.com/2021/07/14/alternative_history_computer_revolution/

DEC is mentioned (and keep reading to the end.)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Rich Alderson
2021-07-15 20:47:34 UTC
Permalink
Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:

> https://www.theregister.com/2021/07/14/alternative_history_computer_revolution/
>
> DEC is mentioned (and keep reading to the end.)
>
> Simon.

An amusing bit of fantasy, as are the comments.

--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
k***@gmail.com
2021-07-16 22:22:19 UTC
Permalink
>-----Original Message-----
>From: Info-vax <info-vax-***@rbnsn.com> On Behalf Of Rich Alderson
>via Info-vax
>Sent: July-15-21 5:48 PM
>To: info-***@rbnsn.com
>Cc: Rich Alderson <***@alderson.users.panix.com>
>Subject: Re: [Info-vax] An alternative history of computing
>
>Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>>
>https://www.theregister.com/2021/07/14/alternative_history_computer_rev
>olution/
>>
>> DEC is mentioned (and keep reading to the end.)
>>
>> Simon.
>
>An amusing bit of fantasy, as are the comments.
>
>--
>Rich Alderson
>***@alderson.users.panix.com
> Audendum est, et veritas investiganda; quam etiamsi non assequamur,
> omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
> --
>Galen

Back in the peak days of DEC and shortly before black Tues when DEC stock dropped by approx. 50% in less than 2 weeks, there was a rumour internally at DEC that stated the BOD was considering buying some small networking company called ..... Cisco.

With stock drop, idea was also dropped, but under an alternative universe .....

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com






--
This email has been checked for viruses by AVG.
https://www.avg.com
Rich Alderson
2021-07-20 03:27:38 UTC
Permalink
<***@gmail.com> writes:

G> >-----Original Message-----
> >From: Info-vax <info-vax-***@rbnsn.com> On Behalf Of Rich Alderson
> >via Info-vax
> >Sent: July-15-21 5:48 PM
> >To: info-***@rbnsn.com
> >Cc: Rich Alderson <***@alderson.users.panix.com>
> >Subject: Re: [Info-vax] An alternative history of computing
> >
> >Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
> >
> >>
> >https://www.theregister.com/2021/07/14/alternative_history_computer_rev
> >olution/
> >>
> >> DEC is mentioned (and keep reading to the end.)
> >>
> >> Simon.
> >
> >An amusing bit of fantasy, as are the comments.
> >
> >--
> >Rich Alderson
> >***@alderson.users.panix.com
> > Audendum est, et veritas investiganda; quam etiamsi non assequamur,
> > omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
> > --
> >Galen
>
> Back in the peak days of DEC and shortly before black Tues when DEC stock d=
> ropped by approx. 50% in less than 2 weeks, there was a rumour internally a=
> t DEC that stated the BOD was considering buying some small networking comp=
> any called ..... Cisco.

I sincerely doubt that Len and Sandy would have considered an offer from
Digital, given the original business plan of Cisco Systems, which was to build
Len's TOAD (which stands for "Ten On A Desk"). Digital had already canceled the
36-bit line by then.

Cisco was not internally a networking company until 1990, when the BoD decided
that the original business plan was not where they wanted to put their money.
Len and Sandy departed quickly.

> With stock drop, idea was also dropped, but under an alternative universe .=
> =2E...
>
> =F0=9F=98=8A
>
>
> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com

--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
k***@gmail.com
2021-07-21 21:59:58 UTC
Permalink
>-----Original Message-----
>From: Info-vax <info-vax-***@rbnsn.com> On Behalf Of Rich Alderson
>via Info-vax
>Sent: July-20-21 12:28 AM
>To: info-***@rbnsn.com
>Cc: Rich Alderson <***@alderson.users.panix.com>
>Subject: Re: [Info-vax] An alternative history of computing
>
><***@gmail.com> writes:
>
>G> >-----Original Message-----
>> >From: Info-vax <info-vax-***@rbnsn.com> On Behalf Of Rich
>> >Alderson via Info-vax
>> >Sent: July-15-21 5:48 PM
>> >To: info-***@rbnsn.com
>> >Cc: Rich Alderson <***@alderson.users.panix.com>
>> >Subject: Re: [Info-vax] An alternative history of computing
>> >
>> >Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>> >
>> >>
>>
>>https://www.theregister.com/2021/07/14/alternative_history_computer_r
>> >ev
>> >olution/
>> >>
>> >> DEC is mentioned (and keep reading to the end.)
>> >>
>> >> Simon.
>> >
>> >An amusing bit of fantasy, as are the comments.
>> >
>> >--
>> >Rich Alderson
>> >***@alderson.users.panix.com
>> > Audendum est, et veritas investiganda; quam etiamsi non
assequamur,
>> > omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
>> > --
>> >Galen
>>
>> Back in the peak days of DEC and shortly before black Tues when DEC
>> stock d= ropped by approx. 50% in less than 2 weeks, there was a
>> rumour internally a= t DEC that stated the BOD was considering buying
>> some small networking comp= any called ..... Cisco.
>
>I sincerely doubt that Len and Sandy would have considered an offer from
>Digital, given the original business plan of Cisco Systems, which was to
build
>Len's TOAD (which stands for "Ten On A Desk"). Digital had already
canceled
>the 36-bit line by then.
>
>Cisco was not internally a networking company until 1990, when the BoD
>decided that the original business plan was not where they wanted to put
>their money.
>Len and Sandy departed quickly.
>
>> With stock drop, idea was also dropped, but under an alternative
>> universe .= =2E...
>>
>> =F0=9F=98=8A
>>
>>
>> Regards,
>>
>> Kerry Main
>> Kerry dot main at starkgaming dot com
>
>--
>Rich Alderson
>***@alderson.users.panix.com
> Audendum est, et veritas investiganda; quam etiamsi non assequamur,
> omnino tamen proprius, quam nunc sumus, ad eam perveniemus.


Minor correction to my original reply - " black Tues" crash should have
stated " black Mon" (crash of 1987).

Re: when did Cisco become a networking company?

See following link: (Wiki .. yes, I know ..)
<https://en.wikipedia.org/wiki/Cisco_Systems>

(kind of grey area between Stanford and Cisco, but early innovations were
focussed on networking, so even though not a company until 1990, not sure
what might have been informally happening behind the scenes at DEC in 1987)


Regards,

Kerry Main
Kerry dot main at starkgaming dot com




--
This email has been checked for viruses by AVG.
https://www.avg.com
gah4
2021-07-16 23:12:26 UTC
Permalink
On Wednesday, July 14, 2021 at 10:40:38 AM UTC-7, Simon Clubley wrote:
> https://www.theregister.com/2021/07/14/alternative_history_computer_revolution/
>
> DEC is mentioned (and keep reading to the end.)

So, was there an Ethernet card for the Apple II?
Galen
2021-07-17 16:00:24 UTC
Permalink
> So, was there an Ethernet card for the Apple II?

I don’t know specifically about the Apple II family, but there was an AppleTalk/Ethernet adapter for the early Macs, with some application(s) supporting file transfer via, perhaps, FTP. We used them with mixed results at Lockheed in Sunnyvale, until the corporate small desktop standard was abruptly switched to IBM PC.

Did any Apple II model support AppleTalk?
gah4
2021-07-17 19:31:11 UTC
Permalink
On Saturday, July 17, 2021 at 9:00:25 AM UTC-7, Galen wrote:
> > So, was there an Ethernet card for the Apple II?
> I don’t know specifically about the Apple II family, but there was an AppleTalk/Ethernet adapter for the early Macs, with some application(s) supporting file transfer via, perhaps, FTP. We used them with mixed results at Lockheed in Sunnyvale, until the corporate small desktop standard was abruptly switched to IBM PC.

You mean a Localtalk-Ethertalk gateway like the GatorBox? I might even still have one.
I was for a while working on school networking projects, and the schools had a lot
of Localtalk networked Macs.

> Did any Apple II model support AppleTalk?

I think there was Localtalk for some, maybe with an add-in card,
but the later models might have it built in. I believe the IIGS
has it built-in.

I think we did have a IIGS at one school, but I don't think I ever got
it on the network. The school had a GatorStar that I bought on eBay,
which by then were very cheap. (GatorStar is GatorBox plus a
12 port LocalTalk hub.) I think that would have allowed printer
access, and maybe file sharing.

We had Netscape 2.0 for a long time on the Ethernet LCII macs, as
the later ones were too big.
John Dallman
2021-07-18 10:27:00 UTC
Permalink
In article <5ca128e4-4654-46b0-a0b2-***@googlegroups.com>,
***@u.washington.edu (gah4) wrote:

> > Did any Apple II model support AppleTalk?
> I think there was Localtalk for some, maybe with an add-in card,
> but the later models might have it built in. I believe the IIGS
> has it built-in.

All the early Macs and the Apple IIGS had high-speed serial ports that
could be used for LocalTalk, at about 230kbps.

The IIGS was a much more advanced beast than the II, II+ or IIe, none of
which had any kind of built-in serial or network communications. There
were add-on serial ports for them, but they were limited by the low
processor performance: communications at 9600bps or faster required
disabling interrupts.

<https://en.wikipedia.org/wiki/Apple_II_serial_cards#Super_Serial_Card_%E2
%80%93_Apple_Computer>

A sensible LocalTalk interface card would have needed a processor and
buffer memory on the card, making it quite expensive. Ethernet cards
would be more expensive, and the ability of an Apple II to do anything
useful with Ethernet-speed communications is rather doubtful. Also, early
Ethernet cabling was thick, inflexible and expensive to install. The
story's author doesn't quite appreciate how limited the early 1980s
technology was in some respect; their thinking is more like the mid-1990s.


John
Andrew Commons
2021-07-22 07:44:22 UTC
Permalink
On Saturday, 17 July 2021 at 8:42:27 am UTC+9:30, gah4 wrote:
> On Wednesday, July 14, 2021 at 10:40:38 AM UTC-7, Simon Clubley wrote:
> > https://www.theregister.com/2021/07/14/alternative_history_computer_revolution/
> >
> > DEC is mentioned (and keep reading to the end.)
> So, was there an Ethernet card for the Apple II?

If you want a nice view of what was going on in those times look at "Accidental Empires" by
Robert X. Cringely (aka Mark Stephens).

In terms of Apple and Ethernet..In about 1990 my home office and development environment
consisted of an Apple IIsi, MicroVax2000, and a DecStation 2100. They all ran DECnet. In the
case of the Apple it was using an Apple Ethernet card with 3rd party DECnet software (the DECnet
specification was freely available). The IIsi had a laserprinter attached and made a nice little print
server for the MicroVAX and DecStation.
Simon Clubley
2021-07-22 17:52:28 UTC
Permalink
On 2021-07-22, Andrew Commons <***@bigpond.com> wrote:
>
> In terms of Apple and Ethernet..In about 1990 my home office and development environment
> consisted of an Apple IIsi, MicroVax2000, and a DecStation 2100. They all ran DECnet. In the
> case of the Apple it was using an Apple Ethernet card with 3rd party DECnet software (the DECnet
> specification was freely available). The IIsi had a laserprinter attached and made a nice little print
> server for the MicroVAX and DecStation.

DECnet is not an open specification.

Parts of it are fully open (the lower-level NSP and related stuff) but
most of the higher-level application protocols are fully closed.

FAL is the only higher-level application protocol that is fully open.

The public CTERM specification is missing all the VMS extensions.

As for the others, show the known objects on your system and then
try and find public DECnet specifications for them. There isn't even
a public DECnet specification for the MAIL transport that I can find.

Now compare that to the TCP/IP situation. Everything there that is
part of a standard TCP/IP stack (including application protocols) is
fully open and documented.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
gah4
2021-07-23 12:00:11 UTC
Permalink
On Thursday, July 22, 2021 at 10:52:30 AM UTC-7, Simon Clubley wrote:

(snip)

> DECnet is not an open specification.
>
> Parts of it are fully open (the lower-level NSP and related stuff) but
> most of the higher-level application protocols are fully closed.
>
> FAL is the only higher-level application protocol that is fully open.
>
> The public CTERM specification is missing all the VMS extensions.

I don't know about openness, but I remember stories from the early
VAX days on how expensive it was. Expensive enough that people
would not network VAX systems because of the price.

Patents (if any) would have expired by now, though.
David Jones
2021-07-23 13:06:24 UTC
Permalink
On Friday, July 23, 2021 at 8:00:16 AM UTC-4, gah4 wrote:
> I don't know about openness, but I remember stories from the early
> VAX days on how expensive it was. Expensive enough that people
> would not network VAX systems because of the price.
>
> Patents (if any) would have expired by now, though.

The first optical fibre backbone for the OSU campus network used
Proteon routers that supported DECnet as one of the protocols. Aside from
being slow, the option was very expensive. After a couple years, we dropped
DECnet from the contract and the backbone became TCP/IP only.
Arne Vajhøj
2021-07-23 15:36:05 UTC
Permalink
On 7/23/2021 8:00 AM, gah4 wrote:
> I don't know about openness, but I remember stories from the early
> VAX days on how expensive it was. Expensive enough that people
> would not network VAX systems because of the price.

As I recall it then DECnet came with VMS.

But TCP/IP was an extra license and way back an expensive
license.

Arne
chris
2021-07-23 16:36:39 UTC
Permalink
On 07/23/21 16:36, Arne Vajhøj wrote:
> On 7/23/2021 8:00 AM, gah4 wrote:
>> I don't know about openness, but I remember stories from the early
>> VAX days on how expensive it was. Expensive enough that people
>> would not network VAX systems because of the price.
>
> As I recall it then DECnet came with VMS.
>
> But TCP/IP was an extra license and way back an expensive
> license.
>
> Arne
>
>

Full decnet was an expensive layered product, from memory, though
a subset and run time libraries did come with vms.

Had a look at decnet at one stage, but already has tcp/ip on several
machines here, so ended up with the third party Wollongong TCP/IP,
from Oz, iirc. Got the job done, but the lack of industry standard,
shipped with the machine networking, was a serious impediment for
Vax and VMS.

The network was and still is the computer etc...
Robert A. Brooks
2021-07-23 17:02:29 UTC
Permalink
On 7/23/2021 12:36 PM, chris wrote:

> Full decnet was an expensive layered product, from memory, though
> a subset and run time libraries did come with vms.

I'm not sure what you mean by "run time libraries"; there is
no run-time-only DECnet option for either Phase IV or Phase V.

DECnet Phase IV was pretty simple -- you had either a routing license
or an end node license. The X.25 stuff (VAX PSI) was separate, but that's not
DECnet per se. The NAS morass was simply a license bundling mechanism with
other stuff, but did not alter the DECnet functionality.

DECnet Phase V (known first as DECnet/OSI and now known as DECnet-Plus)
has more moving parts (the optional OSAK, FTAM, VT -- none of which require an
extra license), and its licensing also essentially follows the routing/end-node
paradigm. The X.25 stuff is again separately licensed.

--
-- Rob
chris
2021-07-23 18:15:45 UTC
Permalink
On 07/23/21 18:02, Robert A. Brooks wrote:
> On 7/23/2021 12:36 PM, chris wrote:
>
>> Full decnet was an expensive layered product, from memory, though
>> a subset and run time libraries did come with vms.
>
> I'm not sure what you mean by "run time libraries"; there is
> no run-time-only DECnet option for either Phase IV or Phase V.
>
> DECnet Phase IV was pretty simple -- you had either a routing license
> or an end node license. The X.25 stuff (VAX PSI) was separate, but
> that's not DECnet per se. The NAS morass was simply a license bundling
> mechanism with
> other stuff, but did not alter the DECnet functionality.
>
> DECnet Phase V (known first as DECnet/OSI and now known as DECnet-Plus)
> has more moving parts (the optional OSAK, FTAM, VT -- none of which
> require an extra license), and its licensing also essentially follows
> the routing/end-node paradigm. The X.25 stuff is again separately licensed.
>

So you are just confirming what I said then, that full decnet was an
expensive layered product ?. Thanks for the clarification though.

Most people expect networking to be part of the base os these days, as
machines are generally useless without it...
Arne Vajhøj
2021-07-23 18:27:06 UTC
Permalink
On 7/23/2021 2:15 PM, chris wrote:
> On 07/23/21 18:02, Robert A. Brooks wrote:
>> On 7/23/2021 12:36 PM, chris wrote:
>>> Full decnet was an expensive layered product, from memory, though
>>> a subset and run time libraries did come with vms.
>>
>> I'm not sure what you mean by "run time libraries"; there is
>> no run-time-only DECnet option for either Phase IV or Phase V.
>>
>> DECnet Phase IV was pretty simple -- you had either a routing license
>> or an end node license. The X.25 stuff (VAX PSI) was separate, but
>> that's not DECnet per se. The NAS morass was simply a license bundling
>> mechanism with
>> other stuff, but did not alter the DECnet functionality.
>>
>> DECnet Phase V (known first as DECnet/OSI and now known as DECnet-Plus)
>> has more moving parts (the optional OSAK, FTAM, VT -- none of which
>> require an extra license), and its licensing also essentially follows
>> the routing/end-node paradigm. The X.25 stuff is again separately
>> licensed.
>
> So you are just confirming what I said then, that full decnet was an
> expensive layered product ?. Thanks for the clarification though.
>
> Most people expect networking to be part of the base os these days, as
> machines are generally useless without it...

I agree that network is necessary.

But DECnet with end-node license instead of routing license
was still network.

Arne
chris
2021-07-23 18:36:55 UTC
Permalink
On 07/23/21 19:27, Arne Vajhøj wrote:
> On 7/23/2021 2:15 PM, chris wrote:
>> On 07/23/21 18:02, Robert A. Brooks wrote:
>>> On 7/23/2021 12:36 PM, chris wrote:
>>>> Full decnet was an expensive layered product, from memory, though
>>>> a subset and run time libraries did come with vms.
>>>
>>> I'm not sure what you mean by "run time libraries"; there is
>>> no run-time-only DECnet option for either Phase IV or Phase V.
>>>
>>> DECnet Phase IV was pretty simple -- you had either a routing license
>>> or an end node license. The X.25 stuff (VAX PSI) was separate, but
>>> that's not DECnet per se. The NAS morass was simply a license bundling
>>> mechanism with
>>> other stuff, but did not alter the DECnet functionality.
>>>
>>> DECnet Phase V (known first as DECnet/OSI and now known as DECnet-Plus)
>>> has more moving parts (the optional OSAK, FTAM, VT -- none of which
>>> require an extra license), and its licensing also essentially follows
>>> the routing/end-node paradigm. The X.25 stuff is again separately
>>> licensed.
>>
>> So you are just confirming what I said then, that full decnet was an
>> expensive layered product ?. Thanks for the clarification though.
>>
>> Most people expect networking to be part of the base os these days, as
>> machines are generally useless without it...
>
> I agree that network is necessary.
>
> But DECnet with end-node license instead of routing license
> was still network.
>
> Arne

Probably excellent when it was first released, back in the days
of isdn and X25, but who would choose it now, other than for niche
applications ?...
Arne Vajhøj
2021-07-23 18:41:46 UTC
Permalink
On 7/23/2021 2:36 PM, chris wrote:
> On 07/23/21 19:27, Arne Vajhøj wrote:
>> On 7/23/2021 2:15 PM, chris wrote:
>>> On 07/23/21 18:02, Robert A. Brooks wrote:
>>>> On 7/23/2021 12:36 PM, chris wrote:
>>>>> Full decnet was an expensive layered product, from memory, though
>>>>> a subset and run time libraries did come with vms.
>>>>
>>>> I'm not sure what you mean by "run time libraries"; there is
>>>> no run-time-only DECnet option for either Phase IV or Phase V.
>>>>
>>>> DECnet Phase IV was pretty simple -- you had either a routing license
>>>> or an end node license. The X.25 stuff (VAX PSI) was separate, but
>>>> that's not DECnet per se. The NAS morass was simply a license bundling
>>>> mechanism with
>>>> other stuff, but did not alter the DECnet functionality.
>>>>
>>>> DECnet Phase V (known first as DECnet/OSI and now known as DECnet-Plus)
>>>> has more moving parts (the optional OSAK, FTAM, VT -- none of which
>>>> require an extra license), and its licensing also essentially follows
>>>> the routing/end-node paradigm. The X.25 stuff is again separately
>>>> licensed.
>>>
>>> So you are just confirming what I said then, that full decnet was an
>>> expensive layered product ?. Thanks for the clarification though.
>>>
>>> Most people expect networking to be part of the base os these days, as
>>> machines are generally useless without it...
>>
>> I agree that network is necessary.
>>
>> But DECnet with end-node license instead of routing license
>> was still network.
>
> Probably excellent when it was first released, back in the days
> of isdn and X25, but who would choose it now, other than for niche
> applications ?...

From around 1995 or so TCP/IP changed from nice to have to must have.

Arne
chris
2021-07-23 18:56:36 UTC
Permalink
On 07/23/21 19:41, Arne Vajhøj wrote:
> On 7/23/2021 2:36 PM, chris wrote:
>> On 07/23/21 19:27, Arne Vajhøj wrote:
>>> On 7/23/2021 2:15 PM, chris wrote:
>>>> On 07/23/21 18:02, Robert A. Brooks wrote:
>>>>> On 7/23/2021 12:36 PM, chris wrote:
>>>>>> Full decnet was an expensive layered product, from memory, though
>>>>>> a subset and run time libraries did come with vms.
>>>>>
>>>>> I'm not sure what you mean by "run time libraries"; there is
>>>>> no run-time-only DECnet option for either Phase IV or Phase V.
>>>>>
>>>>> DECnet Phase IV was pretty simple -- you had either a routing license
>>>>> or an end node license. The X.25 stuff (VAX PSI) was separate, but
>>>>> that's not DECnet per se. The NAS morass was simply a license bundling
>>>>> mechanism with
>>>>> other stuff, but did not alter the DECnet functionality.
>>>>>
>>>>> DECnet Phase V (known first as DECnet/OSI and now known as
>>>>> DECnet-Plus)
>>>>> has more moving parts (the optional OSAK, FTAM, VT -- none of which
>>>>> require an extra license), and its licensing also essentially follows
>>>>> the routing/end-node paradigm. The X.25 stuff is again separately
>>>>> licensed.
>>>>
>>>> So you are just confirming what I said then, that full decnet was an
>>>> expensive layered product ?. Thanks for the clarification though.
>>>>
>>>> Most people expect networking to be part of the base os these days, as
>>>> machines are generally useless without it...
>>>
>>> I agree that network is necessary.
>>>
>>> But DECnet with end-node license instead of routing license
>>> was still network.
>>
>> Probably excellent when it was first released, back in the days
>> of isdn and X25, but who would choose it now, other than for niche
>> applications ?...
>
> From around 1995 or so TCP/IP changed from nice to have to must have.
>
> Arne
>
>
Agreed, must have been that time frame, perhaps vms 5.x something that I
last had anything to do with decnet. Even then though, is seemed so
wooden and didn't really talk to anything other than other dec machines.

Assume that now, a full tcp/ip stack does or will come as part of the OS
from VSI ?...
Simon Clubley
2021-07-23 18:59:29 UTC
Permalink
On 2021-07-23, chris <chris-***@tridac.net> wrote:
> On 07/23/21 19:27, Arne Vajhøj wrote:
>>
>> But DECnet with end-node license instead of routing license
>> was still network.
>>
>
> Probably excellent when it was first released, back in the days
> of isdn and X25, but who would choose it now, other than for niche
> applications ?...
>

Unfortunately, there are still way too many people still using
DECnet Phase IV today. :-(

When VSI was deciding on the priority order for porting the various
layered and other products, DECnet was popular enough that VSI had
to move porting of DECnet Phase IV way up the priority list. :-(

I would love to know how these DECnet Phase IV users get through
a security audit in today's world.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Robert A. Brooks
2021-07-23 22:09:07 UTC
Permalink
On 7/23/2021 2:59 PM, Simon Clubley wrote:

> When VSI was deciding on the priority order for porting the various
> layered and other products, DECnet was popular enough that VSI had
> to move porting of DECnet Phase IV way up the priority list. :-(

DECnet Phase IV is tiny compared to DECnet Phase V, and was much
easier to port.

The port of Phase V is ongoing.

--
-- Rob
David Jones
2021-07-24 00:59:57 UTC
Permalink
On Friday, July 23, 2021 at 6:09:10 PM UTC-4, Robert A. Brooks wrote:
> DECnet Phase IV is tiny compared to DECnet Phase V, and was much
> easier to port.
>
> The port of Phase V is ongoing.
>
> --
> -- Rob

Phase V is so bloated that initially DEC said you had to use a separate box
to be the router (and every network required a router).
Robert A. Brooks
2021-07-24 03:32:05 UTC
Permalink
On 7/23/2021 8:59 PM, David Jones wrote:
> On Friday, July 23, 2021 at 6:09:10 PM UTC-4, Robert A. Brooks wrote:
>> DECnet Phase IV is tiny compared to DECnet Phase V, and was much
>> easier to port.
>>
>> The port of Phase V is ongoing.
>>
>> --
>> -- Rob
>
> Phase V is so bloated that initially DEC said you had to use a separate box
> to be the router (and every network required a router).

Having attempted to run the notorious "Extensions to DECnet-VAX" on a memory-constrained
MicroVAX II, I am well aware of how compute-intensive Phase V is.

I am expressing neither admiration nor denigration of any phase of DECnet; I am
simply giving an update on the porting, and the rationale as to why IV was
done before V.


--

-- Rob
Arne Vajhøj
2021-07-24 01:18:09 UTC
Permalink
On 7/23/2021 6:09 PM, Robert A. Brooks wrote:
> On 7/23/2021 2:59 PM, Simon Clubley wrote:
>> When VSI was deciding on the priority order for porting the various
>> layered and other products, DECnet was popular enough that VSI had
>> to move porting of DECnet Phase IV way up the priority list. :-(
>
> DECnet Phase IV is tiny compared to DECnet Phase V, and was much
> easier to port.
>
> The port of Phase V is ongoing.

My guess is that there is a lot of code and DCL out there
that require DECnet but relative little that require DECnet
phase V.

When DECnet phase V finally arrived then the world had switched
to TCP/IP.

So DECnet phase IV will be enough for most DECnet users.

Arne
Arne Vajhøj
2021-07-24 01:27:16 UTC
Permalink
On 7/23/2021 2:59 PM, Simon Clubley wrote:
> I would love to know how these DECnet Phase IV users get through
> a security audit in today's world.

If the auditors is one of those that follow a checklist and
require everything checked then the setup will fail the audit.

But if the auditor is one that does a risk assessment for
each problem and prioritize based on that, then there
will likely be way too many issues above DECnet phase IV
for it to get attention.

Example: if there is a system with both DECnet and telnet
allowed for login, then there will be two problems for
having protocols allowing login with plain text password
enabled. But if prioritized per risk, then telnet will
get the focus, because TCP/IP get through the network
while DECnet does not.

Of course if DECnet is the only problem then it will
catch serious flak. But most sites will have many
other issues not the least related to the applications
themselves.

Arne
Andrew Commons
2021-07-24 04:41:51 UTC
Permalink
On Friday, 23 July 2021 at 3:22:30 am UTC+9:30, Simon Clubley wrote:

> DECnet is not an open specification.
>
> Parts of it are fully open (the lower-level NSP and related stuff) but
> most of the higher-level application protocols are fully closed.
>
So, DECnet is/was an open specification.

Some of it can be found here:

ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/

The fact that the layered applications were not open does not change the
validity of that statement.

Was it expensive? Yes, and so was the Operating System and the hardware.

Now add hardware/software maintenance and support on top of all that.

It was an expensive game to be in and maintenance bills came in two colours,
pale green and red.

Unix, on the other hand, was developed on DEC hardware up to BSD and System V.
Licenses were basically free if you were an academic institution, ditto for
TCP/IP. For maintenance and support you had mailing lists.

So cheap and cheerful won the academic space unless real quality and reliability was
needed - think SPAN and HEPnet.
Simon Clubley
2021-07-24 14:43:43 UTC
Permalink
On 2021-07-24, Andrew Commons <***@bigpond.com> wrote:
> On Friday, 23 July 2021 at 3:22:30 am UTC+9:30, Simon Clubley wrote:
>
>> DECnet is not an open specification.
>>
>> Parts of it are fully open (the lower-level NSP and related stuff) but
>> most of the higher-level application protocols are fully closed.
>>
> So, DECnet is/was an open specification.
>
> Some of it can be found here:
>
> ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/
>
> The fact that the layered applications were not open does not change the
> validity of that statement.
>

Unfortunately, a protocol which only opens its lower layers and only
1 or 2 of its upper layer protocols is not open in any way that could
accurately be described as open.

It would be like saying that TCP/IP is open if only everything at TCP
level and below was fully open along with FTP and a partial Telnet
specification while everything else in the TCP/IP stack was fully closed.

The point of an open protocol is that you can fully implement another
full version of it just by reading the specifications. You can do that
with TCP/IP but you most certainly cannot do that with the subset of
DECnet specifications that are available.

Not even the MAIL protocol is documented in public. That would be like
calling TCP/IP open while keeping the SMTP specification closed.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-07-25 00:26:49 UTC
Permalink
On 7/24/2021 10:43 AM, Simon Clubley wrote:
> On 2021-07-24, Andrew Commons <***@bigpond.com> wrote:
>> On Friday, 23 July 2021 at 3:22:30 am UTC+9:30, Simon Clubley wrote:
>>> DECnet is not an open specification.
>>>
>>> Parts of it are fully open (the lower-level NSP and related stuff) but
>>> most of the higher-level application protocols are fully closed.
>>>
>> So, DECnet is/was an open specification.
>>
>> Some of it can be found here:
>>
>> ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/
>>
>> The fact that the layered applications were not open does not change the
>> validity of that statement.
>
> Unfortunately, a protocol which only opens its lower layers and only
> 1 or 2 of its upper layer protocols is not open in any way that could
> accurately be described as open.
>
> It would be like saying that TCP/IP is open if only everything at TCP
> level and below was fully open along with FTP and a partial Telnet
> specification while everything else in the TCP/IP stack was fully closed.
>
> The point of an open protocol is that you can fully implement another
> full version of it just by reading the specifications. You can do that
> with TCP/IP but you most certainly cannot do that with the subset of
> DECnet specifications that are available.
>
> Not even the MAIL protocol is documented in public. That would be like
> calling TCP/IP open while keeping the SMTP specification closed.

A protocol is open if it itself is documented.

Other protocols on top of it can be open or closed without
impacting that.

There are also closed protocols on top of TCP/IP - that
does not make TCP/IP closed.

Arne
Dave Froble
2021-07-25 02:27:17 UTC
Permalink
On 7/24/2021 8:26 PM, Arne Vajhøj wrote:
> On 7/24/2021 10:43 AM, Simon Clubley wrote:
>> On 2021-07-24, Andrew Commons <***@bigpond.com> wrote:
>>> On Friday, 23 July 2021 at 3:22:30 am UTC+9:30, Simon Clubley wrote:
>>>> DECnet is not an open specification.
>>>>
>>>> Parts of it are fully open (the lower-level NSP and related stuff) but
>>>> most of the higher-level application protocols are fully closed.
>>>>
>>> So, DECnet is/was an open specification.
>>>
>>> Some of it can be found here:
>>>
>>> ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/
>>>
>>> The fact that the layered applications were not open does not change the
>>> validity of that statement.
>>
>> Unfortunately, a protocol which only opens its lower layers and only
>> 1 or 2 of its upper layer protocols is not open in any way that could
>> accurately be described as open.
>>
>> It would be like saying that TCP/IP is open if only everything at TCP
>> level and below was fully open along with FTP and a partial Telnet
>> specification while everything else in the TCP/IP stack was fully closed.
>>
>> The point of an open protocol is that you can fully implement another
>> full version of it just by reading the specifications. You can do that
>> with TCP/IP but you most certainly cannot do that with the subset of
>> DECnet specifications that are available.
>>
>> Not even the MAIL protocol is documented in public. That would be like
>> calling TCP/IP open while keeping the SMTP specification closed.
>
> A protocol is open if it itself is documented.
>
> Other protocols on top of it can be open or closed without
> impacting that.
>
> There are also closed protocols on top of TCP/IP - that
> does not make TCP/IP closed.
>
> Arne
>

When this started, I just knew that some would come up with that "open"
word. Ya know, that word can be used in various contexts. "Open the
door." "The book is open." And such.

Regardless, the claim was "(the DECnet specification was freely
available)" The claim was never "open", and definitely not "open
software". I don't know how "freely" it was, but I do know there was
DECnet implementations on other than VMS.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Scott Dorsey
2021-07-25 12:28:58 UTC
Permalink
Dave Froble <***@tsoft-inc.com> wrote:
>
>Regardless, the claim was "(the DECnet specification was freely
>available)" The claim was never "open", and definitely not "open
>software". I don't know how "freely" it was, but I do know there was
>DECnet implementations on other than VMS.

The Phase IV documentation is enough to build a working decnet client
to move packets back and forth.

The higher stuff like mail is not as well documented. It would be hard
to do it without the fiche, I think. But a lot of people did it, including
Sun and IBM. They may have used the fiche.

Back in the eighties, the attitudes toward locking down software were
rather different than they are today. Many manufacturers still thought
of operating systems as a free bonus they included to help them sell
hardware. Why would someone pirate it? They'd have to have a machine to
run it on anyway.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Simon Clubley
2021-07-26 00:36:32 UTC
Permalink
On 2021-07-25, Scott Dorsey <***@panix.com> wrote:
> Dave Froble <***@tsoft-inc.com> wrote:
>>
>>Regardless, the claim was "(the DECnet specification was freely
>>available)" The claim was never "open", and definitely not "open
>>software". I don't know how "freely" it was, but I do know there was
>>DECnet implementations on other than VMS.
>
> The Phase IV documentation is enough to build a working decnet client
> to move packets back and forth.
>
> The higher stuff like mail is not as well documented. It would be hard
> to do it without the fiche, I think. But a lot of people did it, including
> Sun and IBM. They may have used the fiche.
>

Exactly. And there are always legal risks with implementing protocols
that do not have public specifications. For the same reason, those public
specifications must also have been released _as_ public specifications
and not just fallen into the public domain.

For example, there's now a copy of the LAT specification on Bitsavers.
(At least there was when I looked through the documents on there. I don't
know if it's still there).

This also extends to items under copyright, not patents.

For example, there's a public copy of the Pillar specification, but it
appears to have fallen into the public domain, instead of being released
_as_ a public document.

As such, if I were to implement a compiler to the specification in that
document, could I get into legal trouble for doing so if I released the
compiler for general use ?

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-07-26 01:05:22 UTC
Permalink
On 7/25/2021 8:36 PM, Simon Clubley wrote:
> On 2021-07-25, Scott Dorsey <***@panix.com> wrote:
>> Dave Froble <***@tsoft-inc.com> wrote:
>>>
>>> Regardless, the claim was "(the DECnet specification was freely
>>> available)" The claim was never "open", and definitely not "open
>>> software". I don't know how "freely" it was, but I do know there was
>>> DECnet implementations on other than VMS.
>>
>> The Phase IV documentation is enough to build a working decnet client
>> to move packets back and forth.
>>
>> The higher stuff like mail is not as well documented. It would be hard
>> to do it without the fiche, I think. But a lot of people did it, including
>> Sun and IBM. They may have used the fiche.
>>
>
> Exactly. And there are always legal risks with implementing protocols
> that do not have public specifications. For the same reason, those public
> specifications must also have been released _as_ public specifications
> and not just fallen into the public domain.
>
> For example, there's now a copy of the LAT specification on Bitsavers.
> (At least there was when I looked through the documents on there. I don't
> know if it's still there).
>
> This also extends to items under copyright, not patents.
>
> For example, there's a public copy of the Pillar specification, but it
> appears to have fallen into the public domain, instead of being released
> _as_ a public document.
>
> As such, if I were to implement a compiler to the specification in that
> document, could I get into legal trouble for doing so if I released the
> compiler for general use ?
>
> Simon.
>

Who is going to care?

If you name it something else, who is going to know where you got your
ideas?

In today's "language of the week" environment, how does anyone keep
track of what's available, and where the ideas come from?

The only "real" question is, are you going to do it?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-07-26 01:21:20 UTC
Permalink
On 7/25/2021 9:05 PM, Dave Froble wrote:
> On 7/25/2021 8:36 PM, Simon Clubley wrote:
>> For example, there's a public copy of the Pillar specification, but it
>> appears to have fallen into the public domain, instead of being released
>> _as_ a public document.
>>
>> As such, if I were to implement a compiler to the specification in that
>> document, could I get into legal trouble for doing so if I released the
>> compiler for general use ?
>
> Who is going to care?

There is a tiny risk that HPE's lawyers may. They should own whatever
IPR is left.

> If you name it something else, who is going to know where you got your
> ideas?

If some of the DEC people from back then still follow compiler
technology, then they may note and they may note it publicly and
then the word gets around.

> In today's "language of the week" environment, how does anyone keep
> track of what's available, and where the ideas come from?

There is a big difference between "inspired by" and
"implementing".

"inspired by" is something everybody does. Java looked at C++.
C# looked at Java. And so on.

Arne
Simon Clubley
2021-07-26 17:30:18 UTC
Permalink
On 2021-07-25, Dave Froble <***@tsoft-inc.com> wrote:
>
> The only "real" question is, are you going to do it?
>

Given the issues involved, I don't think so.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2021-07-26 01:06:09 UTC
Permalink
On 7/25/21 8:36 PM, Simon Clubley wrote:
> On 2021-07-25, Scott Dorsey <***@panix.com> wrote:
>> Dave Froble <***@tsoft-inc.com> wrote:
>>>
>>> Regardless, the claim was "(the DECnet specification was freely
>>> available)" The claim was never "open", and definitely not "open
>>> software". I don't know how "freely" it was, but I do know there was
>>> DECnet implementations on other than VMS.
>>
>> The Phase IV documentation is enough to build a working decnet client
>> to move packets back and forth.
>>
>> The higher stuff like mail is not as well documented. It would be hard
>> to do it without the fiche, I think. But a lot of people did it, including
>> Sun and IBM. They may have used the fiche.
>>
>
> Exactly. And there are always legal risks with implementing protocols
> that do not have public specifications. For the same reason, those public
> specifications must also have been released _as_ public specifications
> and not just fallen into the public domain.
>
> For example, there's now a copy of the LAT specification on Bitsavers.
> (At least there was when I looked through the documents on there. I don't
> know if it's still there).
>
> This also extends to items under copyright, not patents.
>
> For example, there's a public copy of the Pillar specification, but it
> appears to have fallen into the public domain, instead of being released
> _as_ a public document.

Things don't "fall" into the public domain. They have to be explicitly
placed there by the owner of the IP or they remain the property of the
owner or his/her heirs and assigns


bill
Arne Vajhøj
2021-07-26 01:10:28 UTC
Permalink
On 7/25/2021 8:36 PM, Simon Clubley wrote:
> On 2021-07-25, Scott Dorsey <***@panix.com> wrote:
>> Dave Froble <***@tsoft-inc.com> wrote:
>>>
>>> Regardless, the claim was "(the DECnet specification was freely
>>> available)" The claim was never "open", and definitely not "open
>>> software". I don't know how "freely" it was, but I do know there was
>>> DECnet implementations on other than VMS.
>>
>> The Phase IV documentation is enough to build a working decnet client
>> to move packets back and forth.
>>
>> The higher stuff like mail is not as well documented. It would be hard
>> to do it without the fiche, I think. But a lot of people did it, including
>> Sun and IBM. They may have used the fiche.
>
> Exactly. And there are always legal risks with implementing protocols
> that do not have public specifications. For the same reason, those public
> specifications must also have been released _as_ public specifications
> and not just fallen into the public domain.
>
> For example, there's now a copy of the LAT specification on Bitsavers.
> (At least there was when I looked through the documents on there. I don't
> know if it's still there).
>
> This also extends to items under copyright, not patents.
>
> For example, there's a public copy of the Pillar specification, but it
> appears to have fallen into the public domain, instead of being released
> _as_ a public document.
>
> As such, if I were to implement a compiler to the specification in that
> document, could I get into legal trouble for doing so if I released the
> compiler for general use ?

Maybe, but not likely.

Copyright? No. You are not copying anything. And with the latest
Oracle-Google decision then no API problem.

Patent? Not likely. I would assume all relevant patents to
have expired.

Trademark? Just call it something different and you are good.

Trade secret? Maybe, but I doubt it. HPE would need to show that
have taken steps to keep it secret and that it has economic value.
If they have not requested the doc to be removed and if they have
not made a dime on it for 40 years, then they may have a hard
case in court.

(one should obviously consult a lawyer not a news group,
before pursuing such an endeavor)

But even though the risk of losing in court may be small, then
the risk of going bankrupt due to legal cost may still
deter.

Arne
Andrew Commons
2021-07-26 01:53:50 UTC
Permalink
On Sunday, 25 July 2021 at 9:59:01 pm UTC+9:30, Scott Dorsey wrote:

>
> Back in the eighties, the attitudes toward locking down software were
> rather different than they are today. Many manufacturers still thought
> of operating systems as a free bonus they included to help them sell
> hardware. Why would someone pirate it? They'd have to have a machine to
> run it on anyway.
> --scott
>
Back in the eighties DEC were certainly very relaxed about using stuff
from the fiche. Password hashing was a good example. Clean room
implementation was not possible because although the algorithm was
public knowledge the little extras thrown in by DEC were only revealed
in the fiche.

Nobody at DEC asked us how we implemented password cracking in Security
Toolkit even when we were running it on systems at Maynard.

We actually had two ways of doing it but both relied on having access
to the fiche. One was to copy the code unmodified from the fiche and
the other was to map an image that used it, I used SETP0, and execute
the code from that. As it turned out I needn't have bothered with the
SETP0 trick.
Bill Gunshannon
2021-07-25 13:07:56 UTC
Permalink
On 7/24/21 10:27 PM, Dave Froble wrote:
> On 7/24/2021 8:26 PM, Arne Vajhøj wrote:
>> On 7/24/2021 10:43 AM, Simon Clubley wrote:
>>> On 2021-07-24, Andrew Commons <***@bigpond.com> wrote:
>>>> On Friday, 23 July 2021 at 3:22:30 am UTC+9:30, Simon Clubley wrote:
>>>>> DECnet is not an open specification.
>>>>>
>>>>> Parts of it are fully open (the lower-level NSP and related stuff) but
>>>>> most of the higher-level application protocols are fully closed.
>>>>>
>>>> So, DECnet is/was an open specification.
>>>>
>>>> Some of it can be found here:
>>>>
>>>> ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/
>>>>
>>>> The fact that the layered applications were not open does not change
>>>> the
>>>> validity of that statement.
>>>
>>> Unfortunately, a protocol which only opens its lower layers and only
>>> 1 or 2 of its upper layer protocols is not open in any way that could
>>> accurately be described as open.
>>>
>>> It would be like saying that TCP/IP is open if only everything at TCP
>>> level and below was fully open along with FTP and a partial Telnet
>>> specification while everything else in the TCP/IP stack was fully
>>> closed.
>>>
>>> The point of an open protocol is that you can fully implement another
>>> full version of it just by reading the specifications. You can do that
>>> with TCP/IP but you most certainly cannot do that with the subset of
>>> DECnet specifications that are available.
>>>
>>> Not even the MAIL protocol is documented in public. That would be like
>>> calling TCP/IP open while keeping the SMTP specification closed.
>>
>> A protocol is open if it itself is documented.
>>
>> Other protocols on top of it can be open or closed without
>> impacting that.
>>
>> There are also closed protocols on top of TCP/IP - that
>> does not make TCP/IP closed.
>>
>> Arne
>>
>
> When this started, I just knew that some would come up with that "open"
> word.  Ya know, that word can be used in various contexts.  "Open the
> door."  "The book is open."  And such.
>
> Regardless, the claim was "(the DECnet specification was freely
> available)"  The claim was never "open", and definitely not "open
> software".  I don't know how "freely" it was, but I do know there was
> DECnet implementations on other than VMS.
>

I have DECnet on my Linux box. Used to connect to it using my
DECServer200. And connect to both VAX and RSTS from it.

Speaking of "Open", there is always OpenVMS. :-)

bill
Robert A. Brooks
2021-07-25 13:32:42 UTC
Permalink
On 7/25/2021 9:07 AM, Bill Gunshannon wrote:
> On 7/24/21 10:27 PM, Dave Froble wrote:
>> On 7/24/2021 8:26 PM, Arne Vajhøj wrote:
>>> On 7/24/2021 10:43 AM, Simon Clubley wrote:
>>>> On 2021-07-24, Andrew Commons <***@bigpond.com> wrote:
>>>>> On Friday, 23 July 2021 at 3:22:30 am UTC+9:30, Simon Clubley wrote:
>>>>>> DECnet is not an open specification.
>>>>>>
>>>>>> Parts of it are fully open (the lower-level NSP and related stuff) but
>>>>>> most of the higher-level application protocols are fully closed.
>>>>>>
>>>>> So, DECnet is/was an open specification.
>>>>>
>>>>> Some of it can be found here:
>>>>>
>>>>> ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/
>>>>>
>>>>> The fact that the layered applications were not open does not change the
>>>>> validity of that statement.
>>>>
>>>> Unfortunately, a protocol which only opens its lower layers and only
>>>> 1 or 2 of its upper layer protocols is not open in any way that could
>>>> accurately be described as open.
>>>>
>>>> It would be like saying that TCP/IP is open if only everything at TCP
>>>> level and below was fully open along with FTP and a partial Telnet
>>>> specification while everything else in the TCP/IP stack was fully closed.
>>>>
>>>> The point of an open protocol is that you can fully implement another
>>>> full version of it just by reading the specifications. You can do that
>>>> with TCP/IP but you most certainly cannot do that with the subset of
>>>> DECnet specifications that are available.
>>>>
>>>> Not even the MAIL protocol is documented in public. That would be like
>>>> calling TCP/IP open while keeping the SMTP specification closed.
>>>
>>> A protocol is open if it itself is documented.
>>>
>>> Other protocols on top of it can be open or closed without
>>> impacting that.
>>>
>>> There are also closed protocols on top of TCP/IP - that
>>> does not make TCP/IP closed.
>>>
>>> Arne
>>>
>>
>> When this started, I just knew that some would come up with that "open" word.
>> Ya know, that word can be used in various contexts.  "Open the door."  "The
>> book is open."  And such.
>>
>> Regardless, the claim was "(the DECnet specification was freely available)"
>> The claim was never "open", and definitely not "open software".  I don't know
>> how "freely" it was, but I do know there was DECnet implementations on other
>> than VMS.
>>
>
> I have DECnet on my Linux box.  Used to connect to it using my
> DECServer200.  And connect to both VAX and RSTS from it.

That would be LAT, not DECnet, using a DECserver. They did not
use DECnet. The MOP protocol is used to remotely manage DECservers.

As the DECUS button said (regarding LAT on RSTS/E) -- "Better LAT/E than never"

--
-- Rob
Scott Dorsey
2021-07-25 14:02:20 UTC
Permalink
Robert A. Brooks <***@vmssoftware.com> wrote:
>That would be LAT, not DECnet, using a DECserver. They did not
>use DECnet. The MOP protocol is used to remotely manage DECservers.

And the MOP protocol is patented... but the patent does not provide sufficient
information to implement a client. Some people making third party terminal
servers have licensed the patent but it is far from open when compared to
decnet.

Whereas in the IP world, everything is IP, in the DEC world you may have
Decnet, Vaxcluster, and MOP packets all running on the same cable, with
totally different formats. Everything from the data link layer on up is
different, but a lot of people don't seem to recognize that and go poking
at Decnet when they have clustering issues, etc.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Bill Gunshannon
2021-07-25 16:43:05 UTC
Permalink
On 7/25/21 10:02 AM, Scott Dorsey wrote:
> Robert A. Brooks <***@vmssoftware.com> wrote:
>> That would be LAT, not DECnet, using a DECserver. They did not
>> use DECnet. The MOP protocol is used to remotely manage DECservers.
>
> And the MOP protocol is patented... but the patent does not provide sufficient
> information to implement a client. Some people making third party terminal
> servers have licensed the patent but it is far from open when compared to
> decnet.

I can only assume it was clean room duplicated as it is available
on Linux as well.

>
> Whereas in the IP world, everything is IP, in the DEC world you may have
> Decnet, Vaxcluster, and MOP packets all running on the same cable, with
> totally different formats. Everything from the data link layer on up is
> different, but a lot of people don't seem to recognize that and go poking
> at Decnet when they have clustering issues, etc.
> --scott
>

While the names seem to wander it is networking, it cam from DEC, it is
not TCP/IP so it seems to me it is all just various parts of DECnet. :-)

bill
Simon Clubley
2021-07-26 00:22:39 UTC
Permalink
On 2021-07-25, Scott Dorsey <***@panix.com> wrote:
> Robert A. Brooks <***@vmssoftware.com> wrote:
>>That would be LAT, not DECnet, using a DECserver. They did not
>>use DECnet. The MOP protocol is used to remotely manage DECservers.
>
> And the MOP protocol is patented... but the patent does not provide sufficient
> information to implement a client. Some people making third party terminal
> servers have licensed the patent but it is far from open when compared to
> decnet.
>

Are you thinking of LAT and not MOP ? The MOP specification is freely
available, but LAT had (has?) patents against it.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Scott Dorsey
2021-07-26 02:09:51 UTC
Permalink
Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2021-07-25, Scott Dorsey <***@panix.com> wrote:
>> Robert A. Brooks <***@vmssoftware.com> wrote:
>>>That would be LAT, not DECnet, using a DECserver. They did not
>>>use DECnet. The MOP protocol is used to remotely manage DECservers.
>>
>> And the MOP protocol is patented... but the patent does not provide sufficient
>> information to implement a client. Some people making third party terminal
>> servers have licensed the patent but it is far from open when compared to
>> decnet.
>
>Are you thinking of LAT and not MOP ? The MOP specification is freely
>available, but LAT had (has?) patents against it.

I am in fact, yes.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Bill Gunshannon
2021-07-25 16:39:36 UTC
Permalink
On 7/25/21 9:32 AM, Robert A. Brooks wrote:
> On 7/25/2021 9:07 AM, Bill Gunshannon wrote:
>> On 7/24/21 10:27 PM, Dave Froble wrote:
>>> On 7/24/2021 8:26 PM, Arne Vajhøj wrote:
>>>> On 7/24/2021 10:43 AM, Simon Clubley wrote:
>>>>> On 2021-07-24, Andrew Commons <***@bigpond.com> wrote:
>>>>>> On Friday, 23 July 2021 at 3:22:30 am UTC+9:30, Simon Clubley wrote:
>>>>>>> DECnet is not an open specification.
>>>>>>>
>>>>>>> Parts of it are fully open (the lower-level NSP and related
>>>>>>> stuff) but
>>>>>>> most of the higher-level application protocols are fully closed.
>>>>>>>
>>>>>> So, DECnet is/was an open specification.
>>>>>>
>>>>>> Some of it can be found here:
>>>>>>
>>>>>> ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/
>>>>>>
>>>>>> The fact that the layered applications were not open does not
>>>>>> change the
>>>>>> validity of that statement.
>>>>>
>>>>> Unfortunately, a protocol which only opens its lower layers and only
>>>>> 1 or 2 of its upper layer protocols is not open in any way that could
>>>>> accurately be described as open.
>>>>>
>>>>> It would be like saying that TCP/IP is open if only everything at TCP
>>>>> level and below was fully open along with FTP and a partial Telnet
>>>>> specification while everything else in the TCP/IP stack was fully
>>>>> closed.
>>>>>
>>>>> The point of an open protocol is that you can fully implement another
>>>>> full version of it just by reading the specifications. You can do that
>>>>> with TCP/IP but you most certainly cannot do that with the subset of
>>>>> DECnet specifications that are available.
>>>>>
>>>>> Not even the MAIL protocol is documented in public. That would be like
>>>>> calling TCP/IP open while keeping the SMTP specification closed.
>>>>
>>>> A protocol is open if it itself is documented.
>>>>
>>>> Other protocols on top of it can be open or closed without
>>>> impacting that.
>>>>
>>>> There are also closed protocols on top of TCP/IP - that
>>>> does not make TCP/IP closed.
>>>>
>>>> Arne
>>>>
>>>
>>> When this started, I just knew that some would come up with that
>>> "open" word. Ya know, that word can be used in various contexts.
>>> "Open the door."  "The book is open."  And such.
>>>
>>> Regardless, the claim was "(the DECnet specification was freely
>>> available)" The claim was never "open", and definitely not "open
>>> software".  I don't know how "freely" it was, but I do know there was
>>> DECnet implementations on other than VMS.
>>>
>>
>> I have DECnet on my Linux box.  Used to connect to it using my
>> DECServer200.  And connect to both VAX and RSTS from it.
>
> That would be LAT, not DECnet, using a DECserver.  They did not
> use DECnet.  The MOP protocol is used to remotely manage DECservers.
>
> As the DECUS button said (regarding LAT on RSTS/E) -- "Better LAT/E than
> never"
>

$ man -k decnet
decnet.conf (5) - DECnet hosts file
decnet.proxy (5) - DECnet proxy file
decnetconf (8) - Simple configuration script for DECnet
dneigh (8) - DECnet Routing Information
dnetcat (1) - opens a DECnet connection
dnetd (8) - DECnet Super-server
dnetd.conf (5) - DECnet objects file
dnetinfo (8) - DECnet Routing Information
dnetnml (8) - DECnet Network Management Listener
dnetstat (1) - lists DECnet connections
dnlogin (1) - Connect as a terminal to a DECnet system
dnroute (8) - DECnet Routing Daemon
fal (8) - File Access Listener for DECnet
mount.dapfs (8) - Mount DAP filesystem over DECnet
multinet (8) - Connect to a Multinet* DECnet over IP server
phone (1) - Phone utility for DECnet
phoned (8) - DECnet phone server daemon
rmtermd (8) - Old style DECnet terminal services for Linux
sendvmsmail (8) - mail forwarder for DECnet
setether (8) - Set the ethernet address for use with DECnet
vmsmaild (8) - mail daemon for DECnet


OK, I guess. But I still have DECnet on my Linux box.

bill
Simon Clubley
2021-07-26 00:41:59 UTC
Permalink
On 2021-07-24, Arne Vajhøj <***@vajhoej.dk> wrote:
>
> A protocol is open if it itself is documented.
>
> Other protocols on top of it can be open or closed without
> impacting that.
>
> There are also closed protocols on top of TCP/IP - that
> does not make TCP/IP closed.
>

Those lower levels exist to provide services to the higher application
levels. There is an expected set of core functionality at application
level in order for a protocol to be useful and you can't call something
open if you can't implement that expected set of functionality using the
public standards.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-07-26 00:49:30 UTC
Permalink
On 7/25/2021 8:41 PM, Simon Clubley wrote:
> On 2021-07-24, Arne Vajhøj <***@vajhoej.dk> wrote:
>> A protocol is open if it itself is documented.
>>
>> Other protocols on top of it can be open or closed without
>> impacting that.
>>
>> There are also closed protocols on top of TCP/IP - that
>> does not make TCP/IP closed.
>
> Those lower levels exist to provide services to the higher application
> levels. There is an expected set of core functionality at application
> level in order for a protocol to be useful and you can't call something
> open if you can't implement that expected set of functionality using the
> public standards.

But you can implement whatever functionality you want.

It may just not be compatible with somebody elses
proprietary implementation.

Let us take TCP/IP and database access protocol. Let
us assume that Oracle's protocol is a closed while
PostgreSQL's protocol is open. Then you can implement
a PostgreSQL compatible database server or a PostgreSQL
client, but you can't do the same for Oracle.

And that means absolutely nothing for whether
TCP/IP is open or not.

Arne
Simon Clubley
2021-07-26 01:05:29 UTC
Permalink
On 2021-07-25, Arne Vajhøj <***@vajhoej.dk> wrote:
> On 7/25/2021 8:41 PM, Simon Clubley wrote:
>>
>> Those lower levels exist to provide services to the higher application
>> levels. There is an expected set of core functionality at application
>> level in order for a protocol to be useful and you can't call something
>> open if you can't implement that expected set of functionality using the
>> public standards.
>
> But you can implement whatever functionality you want.
>
> It may just not be compatible with somebody elses
> proprietary implementation.
>
> Let us take TCP/IP and database access protocol. Let
> us assume that Oracle's protocol is a closed while
> PostgreSQL's protocol is open. Then you can implement
> a PostgreSQL compatible database server or a PostgreSQL
> client, but you can't do the same for Oracle.
>
> And that means absolutely nothing for whether
> TCP/IP is open or not.
>

But they are not considered to be part of the core TCP/IP stack.

Everything that ships as part of a TCP/IP stack (including SSH,
Telnet, FTP, SMTP, etc) has a public specification that goes
with it.

However, not everything that ships as part of the DECnet stack
on VMS has a public specification that goes with it.

(And don't forget in addition that the public CTERM specification
is missing the VMS specific bits.)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-07-26 01:16:20 UTC
Permalink
On 7/25/2021 9:05 PM, Simon Clubley wrote:
> On 2021-07-25, Arne Vajhøj <***@vajhoej.dk> wrote:
>> On 7/25/2021 8:41 PM, Simon Clubley wrote:
>>>
>>> Those lower levels exist to provide services to the higher application
>>> levels. There is an expected set of core functionality at application
>>> level in order for a protocol to be useful and you can't call something
>>> open if you can't implement that expected set of functionality using the
>>> public standards.
>>
>> But you can implement whatever functionality you want.
>>
>> It may just not be compatible with somebody elses
>> proprietary implementation.
>>
>> Let us take TCP/IP and database access protocol. Let
>> us assume that Oracle's protocol is a closed while
>> PostgreSQL's protocol is open. Then you can implement
>> a PostgreSQL compatible database server or a PostgreSQL
>> client, but you can't do the same for Oracle.
>>
>> And that means absolutely nothing for whether
>> TCP/IP is open or not.
>
> But they are not considered to be part of the core TCP/IP stack.
>
> Everything that ships as part of a TCP/IP stack (including SSH,
> Telnet, FTP, SMTP, etc) has a public specification that goes
> with it.
>
> However, not everything that ships as part of the DECnet stack
> on VMS has a public specification that goes with it.
>
> (And don't forget in addition that the public CTERM specification
> is missing the VMS specific bits.)

Telnet, SSH, FTP, SMTP etc. are individual specifications - they
are not part of the specs for TCP and IP.

And they do not always come with TCP/IP.

They often do, because the specs are open and open source
implementations exist making them easy to deliver.

But being frequently bundled with does not make them
part of a protocol.

Arne
chris
2021-07-26 10:27:16 UTC
Permalink
On 07/26/21 02:16, Arne Vajhøj wrote:
> On 7/25/2021 9:05 PM, Simon Clubley wrote:
>> On 2021-07-25, Arne Vajhøj <***@vajhoej.dk> wrote:
>>> On 7/25/2021 8:41 PM, Simon Clubley wrote:
>>>>
>>>> Those lower levels exist to provide services to the higher application
>>>> levels. There is an expected set of core functionality at application
>>>> level in order for a protocol to be useful and you can't call something
>>>> open if you can't implement that expected set of functionality using
>>>> the
>>>> public standards.
>>>
>>> But you can implement whatever functionality you want.
>>>
>>> It may just not be compatible with somebody elses
>>> proprietary implementation.
>>>
>>> Let us take TCP/IP and database access protocol. Let
>>> us assume that Oracle's protocol is a closed while
>>> PostgreSQL's protocol is open. Then you can implement
>>> a PostgreSQL compatible database server or a PostgreSQL
>>> client, but you can't do the same for Oracle.
>>>
>>> And that means absolutely nothing for whether
>>> TCP/IP is open or not.
>>
>> But they are not considered to be part of the core TCP/IP stack.
>>
>> Everything that ships as part of a TCP/IP stack (including SSH,
>> Telnet, FTP, SMTP, etc) has a public specification that goes
>> with it.
>>
>> However, not everything that ships as part of the DECnet stack
>> on VMS has a public specification that goes with it.
>>
>> (And don't forget in addition that the public CTERM specification
>> is missing the VMS specific bits.)
>
> Telnet, SSH, FTP, SMTP etc. are individual specifications - they
> are not part of the specs for TCP and IP.
>
> And they do not always come with TCP/IP.
>
> They often do, because the specs are open and open source
> implementations exist making them easy to deliver.
>
> But being frequently bundled with does not make them
> part of a protocol.
>
> Arne

TCP/IP is is just one layer of a stack of networking
parts that are designed to work together, a very
elegant and well engineered design. TCP, along with UDP,
are layered above IP, ICMP and IGMP, which in turn are
layered above the data link layer and hardware at
lowest level. Above that, utilities such as ping, telnet,
ftp, tftp and X are layered. Those top level layers are
optional, but all the layers and parts below TCP and
UDP are pretty much essential for normal system operation,
a large chunk of code. All the RFC's for the spec, the
whole stack in fact, are in the public domain and have
been for decades.

Originally, all that was loosely based on an ISO model,
the sort of standards that DEC were great supporters
and contributors to at all levels, but really backed
themselves into a corner over decnet. An obscure set
of protocols and command set reminiscent of the sort of
serisl line and telco ideas dating back to the 1970's.
TCP/IP was faster, easier to visualise in design, to
program and above all, a completely open source and fixed
set of standards that anyone could use, improve and generally
contribute to.

Long term, closed source sytems are dead, other than for
specialist applications, but it will take brave vendors
to contribute their systems to the commen good, after
decades of secrecy and client lockin...








TCP/IP is is just one layer of a stack of networking
parts that are designed to work together, a very
elegant and well engineered design. TCP, along with UDP,
are layered above IP, ICMP and IGMP, which in turn are
layered above the data link layer and hardware at
lowest level. Above that, utilities such as ping, telnet,
ftp, tftp and X etc are layered. Those top level layers are
optional, but all the layers and parts below TCP and
UDP are pretty much essential for normal system operation,
a large chunk of code. All the RFC's for the spec, the
whole stack in fact, are in the public domain and have
been for decades.

Originally, all that was loosely based on an ISO model,
the sort of standards that DEC were great supporters
and contributors to at all levels, but really backed
themselves into a corner over decnet. An obscure set
of protocols and command set reminiscent of the sort of
serisl line and telco ideas dating back to the 1970's.
TCP/IP was faster, easier to visualise in design, to
program and above all, a completely open source and fixed
set of standards that anyone could use, improve and generally
contribute to.

Long term, closed source systems are dead, other than for
specialist applications, but it will take brave vendors
to contribute their systems to the common good, after
decades of secrecy and client lockin...
David Jones
2021-07-28 01:50:28 UTC
Permalink
On Monday, July 26, 2021 at 6:27:22 AM UTC-4, chris wrote:
> Originally, all that was loosely based on an ISO model,
> the sort of standards that DEC were great supporters
> and contributors to at all levels, but really backed
> themselves into a corner over decnet. An obscure set
> of protocols and command set reminiscent of the sort of
> serisl line and telco ideas dating back to the 1970's.
> TCP/IP was faster, easier to visualise in design, to
> program and above all, a completely open source and fixed
> set of standards that anyone could use, improve and generally
> contribute to.

The TCP/IP standards were developed over decades, RFC superceding RFC.
The RFC specifications often had gaps which results in conflicting implementations
by different parties, usually resolved by adopting the interpretation of the one
which has bigger presence in the rather limited ARPANET ecosystem.

Eventually it got reliable enough that V.P. Gore proposed dropping the commerce
restrictions.
chris
2021-07-28 09:45:15 UTC
Permalink
On 07/28/21 02:50, David Jones wrote:
> On Monday, July 26, 2021 at 6:27:22 AM UTC-4, chris wrote:
>> Originally, all that was loosely based on an ISO model,
>> the sort of standards that DEC were great supporters
>> and contributors to at all levels, but really backed
>> themselves into a corner over decnet. An obscure set
>> of protocols and command set reminiscent of the sort of
>> serisl line and telco ideas dating back to the 1970's.
>> TCP/IP was faster, easier to visualise in design, to
>> program and above all, a completely open source and fixed
>> set of standards that anyone could use, improve and generally
>> contribute to.
>
> The TCP/IP standards were developed over decades, RFC superceding RFC.
> The RFC specifications often had gaps which results in conflicting implementations
> by different parties, usually resolved by adopting the interpretation of the one
> which has bigger presence in the rather limited ARPANET ecosystem.
>
> Eventually it got reliable enough that V.P. Gore proposed dropping the commerce
> restrictions.

That's a rather biased, one sided view. I was using tcp/ip in the late
1980's and by then, most if not all of the unix community had a common
set of networking standards that just worked out of the box and was
reliable. Billion $ companies were created and thrived on it as well.
Even DEC had mips cpu based unix workstations and Ultrix ran on VAX,
mips and even pdpd11 hardware.

The RFC idea is still alive, as new standards emerge,but the core
networking standards were established very early and have changed
little over time.

As for Al Gore, yet another brain dead politician, though I understand
that he invented the internet over breakfast one morning?...
Dave Froble
2021-07-28 13:41:57 UTC
Permalink
On 7/28/2021 5:45 AM, chris wrote:
> On 07/28/21 02:50, David Jones wrote:
>> On Monday, July 26, 2021 at 6:27:22 AM UTC-4, chris wrote:
>>> Originally, all that was loosely based on an ISO model,
>>> the sort of standards that DEC were great supporters
>>> and contributors to at all levels, but really backed
>>> themselves into a corner over decnet. An obscure set
>>> of protocols and command set reminiscent of the sort of
>>> serisl line and telco ideas dating back to the 1970's.
>>> TCP/IP was faster, easier to visualise in design, to
>>> program and above all, a completely open source and fixed
>>> set of standards that anyone could use, improve and generally
>>> contribute to.
>>
>> The TCP/IP standards were developed over decades, RFC superceding RFC.
>> The RFC specifications often had gaps which results in conflicting
>> implementations
>> by different parties, usually resolved by adopting the interpretation
>> of the one
>> which has bigger presence in the rather limited ARPANET ecosystem.
>>
>> Eventually it got reliable enough that V.P. Gore proposed dropping
>> the commerce
>> restrictions.
>
> That's a rather biased, one sided view. I was using tcp/ip in the late
> 1980's

Well, there is your problem. In the late 1970s DECnet was a working
product. As I remember, not so for TCP/IP. I'd perhaps suggest that
you need to be a bit older, but, it's no fun, won't wish that on someone.


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
chris
2021-07-28 14:45:20 UTC
Permalink
On 07/28/21 14:41, Dave Froble wrote:
> On 7/28/2021 5:45 AM, chris wrote:
>> On 07/28/21 02:50, David Jones wrote:
>>> On Monday, July 26, 2021 at 6:27:22 AM UTC-4, chris wrote:
>>>> Originally, all that was loosely based on an ISO model,
>>>> the sort of standards that DEC were great supporters
>>>> and contributors to at all levels, but really backed
>>>> themselves into a corner over decnet. An obscure set
>>>> of protocols and command set reminiscent of the sort of
>>>> serisl line and telco ideas dating back to the 1970's.
>>>> TCP/IP was faster, easier to visualise in design, to
>>>> program and above all, a completely open source and fixed
>>>> set of standards that anyone could use, improve and generally
>>>> contribute to.
>>>
>>> The TCP/IP standards were developed over decades, RFC superceding RFC.
>>> The RFC specifications often had gaps which results in conflicting
>>> implementations
>>> by different parties, usually resolved by adopting the interpretation
>>> of the one
>>> which has bigger presence in the rather limited ARPANET ecosystem.
>>>
>>> Eventually it got reliable enough that V.P. Gore proposed dropping
>>> the commerce
>>> restrictions.
>>
>> That's a rather biased, one sided view. I was using tcp/ip in the late
>> 1980's
>
> Well, there is your problem. In the late 1970s DECnet was a working
> product. As I remember, not so for TCP/IP. I'd perhaps suggest that you
> need to be a bit older, but, it's no fun, won't wish that on someone.
>
>

Fwir, decnet in the 1970's was via serial lines, so not exactly
networking as most would understand the term to mean. It's not
about bragging rights though. Old ideas become redundant as
the art progresses. Nothing stays the same, nor lasts forever
and we are all standing on the shoulders of giants etc.

As for older, very much wrinkly here, but make no apologies for
that. Electronics and computing have been a fun ride and helped
keep me afloat for decades and am grateful for that...
Simon Clubley
2021-07-28 17:16:13 UTC
Permalink
On 2021-07-28, Dave Froble <***@tsoft-inc.com> wrote:
> On 7/28/2021 5:45 AM, chris wrote:
>>
>> That's a rather biased, one sided view. I was using tcp/ip in the late
>> 1980's
>
> Well, there is your problem. In the late 1970s DECnet was a working
> product. As I remember, not so for TCP/IP. I'd perhaps suggest that
> you need to be a bit older, but, it's no fun, won't wish that on someone.
>

2780 (and 3780) existed before that. What's your point ? :-)

Oh, and IBM beat DEC by several years with SNA, but you don't see
that in general use either. :-)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2021-07-28 17:31:41 UTC
Permalink
On 2021-07-28, Bill Gunshannon <***@gmail.com> wrote:
>
> One really has to wonder why, if it had a decade head start OSI (aka
> DECnet) never acquired the capabilities of TCP/IP. Why is the Internet
> TCP/IP based and not OSI?
>

DECnet was not OSI.

DECnet Phase V (which very few people apparently use) implemented the
OSI protocols after they had already been developed elsewhere.

BTW, early Internet protocols had already existed for a decade before
what we recognise as today's TCP, IP, and UDP were released in the very
early 1980s so they were an incremental development of what already
existed instead of something new.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John Wallace
2021-07-28 17:45:21 UTC
Permalink
On 28/07/2021 17:26, Bill Gunshannon wrote:
> On 7/28/21 9:41 AM, Dave Froble wrote:
>> On 7/28/2021 5:45 AM, chris wrote:
>>> On 07/28/21 02:50, David Jones wrote:
>>>> On Monday, July 26, 2021 at 6:27:22 AM UTC-4, chris wrote:
>>>>> Originally, all that was loosely based on an ISO model,
>>>>> the sort of standards that DEC were great supporters
>>>>> and contributors to at all levels, but really backed
>>>>> themselves into a corner over decnet. An obscure set
>>>>> of protocols and command set reminiscent of the sort of
>>>>> serisl line and telco ideas dating back to the 1970's.
>>>>> TCP/IP was faster, easier to visualise in design, to
>>>>> program and above all, a completely open source and fixed
>>>>> set of standards that anyone could use, improve and generally
>>>>> contribute to.
>>>>
>>>> The TCP/IP standards were developed over decades, RFC superceding RFC.
>>>> The RFC specifications often had gaps which results in conflicting
>>>> implementations
>>>> by different parties, usually resolved by adopting the interpretation
>>>> of the one
>>>> which has bigger presence in the rather limited ARPANET ecosystem.
>>>>
>>>>   Eventually it got reliable enough that  V.P. Gore proposed dropping
>>>> the commerce
>>>> restrictions.
>>>
>>> That's a rather biased, one sided view. I was using tcp/ip in the late
>>> 1980's
>>
>> Well, there is your problem.  In the late 1970s DECnet was a working
>> product.
>
> A working product that only worked on a very small subset of computers
> in use at the time and with little or no long distance capabilities.
>
>>           As I remember, not so for TCP/IP.  I'd perhaps suggest that
>> you need to be a bit older, but, it's no fun, won't wish that on someone.
>
> One really has to wonder why, if it had a decade head start OSI (aka
> DECnet) never acquired the capabilities of TCP/IP.  Why is the Internet
> TCP/IP based and not OSI?
>
> bill
>
>

The internet is still largely IPv4 based, even though IPv6 has allegedly
been around almost as long as OSI implementations.

Retail ISPs back then liked cheap stuff and cheap staff. Mostly they
still do. IPv4 was cheap. Browsers were cheap. Expertise and training?
Hmmm, no, we don't do that, it costs too much.

IPv4 is still cheap (for ISPs). IPv4's ongoing impact on end users
varies, but apparently things like CGNAT (widely seen in the mobile
world) are not much fun for end users who want to go slightly off
mainstream.

In the user-visible world, insecure browsers (and insecure email, and
...) are now a huge contributor to IT insecurity. But never mind,
Tikstabook will sort it. Perhaps.

Also at the application level, prior to proprietary non-standards-based
web-GUI-based email taking over the world, the main setup that the IP
world could offer was a teletype-era mail setup (POP/SMTP) which needed
dozens of band-aids to be added before it was actually anything like
usable, especially in a multiplatform environment. That's before we even
get into "advanced" higher-layer topics like authentication,
authorization, and optional extras such as (e.g. for email) secure
delivery, non-repudiation, etc.

Still I guess some people must see it as progress.
Simon Clubley
2021-07-28 18:00:32 UTC
Permalink
On 2021-07-28, John Wallace <***@yahoo.co.uk> wrote:
>
> The internet is still largely IPv4 based, even though IPv6 has allegedly
> been around almost as long as OSI implementations.
>

IPv6 was designed by committee. IPv4 protocols were designed by small
groups of engineers (at least in the formative years) with a pragmatic
approach.

IPv6 would have been accepted more easily if it was IPv4 + more addressing
space (with IPv4 addresses living directly within an IPv6 network in a
compatible way) and it had been left at that.

>
> In the user-visible world, insecure browsers (and insecure email, and
> ...) are now a huge contributor to IT insecurity. But never mind,
> Tikstabook will sort it. Perhaps.
>

Yes, but unfortunately this has nothing to do with the network protocols
in use underneath the web browser.

> Also at the application level, prior to proprietary non-standards-based
> web-GUI-based email taking over the world, the main setup that the IP
> world could offer was a teletype-era mail setup (POP/SMTP) which needed
> dozens of band-aids to be added before it was actually anything like
> usable, especially in a multiplatform environment. That's before we even
> get into "advanced" higher-layer topics like authentication,
> authorization, and optional extras such as (e.g. for email) secure
> delivery, non-repudiation, etc.
>
> Still I guess some people must see it as progress.

It is progress compared to the more limited security stuff you can
do with VMS networking outside of those protocols.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-07-28 18:32:19 UTC
Permalink
On 7/28/2021 12:26 PM, Bill Gunshannon wrote:
> On 7/28/21 9:41 AM, Dave Froble wrote:
>> On 7/28/2021 5:45 AM, chris wrote:
>>> On 07/28/21 02:50, David Jones wrote:
>>>> On Monday, July 26, 2021 at 6:27:22 AM UTC-4, chris wrote:
>>>>> Originally, all that was loosely based on an ISO model,
>>>>> the sort of standards that DEC were great supporters
>>>>> and contributors to at all levels, but really backed
>>>>> themselves into a corner over decnet. An obscure set
>>>>> of protocols and command set reminiscent of the sort of
>>>>> serisl line and telco ideas dating back to the 1970's.
>>>>> TCP/IP was faster, easier to visualise in design, to
>>>>> program and above all, a completely open source and fixed
>>>>> set of standards that anyone could use, improve and generally
>>>>> contribute to.
>>>>
>>>> The TCP/IP standards were developed over decades, RFC superceding RFC.
>>>> The RFC specifications often had gaps which results in conflicting
>>>> implementations
>>>> by different parties, usually resolved by adopting the interpretation
>>>> of the one
>>>> which has bigger presence in the rather limited ARPANET ecosystem.
>>>>
>>>> Eventually it got reliable enough that V.P. Gore proposed dropping
>>>> the commerce
>>>> restrictions.
>>>
>>> That's a rather biased, one sided view. I was using tcp/ip in the late
>>> 1980's
>>
>> Well, there is your problem. In the late 1970s DECnet was a working
>> product.
>
> A working product that only worked on a very small subset of computers
> in use at the time and with little or no long distance capabilities.

As I recall, there just wasn't much of any long distance capabilities.
I remember dedicated lines, and the huge cost. Don't judge the past by
today's capabilities.

>> As I remember, not so for TCP/IP. I'd perhaps suggest that
>> you need to be a bit older, but, it's no fun, won't wish that on someone.
>
> One really has to wonder why, if it had a decade head start OSI (aka
> DECnet) never acquired the capabilities of TCP/IP. Why is the Internet
> TCP/IP based and not OSI?

Don't get the wrong idea. I'm not proposing DECnet as a better product.
It was and is a good product for the time in which it was developed
and used. But it never became universal. Not sure why? Doesn't
matter, TCP/IP works, and works almost everywhere.

My only problem is people today knocking older stuff that perhaps was
bleeding edge when developed, but perhaps no continuing development, or,
something better (or more universal) came along. Doesn't make the older
stuff bad, just outdated.

Now OSI, nothing good ever came out of a committee, and the more
members, the worse the product.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-07-29 12:53:50 UTC
Permalink
On 2021-07-28, Dave Froble <***@tsoft-inc.com> wrote:
>
> Don't get the wrong idea. I'm not proposing DECnet as a better product.
> It was and is a good product for the time in which it was developed
> and used. But it never became universal. Not sure why? Doesn't
> matter, TCP/IP works, and works almost everywhere.
>
> My only problem is people today knocking older stuff that perhaps was
> bleeding edge when developed, but perhaps no continuing development, or,
> something better (or more universal) came along. Doesn't make the older
> stuff bad, just outdated.
>

The reason why I compare DECnet to today's standards instead of those
of 30 years ago is because there are people here in 2021 who are deluded
enough to think that DECnet is somehow comparable to the networking
stacks of today, both in functionality and security.

That's why DECnet gets compared by me to those same stacks of today
(and is promptly found by me to be massively lacking compared to
modern networking stacks).

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-07-29 15:07:33 UTC
Permalink
On 7/29/2021 8:53 AM, Simon Clubley wrote:
> On 2021-07-28, Dave Froble <***@tsoft-inc.com> wrote:
>>
>> Don't get the wrong idea. I'm not proposing DECnet as a better product.
>> It was and is a good product for the time in which it was developed
>> and used. But it never became universal. Not sure why? Doesn't
>> matter, TCP/IP works, and works almost everywhere.
>>
>> My only problem is people today knocking older stuff that perhaps was
>> bleeding edge when developed, but perhaps no continuing development, or,
>> something better (or more universal) came along. Doesn't make the older
>> stuff bad, just outdated.
>>
>
> The reason why I compare DECnet to today's standards instead of those
> of 30 years ago is because there are people here in 2021 who are deluded
> enough to think that DECnet is somehow comparable to the networking
> stacks of today, both in functionality and security.
>
> That's why DECnet gets compared by me to those same stacks of today
> (and is promptly found by me to be massively lacking compared to
> modern networking stacks).
>
> Simon.
>

Yeah, well so is that "sorta round" rock the caveman chipped. So,
what's your point?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-07-29 17:20:21 UTC
Permalink
On 2021-07-29, Dave Froble <***@tsoft-inc.com> wrote:
>
> Yeah, well so is that "sorta round" rock the caveman chipped. So,
> what's your point?
>

The point is, if you say something from a previous generation is
comparable to what is available today, then that's the standard
you are going to be judged by.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-07-29 19:10:43 UTC
Permalink
On 7/29/2021 1:20 PM, Simon Clubley wrote:
> On 2021-07-29, Dave Froble <***@tsoft-inc.com> wrote:
>>
>> Yeah, well so is that "sorta round" rock the caveman chipped. So,
>> what's your point?
>>
>
> The point is, if you say something from a previous generation is
> comparable to what is available today, then that's the standard
> you are going to be judged by.

Who says that? Not me. I'm more into asking don't compare apples and
oranges.


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-07-28 17:47:59 UTC
Permalink
On 2021-07-28, chris <chris-***@tridac.net> wrote:
>
> The RFC idea is still alive, as new standards emerge,but the core
> networking standards were established very early and have changed
> little over time.
>

However, all layers of the TCP/IP stack have had a solid workout from
a security point of view and things have been changed as issues have
been discovered.

I see no evidence that DECnet has had that level of probing.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
gah4
2021-07-28 18:55:22 UTC
Permalink
On Wednesday, July 28, 2021 at 2:45:18 AM UTC-7, chris wrote:

(snip)

> As for Al Gore, yet another brain dead politician, though I understand
> that he invented the internet over breakfast one morning?...

I almost remember the time before ...

When there were .COM, but it wasn't allowed for messages
(e-mail, ftp, telnet, anything) between two .COM sites.

Government and academic users were allowed to connect to them.
And also, much of the long distance lines were on 56K bit/s leased lines.

And yes, with Al Gore in the lead, the Internet as we know it, starting with
much government funding, and later more commercial networks forming.
Scott Dorsey
2021-07-29 01:51:56 UTC
Permalink
chris <chris-***@tridac.net> wrote:
>
>That's a rather biased, one sided view. I was using tcp/ip in the late
>1980's and by then, most if not all of the unix community had a common
>set of networking standards that just worked out of the box and was
>reliable. Billion $ companies were created and thrived on it as well.
>Even DEC had mips cpu based unix workstations and Ultrix ran on VAX,
>mips and even pdpd11 hardware.

In the commercial world everybody had x.25 and it just worked right out
of the box too (unless you had a Pr1me or a CDC).

Although I remembered when everything stopped to change ip versions.
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Scott Dorsey
2021-07-29 01:53:51 UTC
Permalink
Bill Gunshannon <***@gmail.com> wrote:
>
>One really has to wonder why, if it had a decade head start OSI (aka
>DECnet) never acquired the capabilities of TCP/IP. Why is the Internet
>TCP/IP based and not OSI?

Because OSI was plagued with huge committees of people who couldn't
agree on anything.

I took a class with Philip Enslow who was a huge promoter of the OSI model
but he spent most of his time promoting it to the other people on the
committee with him.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Dave Froble
2021-07-26 01:08:23 UTC
Permalink
On 7/25/2021 8:41 PM, Simon Clubley wrote:
> On 2021-07-24, Arne Vajhøj <***@vajhoej.dk> wrote:
>>
>> A protocol is open if it itself is documented.
>>
>> Other protocols on top of it can be open or closed without
>> impacting that.
>>
>> There are also closed protocols on top of TCP/IP - that
>> does not make TCP/IP closed.
>>
>
> Those lower levels exist to provide services to the higher application
> levels. There is an expected set of core functionality at application
> level in order for a protocol to be useful and you can't call something
> open if you can't implement that expected set of functionality using the
> public standards.
>
> Simon.
>

I'm pretty sure if you're naming a product, you could call it just about
anything you want to call it. Even "Open Software". I'm guessing that
"name" hasn't been copyrighted ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2021-07-25 20:41:03 UTC
Permalink
On 7/25/21 4:16 PM, Phillip Helbig (undress to reply) wrote:
> In article <sdh8uv$6kd$***@dont-email.me>, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> Unfortunately, a protocol which only opens its lower layers and only
>> 1 or 2 of its upper layer protocols is not open in any way that could
>> accurately be described as open.
>>
>> It would be like saying that TCP/IP is open if only everything at TCP
>> level and below was fully open along with FTP and a partial Telnet
>> specification while everything else in the TCP/IP stack was fully closed.
>>
>> The point of an open protocol is that you can fully implement another
>> full version of it just by reading the specifications. You can do that
>> with TCP/IP but you most certainly cannot do that with the subset of
>> DECnet specifications that are available.
>>
>> Not even the MAIL protocol is documented in public. That would be like
>> calling TCP/IP open while keeping the SMTP specification closed.
>
> There are lies, damn lies, and open systems.
>

Which makes it even more interesting that the Linux DECnet subsystem
has commands for doing DECnet MAIL.

bill
Simon Clubley
2021-07-26 00:24:22 UTC
Permalink
On 2021-07-25, Phillip Helbig (undress to reply) <***@asclothestro.multivax.de> wrote:
>
> There are lies, damn lies, and open systems.
>

If open systems are so bad, then why is so much of the technology
making its way into VMS ?

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-07-26 01:15:54 UTC
Permalink
On 7/25/2021 8:24 PM, Simon Clubley wrote:
> On 2021-07-25, Phillip Helbig (undress to reply) <***@asclothestro.multivax.de> wrote:
>>
>> There are lies, damn lies, and open systems.
>>
>
> If open systems are so bad, then why is so much of the technology
> making its way into VMS ?
>
> Simon.
>

Gee, can we first define "open systems" ???

Don't know about you limeys, (thought we were using a similar language)
but I don't read anything above that makes any claims about good, bad,
indifferent, ...

As to why some things are being implemented on VMS, it's a connected
world, for better or worse, and if one wishes to exist in such a world,
they need to have the tools that support such connectivity.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
chris
2021-07-26 10:43:59 UTC
Permalink
On 07/26/21 02:15, Dave Froble wrote:
> On 7/25/2021 8:24 PM, Simon Clubley wrote:
>> On 2021-07-25, Phillip Helbig (undress to reply)
>> <***@asclothestro.multivax.de> wrote:
>>>
>>> There are lies, damn lies, and open systems.
>>>
>>
>> If open systems are so bad, then why is so much of the technology
>> making its way into VMS ?
>>
>> Simon.
>>
>
> Gee, can we first define "open systems" ???
>
> Don't know about you limeys, (thought we were using a similar language)
> but I don't read anything above that makes any claims about good, bad,
> indifferent, ...
>
> As to why some things are being implemented on VMS, it's a connected
> world, for better or worse, and if one wishes to exist in such a world,
> they need to have the tools that support such connectivity.
>

As applied to software or operating systems, any product where all the
source code, design documentation and build information is available
without restriction for anyone to use, modify, spin off variations at
no substantial cost.

"Open"VMS never did qualify for that description, though there were some
signs of movement in the general direction...
Simon Clubley
2021-07-26 17:36:39 UTC
Permalink
On 2021-07-25, Dave Froble <***@tsoft-inc.com> wrote:
> On 7/25/2021 8:24 PM, Simon Clubley wrote:
>> On 2021-07-25, Phillip Helbig (undress to reply) <***@asclothestro.multivax.de> wrote:
>>>
>>> There are lies, damn lies, and open systems.
>>>
>>
>> If open systems are so bad, then why is so much of the technology
>> making its way into VMS ?
>>
>
> Gee, can we first define "open systems" ???
>
> Don't know about you limeys, (thought we were using a similar language)

We've talked about that David. :-) We only gave you your language, we are
not responsible for what you did to it. :-)

> but I don't read anything above that makes any claims about good, bad,
> indifferent, ...
>

It's Phillip. :-) VMS is far better than open source to him (although
while at the same time as saying that, he also wants someone to port
one of the open source browsers to VMS... :-))

> As to why some things are being implemented on VMS, it's a connected
> world, for better or worse, and if one wishes to exist in such a world,
> they need to have the tools that support such connectivity.
>

Exactly.

Simon.

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