Subject: Re: Rechartering the NFS Version 4 Workgroup - thoughts request o f comments

From: Mike Eisler <[email-masked]>
Date: Tue, 20 Mar 2001 07:36:33 -0800 (PST)

> > How is this all going to work (or not work)?  Do we need two
> > separately developed inter-operating implementations of 
> > every feature?  For example, as far as I know, everybody's
> > method of implementing SPKM3 and LIPKEY is to wait for
> > Andy to do it and steal his code (Who said, "Ordinary artists
> > borrow.  Great artists steal.").  It doesn't make sense to
> > do anything else.  Is this going to be a problem for getting
> > to Draft status?
> 
> The official position is that the two implementations need to
> be genetically distinct, but we don't actually do DNA testing.
> 
> We want to know the spec could be understood by more than one
> genius, but one could possibly argue (to oneself) that 
> integrating the code tested that enough...

My interpretation, based on my failed attempt to raise RRC 2203 to
Draft, is that while two independent implementations of RFC XXXX do not
have to use distinctly building blocks that they depend om (for
example, they don't have to use different TCP/IP stacks, something
which would be impractical if the two interoperable, independent,
implementations both ran on Linux), RFC XXXX, because it depends on
TCP/IP cannot achive Draft, unless TCP and IP are at Draft or higher.
Which of course they are. 

RFC 2203 (RPCSEC_GSS) was denied Draft status last year because it
depended on GSS-API (RFC 2743). RFC 2743 is still at Draft status.
Thus, based on GSS-API alone, I don't see how NFSv4 gets to Draft. And
I'd think that because NFSv4 depends also on ONC RPC, LIPKEY, and the
Kerberos V5 GSS-API plug in, that NFSv4 doesn't get to Draft until the
corresponding RFCs are raised. And of coruse, the RFCs NFSv4
depends on must have two independent, interoperable implementations.
So while as Dave says, everyone will probably used
Andy's SPKM and LIPKEY, at some point there has to be someone
else with an SPKM and LIPKEY who interoperates with Andy's, even
if the test application is not NFSv4.

But I'd certainly love to be wrong. If so, please submit RFC 2203 for
consideration to Draft status. :-)

BTW, XDR ought to be raised to Standard by now; it's been at Draft for
a long time, and has no dependencies on other RFCs.

	-mre

---

From: Allison Mankin <[email-masked]>
Date: Tue, 20 Mar 2001 10:54:36 -0500

> depended on GSS-API (RFC 2743). RFC 2743 is still at Draft status.

I took an action item to talk to the Security ADs about advancing
RFC 2743 beyond its PS status and I'll report to this group (I'll
find out at least something initial this week).  

> a long time, and has no dependencies on other RFCs.

Good point.  It wouldn't block it from moving, but it does need to
acquire a (null?) IANA Considerations section and a Security Considerations
section.  Who can take on writing the latter?

Allison

---

From: Michael Eisler <[email-masked]>
Date: Tue, 20 Mar 2001 08:20:11 -0800 (PST)

> section.  Who can take on writing the latter?

I'll do it.

	-mre