Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!bloom-beacon!pae
From: pae@athena.mit.edu (Philip Earnhardt)
Newsgroups: comp.protocols.misc
Subject: RPC Technologies
Message-ID: <1990Aug9.180750.5568@athena.mit.edu>
Date: 9 Aug 90 18:07:50 GMT
Sender: Jake Edge (onecom!wldrdg!jake)
Organization: L & E Technologies
Lines: 74

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

>>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...
>
>At worst.  If the demand appeared to exist, I suppose we could document
>the interface between the authentication module and the rest of NCS.
>This would allow people to write authentication modules without having
>the source to NCS.

I'd rather not beat a dead horse, but ... this would then allow customization
by application developers ... clearly a limited form of customization (as
the 'RPC protocol' would presumably be left intact).  Which leaves open the
question of what other sections of NCS may need to be 'customized' by the
end user.  I do not believe that you would claim that you have thought of
all possible applications of NCS and therefore you could not have included
all things that the users may find neccesary.  For this reason, Netwise-style
customizations, while not allowing all possible customizations, certainly 
allows the users a great deal more flexibility in building their applications.

>>But again, you folks are constraining the choices of your customers. 
>
>As does the C compiler writer who chooses to make his compiler save
>registers on ALL procedure calls, not just on those generated by a
>compiler targeted for a particular hardware architecture.

This is a very odd defense.  To defend constraining your customers by pointing
the finger at other folks who have done so in the past is ludicrous.

>In NCS, we achieve
>the analogous optimization by telling people to declare a procedure to
>be "idempotent".  Idempotence is a property of a procedure, not a network
>transport protocol.  Since we're dealing in remote PROCEDURE calls, this
>seems like the more appropriate abstraction.

And if one of your customers chooses to use NCS/TCP, what will declaring
a procedure as idempotent do for them?  Specifically what optimizations will
be applied?

>>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.
>
>We've been over this again and again.  People don't want "CL and CO RPC".
>They want RPC.  They want to make certain performance tradeoffs made
>available to them.  NCS addresses this desire in an appropriate way.

I am not sure how you can make such a sweeping generalization. Is this the 
result of some HP marketing survey or do you believe that just by saying it,
you can make it true?

Nat, in going over the most recent postings from both sides, the signal to
noise ratio appears to be decreasing dramatically (Chuck McManis' encouragement
notwithstanding) ... shall we try to keep it to a more technical level? (This
posting was done with that intent)

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