🚀 go-pugleaf

In <4b8742f6.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin)
writes:

>>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.

I agree, however there may be others following this dialogue who still hang
in the balance. In my previous posting (and I do realize that it is more
than a bit confusing as to who is posting -- we have a bit of a problem with
our news feed) there were a number of issues that the Netwise RPC Tool solves
through customization (for example asynchronous RPC) that you have done a fair
amount of hand waving about. As you have stated, threads will provide a way
to do asynchronous RPC (for environments that support threads), but you also
seem to believe that asynchronous RPC is blasphemous (i.e. your religion
says that it is a bad thing). You really can't have it both ways. And though 
threads will provide a method to accomplish async, it is clearly a much less
straightforward mechanism for an application programmer to use. This is one of 
the reasons that I believe customization is by and large a good thing. The 
Netwise tool does not inflict its users with the biases of the tool designers.

>>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.

So, to paraphrase, the authentication and privacy features of NCS 2.0 are
hardcoded. They could be changed by you folks if Kerberos doesn't make it 
as a standard, but application developers (i.e. customers who buy NCS) are
stuck with it. I would not try to claim that there is something inherently
wrong with Kerberos, but if some developer has a legitimate problem with it
(perhaps because it uses the DES), and they are working under NCS 2.0, they are
stuck ... true? I suppose if an NCS user really had to change it for their own
reasons, they could buy the NCS source and replace the Kerberos module...

In addition, I think it would be more fair to say that modularizing the 
Kerberos portion of NCS is a standard engineering decision. I think that most 
folks in this day and age would be flabbergasted that a conceptually seperate 
portion of the system was not put into a seperate module.

>>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.

Am I missing something here? Isn't UDP a CL transport protocol that is used
by a fair number of current applications (including NFS which is likely the
most widely used RPC application in the world today)? Aren't there provisions
for a CLTP in the OSI reference model? I think that there are those who would
disagree about _only_ having a COTP (which may be stretching your statement a
bit).

>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.

But again, you folks are constraining the choices of your customers. There are
distinct sets of advantages and disadvantages to CO vs. CL transports and the
NCS product allows only the set for CO transports. BTW, if the home-brew CO
transport over UDP is so much better than TCP, why didn't you folks stay with
that for NCS 2.0 rather than adding TCP support?

With the Netwise approach, you get (in effect) _both_ CL and CO RPC and allow 
user of the tool to decide for themselves which of these two options is 'best'
for their application. If a user wishes the advantages of a CL RPC (largely
reduced overhead) and is willing to pay the price that implies (lost messages, 
etc.), they should have the opportunity to make that decision. Clearly there 
exist applications that will benefit from this.

My overall impression of NCS is that it is largely a 'do it our way' system.
The NCS designers made decisions about what RPC should be and how it should 
operate and that these are the only allowable ways to do RPC within NCS. In
my experience in dealing with customers, this simply will not work. These
folks have their own ideas about how RPC should work and they intend to use
it that way. Trying to convince them that certain things are not religiously
correct is a futile exercise. A much better alternative is to give users the
flexibility to decide for themselves and (as much as possible) to warn them
about potential problems with their approach. In the end, C programmers (as
opposed to Pascal programmers) are used to doing things their way even though
there is some (perhaps great) danger associated with it and IMHO this is as
it should be.

------------------------------------------------------------------------------
The verbiage above does not neccesarily reflect the views of my employer or
client (Netwise).

jake edge - L & E Technologies, Inc. 2888 Bluff St. Suite 142 Boulder, CO 80302 
    Ma Bell: (303) 440-1142                     UUCP: ...!onecom!wldrdg!jake