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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 7 Nov 2000 10:51:09 -0800

> I don't feel comfortable changing NFSv4 in an incompatible way after
> it reaches Proposed state.  IMHO, if the WG decides that the protocol
> needs to be changed in an incompatible way then it needs to make the
> decision to retract the draft and reapply for IESG approval after we
> have made the appropriate changes.

That works for this time (assuming we can agree on what a stateid means 
and how big it is).  But, what about next time?

The assumption seems to be that the spec is perfect (except for 
clarifications) and that we will not need to make further changes.
While that is possible, I don't think we should count on it.

I think implementation experience is going to show problems.  Be
prepared for incidents of "What could we have been thinking?".  
If they don't happen, consider it a bonus.

---

From: Brent Callaghan <[email-masked]>
Date: Tue, 7 Nov 2000 11:32:14 -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?

I don't understand what you're driving at here. 
 
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.

The intent of the "Proposed" maturity level is to gain experience with
protocol implementations and make changes to the protocol if necessary.

If there's consensus that the protocol needs changes, then we
should do it.  It's none of our concern that it becomes incompatible
with someone running a pre-Draft version.

	Brent

---

From: Brent Callaghan <[email-masked]>
Date: Tue, 7 Nov 2000 17:46:50 -0800 (PST)

Beepy writes:
> Spencer's comment of the existence of multiple Proposed Standards as
> they are resubmitted on the path to Draft Standard seems to me
> reasonable - and gets me back to the assertion that the current draft
> in the queue be allowed to proceed, and we set a date for a
> resubmission of a new Proposed Standard with corrections that is tied
> to some external event such as completion of the interoperability
> testing in March at Connectathon.

Yes, this is normal IETF standars process: implementation experience
feeds back into the spec.

I don't think any of us want to see lots of revisions, but we do
need some opportunity to make changes before we go for Draft.

One possibility is to publish pending changes in an update I-D
that documents the proposed changes, then aim to submit a
revision and get last call of the RFC post-Connectathon.

If we're lucky and get good coverage of features at Connectathon,
then we may get away with a single revision before we submit for Draft.

I'll be surprised if all the delegation stuff works first
time without needing a few tweaks to the protocol ....

	Brent

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 8 Nov 2000 09:19:13 -0800

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

This leads to the question of what we code to for the next bake-off.

There are a number of things that came out of the last bake-off and
the ensuing discussion.

If we believe in testing the protocol by implementing it, we should
include whatever consensus we arive at on those items, by including
it in whatever we all code to for Connectathon.  Then we can test
something that is as close as possible to what we hope will be the
eventual Draft Standard.  Then we can incorporate the set of things
that come out of Connectathon (we hope it will be small or empty).

There are a lot of minor items that need to be resolved (Those who
have volunteered to produce something on any of these should consider
themselves nagged), but I think is it particularly necessary to decide 
on the following (somewhat inter-related) big-ticket items:

     1) What is a stateid?

     2) How big is a stateid? (Is 64 bits too small?)

     3) What to do about the NT server open-upgrade-downgrade issue?

> On a positive note:
> 
> 	GREAT WORK GUYS doing the implementations!

> The IETF process works.

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