🚀 go-pugleaf

In <1990Jul10.225103.20551@athena.mit.edu> pae@athena.mit.edu (Philip Earnhardt) writes:
>> I understand your position and I don't know that there's much point
>> arguing about the relative merits of customization.  We simply disagree.
>
>This seems to be a bit of a 'back-off' from your previous postings ... are
>we calling it a draw (i.e. yes there are dangers in customization and yes
>there are instances where they are neccesary)?

No.  I am simply not interested in trying to convince you any more that
customization is a bad idea.  I believe (a) that you strongly believe that
it's a good idea, and (b) that I'm not going to change your mind.

>> Authentication and privacy features are part of NCS 2.0.
>
>Maybe I am misunderstanding here, but it sounds like you are saying that NCS 2.0
>will provide methods for authentication and for privacy that are 'hardcoded' 
>into the system. If (for some reason) a customer has their own method that they
>wish to use (i.e. their own encryption scheme) they will not be able to use it
>and that instead they must use the method provided by NCS 2.0 ... am I jumping
>to conclusions?

The authentication facilities of NCS 2.0 are modularized in a way that
permits their replacement.  I'm sure someone will jump up and down and
say "So you do have customization!" so I guess I might as well address
it now.  While there seems to be a strong movement to MIT Project
Athena's Kerberos system (which is what NCS 2.0 works with), we (the
NCS developers) are not empowered by anyone (not even ourselves :-) to
declare that this is the one that everyone will eventually use.  In case
Kerberos doesn't become a standard (based on the OSF DCE RFT decision,
it *is* now an OSF standard) or in case someone really wants to use
something else, we arranged that the Kerberos piece can be removed and
another one plugged in.  We DO NOT consider this something that would
be done by application developers.  We consider our design as a safety
net in case things don't go in the way we have high confidence they will
go.  It's not very useful if everyone in a single environment is
not using the same authentication mechanism (protocol, key distribution
center, etc.).  For these reasons, we think of the design of NCS's 
authentication component as a good engineering decision, not as the
creation of a general customization facility.

>BTW, in some hallway discussions that we have had around here, the concept of
>uniform transport behavior (sp?) has come up and it leaves me a bit puzzled. 
>From my (perhaps somewhat limited) understanding of the current thinking in the 
>networking community, there appear to be two camps, connection-oriented and
>connection-less (thus the CO/CL split in the OSI) and what uniform transport
>behavior in effect does is to come down clearly in the CO camp. (i.e. whether
>the transport is CO or CL is unimportant (except in the case of broadcast) as
>NCS establishes a CO protocol in either case). Is this the intent? The Netwise
>approach is to have uniform CO transport behavior and uniform CL transport 
>behavior and to therefore recognize this fundamental split ... I am curious
>as to your thinking on this.

I don't know about your "two camp" notion.  If two camps are present
anywhere, it's at the network layer:  some people think it's important
to have CL network protocols (like IP) and some people don't think it's
so important (and are happy to have [only] a CO network protocol).  No
one disagrees about the need for CO transport protocols.

No one thinks that the behavior of a particular transport protocol (e.g.,
TCP) should vary as a function of what (allowed) network protocol it
runs on top of.  I.e., if someone were to make a TCP that ran over OSI
CLNP (a not unthinkable scenario), I think people would be pretty annoyed
if you (a) didn't make it reliable (in the way people generally think
of TCP/IP as being reliable), and (b) you advertised your software as
being TCP.  Similarly, our feeling is that people would be annoyed at
someone's advertising something as "being RPC" yet making its behavior
a function of some lower level network protocol choices.
                    -- Nat Mishkin
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com