[Info-vax] What would you miss if DECnet got the chop? Was: "bad select 38" (OpenSSL on VMS)

[Dirk Munk]

Jan-Erik Soderholm wrote:
> Den 2016-10-03 kl. 12:30, skrev Dirk Munk:
>> Jan-Erik Soderholm wrote:
>>> Den 2016-10-03 kl. 09:12, skrev Dirk Munk:
>>>> Michael Moroney wrote:
>>>>> David Froble <davef at tsoft-inc.com> writes:
>>>>>
>>>>>> Dirk Munk wrote:
>>>>>
>>>>>>> The DEC/HP way of DECnet over IP is not only offering DECnet over
>>>>>>> IP,
>>>>>>> but also OSI over IP (you can look at DECnet as just another OSI
>>>>>>> application). It is covered by three RFC's, RFC1006, RFC1859, and
>>>>>>> RFC2126, the latter is for IPv6.
>>>>>>>
>>>>>>> Both versions of DECnet over IP are incompatible.
>>>>>>>
>>>>>>> Now my simple question is, what should VSI offer, two incompatible
>>>>>>> versions of DECnet over IP?
>>>>>
>>>>>> If you look up thread at Michael Moroney's post, you'll see the
>>>>>> reality.  He got
>>>>>> DECnet built, but that's all the time VSI is going to put into
>>>>>> DECnet.
>>>>>
>>>>>> What you see today is all that you're ever going to see, with the
>>>>>> understanding
>>>>>> of "never say never".  Your question(s) are already answered.  Not
>>>>>> that
>>>>>> you're
>>>>>> going to like the answer(s).
>>>>>
>>>>> Without looking into it, I would assume OSI over IP is just another
>>>>> user
>>>>> of IP and it "should work" with Multinet/the VSI IP.  But perhaps the
>>>>> DECnet V people conspired with the DEC TCPIP people to use an
>>>>> undocumented
>>>>> interface.  But we should already know the answer.  Does DECnet-Plus
>>>>> over
>>>>> IP work at all with the current Multinet implementation?
>>>>
>>>> According to the DECnet-Plus SPD, only the HP IP stack is supported. It
>>>> does not explicitly say that no other IP stack works of course.
>>>>
>>>> DECnet-Plus relies on the PWIP driver, it must be loaded.
>>>>
>>>> DECnet-plus at present uses RFC1006 and RFC1859. For DECnet-Plus to use
>>>> IPv6, RFC2126 should also be implemented.
>>>
>>> It would surprice me a lot to see any such new development.
>>>
>>>
>> Suppose a company has...
>
> And that is the real point here.  One can make up just about
> any scenario, but the questsions is still how relevant that is.
>
> I guess that VSI will not "suppose" anything, but actually asks
> those that will pay for their future existance.
>
>> software (RdB for instance) that heavily relies on DECnet.
>
> Rdb (as such) doesn't rely on DECnet. Yes, there are remote DECnet
> interfaces but there are also remote TCPIP interfaces.
>
>
>> It went from Phase IV to Phase V without changing the software. It
>> went from Phase V with CLNS transport to Phase V over IPv4, no change in
>> the application. And now that company wants to move from IPv4 to IPv6.
>>
>> And now you're telling that company to stay with IPv4, or to completely
>> redesign their software around plain IP, or to forget their application
>> (and VMS?)
>>
>> Or a company is using OSI functionality over IPv4,they can forget
>> about OSI
>> if the network changes from IPv4 to IPv6?
>>
>> And all of that because a 20 year old RFC should not be implemented
>> according to you?
>
> I did not say that it "should not", I said that I'd be surprised to see
> any such new development on DECnet. I'd be happy to be surprised... :-)
>
> But then again, I'm sure that VSI will make its decisions based on
> what their (future) paying customers asks for.
>
The main problem with VMS these last decades was that nothing was done 
properly.

TCP/IP had a half-baked interface with partly a VMS UI, and partly a 
Unix UI.

IPv6 was there, but with a rudimentary implementation.

iSCSI was there, and it was withdrawn again.

And so on.

If you want to do something, do it right, not half-baked. If you're 
going to have a proper IPv6 implementation, then have a proper 
DECnet/OSI over IPv6 implementation as well. The RFC is there, it has to 
be implemented. No more half-baked stuff.