[Info-vax] DECnet Phase IV and VMS code comments

[Stephen Hoffman]

On 2016-11-29 19:24:35 +0000, David Froble said:

> Stephen Hoffman wrote:
>> On 2016-11-29 13:25:01 +0000, Simon Clubley said:
>> 
>>> On 2016-11-28, Kerry Main <kemain.nospam at gmail.com> wrote:
>>>> 
>>>> I don't think anyone here views 35+ year old DECnet as a strategic 
>>>> network product.
>>> 
>>> ...I only care about the fact that it's still available and enabled on 
>>> VMS systems running today...
>> 
>> Which is why I'd prefer to see telnet, FTP, DECnet and other giblets 
>> with explicit security warnings and requiring the system manager to 
>> override those to enable the mechanisms.   Or entirely removed, and an 
>> extra-cost add on.
>> 
>> In short, far less DECnet integration with OpenVMS.   Vastly better IP 
>> integration.  TLS and certificate integration, too.   It's long past 
>> time to update what was started with OpenVMS V6.2.
>> 
>> Keeping utterly broken designs and interfaces around and accessible 
>> "for compatibility" is short-sighted and hazardous, at best.   But then 
>> I'm being polite.   Customers will always want to avoid making changes, 
>> but they can and do need to make at least some.    Customers — most of 
>> them — aren't experts in this sort of stuff, and what is available is 
>> hard to use, variously not used, and is poorly integrated.   Even 
>> within OpenVMS itself.  Which is why we still see configurations where 
>> DECnet, telnet and FTP are commonly used, if not the primary network 
>> transports...   Which means folks can get shellacked — and do, and have 
>> gotten shellacked, and without attackers bothering to use ROP or 
>> needing to bypass ASLR or otherwise...
> 
> I agree about doing better today.  However, I'm a bit aware that there 
> are people using VMS for things that I've never imagined.  For example, 
> John Wallace has mentioned factory controls that use the OSI stuff, (I 
> seem to recall), and therefore doing away with DECnet V might push such 
> people away from VMS.  I'll bet there are more such instances.

Sure.  Platform vendors are faced with these sorts of decisions.   
Protect the installed base and applications entirely, or provide 
extensive compatibility and force some specific application changes 
where specifically necessary, or overhaul the platform and watch more 
than a few folks migrate elsewhere.   But the seemingly-safest approach 
— rote upward-compatibility — means the vendor cannot fix actual latent 
problems, and new system APIs and designs only get worse and 
progressively more convoluted and more complex and more costly to 
implement and deploy.

The lattermost choice — rewriting everything — is a non-starter for 
many cases, or a nervy and rather longer-term business play.   Work 
such as HPE and The Machine lurks here, assuming it ships and meets or 
exceeds expectations and can be adopted by enough folks.   But — much 
like the existing Bliss, Macro32 and C source code continues to exist 
within OpenVMS — I just don't see OpenVMS development performing this 
sort of a rewrite, or requiring extensive customer rewrites.  Nor most 
any other large software platform or major application, for that matter.

Which leaves the middle path of the three — forcing targeted upgrades 
of applications using problematic interfaces and approaches, as — when 
correctly managed and when the reasons and benefits for the changes are 
clearly communicated — the cost of that remains lower than porting the 
applications elsewhere.   No amount of compatibility can fix 
fundamentally broken or insecure interfaces.   Preferably these changes 
with a migration path to the newer APIs or transports or mechanisms, a 
migration plan and window and deprecation plans, and the necessity and 
the accrual of defined benefits for the effort involved.

Costly?   64-bit addressing is an impressive and upward-compatible 
design, but writing new native 64-bit applications increasingly reminds 
me of working on RSX-11M with its memory addressing shenanigans.    
Flat address spaces are what made VAX so much nicer than PDP-11, after 
all.   This sort of complexity means more costs for everybody, when 
you're forced to work within these upward-compatible designs, or when 
you're faced with APIs and mechanisms which are known to be problematic 
or insecure — the password hash, the use of MD5, etc — that are still 
around for compatibility.

I don't like changing my application code.  None of us do, after all.  
But it's sometimes necessary.

This is a form of the game of "chicken".  Making changes necessary to 
better secure or to simplify or otherwise improve the system or the 
platform, trading off the risks the loss of some customers that might 
choose not to follow your changes, as compared with the folks that 
might want or need the changes.  Now if you aren't planning to try to 
expand the installed base and the folks are mostly-happy with what they 
have, then this whole discussion gets a whole lot easier.   But some 
number of folks have or find reasons to port.   Which means the 
long-term revenue trends just aren't in a good direction.  Which can 
make some of the current customers... nervous, too.   Running a 
business, there's no single right answer.   Lots of wrong ones, though.

> That written, today there just isn't much use for DECnet, and there is 
> a use for IP, an IP that supports all (or most) of the DECnet 
> utilities.  As you've suggested, tie the stuff tightly to the OS, and 
> make it easy to use, and include security.
> 
> So, if any work is to be done in this direction, much better to 
> allocate the resources to implementing the DECnet utilities that are 
> useful using IP.

Ayup.   Which is part of why I've been having difficulty wrapping my 
head around the EDT work, too.


-- 
Pure Personal Opinion | HoffmanLabs LLC