>There are people who don't need GSS-RPC behind their firewalls. They
>don't _want_ GSS-RPC. I'd rather not pay the bloat overheads of
>GSS-RPC if I can avoid it.  And I really, really, really don't want
>GSS-RPC in the kernel (unless it can be configured away).  And I dont
>see much gain in forcibly GSS-RPC-ising all of userland is, if the
>kernel NFS uses old, boring unauthenticated sunrpc.  Is there
>something I'm missing?

Urrk, I'd _never_ propose GSS-RPC in the kernel.  I wasn't thinking of
GSS-RPCing all of userland ... if you don't use it, you don't load those
bits of the shared library (that's the point of shared libraries, right?)
I was just thinking of saving bloat in terms of having two RPC libraries.

>Once we've got that settled, what do you propose for rpc in EXPORTABLE
>binary distributions?  I dont think the one-library approach is viable
>there. Do you?

Hmmm ... that's a good point.  I guess it doesn't really make sense
at all, then.  Oh well ... makes my job easier, that's for sure :-)

>Last, a small point: what happens to the KRB4 "domestic" distribution?
>Does it disappear with krb5? If it does, what happens to poor sods in
>academic sites who're stuck in an AFS KRB4 environment which isn't
>migrating to a krb5 KDC? Are there any plans to leave the KRB4
>"domestic" avaiable for legacy reasons?

The _intent_ is to not lose functionality.  You should still be able
to do a V4 kinit, telnet, rsh, rlogin, etc etc.  But the current V4
domestic code will go away and it will all be based on the V4 compat
code that comes with V5.  The only thing that you might lose is the
ability to run a V4 admin server (and I'll make sure that doesn't
go away if that will really impact people).

--Ken