Subject: Re: NFSv4 at Proposed Standard (was Re: downgrade/upgrade)

From: Mike Eisler <[email-masked]>
Date: Tue, 7 Nov 2000 12:16:30 -0800 (PST)

> Mike Eisler writes:
> > Is it your expectation that we will:
> > 
> > 	- proceed with publication of the current nfsv4 document as an
> > 		RFC; and
> > 	- modify the specification in an incompatible way, such that there
> > 		are then two RFCs, both listening over port 2049, both
> > 		purporting to serve ONC RPc program number  100003 over
> > 		version 4?

> There's no magic about the RFC number assigned to a Proposed Standard,
> nor is the protocol set in concrete.  
> 
> The protocol description will be assigned a new RFC number when it
> becomes a Draft Standard anyway.

Only if the protocol changes, or if the two interoperating implementations
implement a subset if the features specfied in the proposed standard.
Admittably both are likely outcomes in the case of nfsv4. What I
want to know is if an incompatible protocol change is likely?

> If there's consensus that the protocol needs changes, then we

That would be a departure from my experience with other standards track
items produced by other working groups.  E.g. GSS-API version 2
preserved compatbility with GSS-API v1. The CAT and the successor
Kerberos V5 working group have not run toward producing a new Kerberos
V5 specification that is incompatible with the venerable RFC 1510. When
LIPKEY needed to bend the SPKM specification, a new OID was assigned
for a new flavor of SPKM, rather than rendering the old SPKM
specification incompatible. Spencer has already chronicled the IMAP
versioning issues.

> should do it.  It's none of our concern that it becomes incompatible
> with someone running a pre-Draft version.

With zero production NFSv4 implementations today, this is really easy
to say. It's going to be a mess when there are multiple NFSv4s out
there that are based on two or more completely incompatible
specifications.

While, I don't understand the technical benefit in publishing an RFC
that is DOA, I admit that is a minor issue compared to fixing the
protocol. One non-technical benefit in pubishing the RFC is that it allow ISOC
to meet Sun's terms of giving up control of the NFS protocol.

In any case, my question is effectively, do people recognize that the
Proposed NFSv4 standard is likely to be changed in incompatible ways?
If we reach consensus that (a) yes we understand, and (b), we'll do it
anyway, fine. Hopefully the to be published nfsv4 proposed standard can
have some language indicating that it is effectively DOA, so that the
interoperability nightmare I believe will occur, will be minimized.

	-mre

---

From: Brian Pawlowski <[email-masked]>
Date: Tue, 7 Nov 2000 18:01:22 -0800 (PST)

I certainly expect that the current people implementing understand.

And if any lurkers on the mail list didn't understand the issues,
I presume they do now.

Any against this "consensus" on understanding?

Practically speaking (again) I see the March 2001 timeframe as being
a forcing function for a next revision - reflecting a roll up
of changes that may result from the close completion of several
implementations.

On a positive note:

	GREAT WORK GUYS doing the implementations!

The IETF process works.