Path: utzoo!attcan!uunet!bu.edu!snorkelwacker!mit-eddie!apollo!mishkin From: mishkin@apollo.HP.COM (Nathaniel Mishkin) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Message-ID: <4b8742f6.20b6d@apollo.HP.COM> Date: 11 Jul 90 15:29:00 GMT References: <404@bischeops.UUCP> <4b423481.20b6d@apollo.HP.COM> <1990Jul5.040529.16093@athena.mit.edu> <1990Jul10.225103.20551@athena.mit.edu> Sender: root@apollo.HP.COM Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 71 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