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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 7 Nov 2000 08:12:36 -0800

Spencer wrote:
> 
> On Mon, Brent Callaghan wrote:
> > 
> > Spencer writes:
> > > The real question should be "Is the WG willing to pull the current
> > > Proposed Standard back and re-work it?"  I say Proposed Standard here
> > > since the IESG has provided its approval and the only action left is
> > > the final edits of draft-07 before it becomes an RFC.  Is the WG
> > > willing to pull the draft back and delay the process?  Are we able to
> > > resolve the issues in a way that wouldn't require updating the pending
> > > RFC immediately?  What I mean by this is to have the NFSv4 RFC
> > > published and the WG turns out the first draft representing the Draft
> > > Standard that includes clarifications (without .x changes)?
> > 
> > The standards process doesn't discriminate between protocol changes
> > and clarifying text changes.  A Proposed Standard is expected to
> > undergo some revision based on implementation experience.  As quoted
> > from http://www.ietf.org/rfc/rfc2026.txt, section 6.2 "Advancing in the
> > Standards Track:"
> > 
> >    A specification may be (indeed, is likely to be) revised as it
> >    advances through the standards track.  At each stage, the IESG shall
> >    determine the scope and significance of the revision to the
> >    specification, and, if necessary and appropriate, modify the
> >    recommended action.  Minor revisions are expected, but a significant
> >    revision may require that the specification accumulate more
> >    experience at its current maturity level before progressing. Finally,
> >    if the specification has been changed very significantly, the IESG
> >    may recommend that the revision be treated as a new document, re-
> >    entering the standards track at the beginning.
> > 
> > A "significant revision" would be something like a new delegation
> > model, removing compound ops, or a new attribute framework.  But the
> > addition or deletion of simple ops, error codes, arguments etc are minor,
> > and desirable if the spec is easier to implement and less error prone.
> > Of course, the final determination of what's "significant" or "minor"
> > is up to the IESG - I'm sure the ADs will warn us if there's a risk
> > that a change could be interpreted as "very significant."
> > 
> > At this point in the standards process, when we're moving from
> > protocol theory to protocol implementation, I think the IETF
> > encourages us to revise the protocol if our "rough code"
> > experience is to be useful.
> > 
> > I don't think we're a WG that will endlessly iterate drafts toward a
> > "perfect" protocol.  Given the speed at which this group got a fairly
> > complex protocol to Proposed Standard, I think there's a strong
> > likelihood that we'll also make a timely advance to Draft.
> > 
> > Keep implementing, keep interoperating, and make (minor) changes
> > while we still can ...
> > 
> > 	Brent
> 
> Implementors will release product based upon the Proposed Standard.

I kind of doubt that.  Given the complexity of this protocol I just
don't see anyone doing an implementation in their basement (based 
on the Proposed Standard or otherwise) and then it being released to
the world, without being tested at a bake-off or Connectathon.  Who
is going to do this?  Everybody who might release product will be
on our radar screen.

People may release before official Draft Standard status but I
assume that by that point we will have an incipient "draft Draft
Standard" that they can implement to.  Changes after that point,
if there are any (and I hope not) could be dealt with by minor
versioning.

If people are really ready to release before that point, we can
consider what we want to do about minor versioning, but that
hasn't happened yet.

> Nothing we can do or what is written in the RFCs will prevent that
> from occurring. 

You can affect the probability of it occurring.  Deciding that
everyone else will bear the burden (testing, coding) of interoprating
with those who do that will clearly increase the probability that 
it will occur.

Deciding that you won't accommodate those that do this will not
prevent it, but it will make it less likely.

You can also make sure that any mismatch is easily visible.
Subtle changes in the interpretation of stateid are likely to
show mismatches in difficult-to-interpret ways.  Debugging
obscure errors that only show up in rare cases is not going to
be fun.  On the other hand, if you make subtle changes and
obvious (also still minor in the IETF sense) changes at the
same time, you are better off.  If you removed TAG (to take a
random example :-), any mismatch would show up as an XDR error
on the first request, and that would be a good thing. 
   
> Making minor changes, once we have an RFC that is a
> Proposed Standard, will require a minor revision and that minor
> revision must play within the rules that are currently defined (unless
> we find that the current set of rules are incorrect or incomplete).

I don't agree.

Consider the change that Carl is proposing to handling of multiple
opens.  Even though this would not change the .x file, it is not
just a clarification.  It is a substantive change to the protocol.
Do we really want to burden clients and servers with supporting 
both models at the same time.  Understanding and implementating 
one at a time is difficult enough.  And how would this fit into 
minor versioning?  The format of stateid stays the same but the 
interpretation changes.  Would this require stateid4_1 and separate
versions of OPEN, CLOSE, LOCK, LOCKU, RENEW, SETATTR, READ, WRITE, 
etc.?

Clearly, if making Carl's change requires all that, then even if
it is a good thing in all other respects, then the change will not
be done.  I don't think that is reasonable.

Minor versioning sure beats the alternative, but it is not fun.
Let's save it for when there is a real need.  Now is not that time.

We are at a very early stage.  We all recognize that we may have
to change our code based on bake-off results and the discussion
in the working group.  This applies to spec "clarifications" as 
well.  I have implemented stateid=lockowner+file.  If the spec
is "clarified" to be stateid=lockowner, I will change my code.
If there is anyone out there who has implemented stateid=lockowner
and the spec is clarified to be stateid=lockowner+file, he will
have to change his code.  Minor versioning is not intended for
this stage of developement.  It just won't work. 
   
> I am not against making changes but we must all agree what the ground
> rules are and where they will take us.

I think we should make a change if there is a consensus that the
change should be made (because it is important enough and does not
look risky).  That's a difficult enough hurdle.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 7 Nov 2000 11:50:39 -0600

> is going to do this?  Everybody who might release product will be

Really?  I would generally agree but in the age of open source
anything can happen.  As a reminder, a group of students did
a partial implementation.  Their announcement is at:
http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2000/0246.html

If the RFC is published as a Proposed Standard and someone does
implementation work and is not on the WG alias, then all bets are off.
The likelyhood of this occurring is low but it can happen.  It doesn't
have to be a 'full' implementation; it can be something that meets the
needs of the user.

> consider what we want to do about minor versioning, but that

Are you really suggesting that someone release a "product" based on an
Internet draft?  That's funny.  The IETF makes strong statements about
the just referencing of Internet drafts.  Releasing product based on a
Internet draft would be insane.  I, for one, would not trust the
promise of a WG about the stability of an Internet draft.

At the very least, another version of the Proposed Standard would need
to be published.

> > we find that the current set of rules are incorrect or incomplete).

Okay, let's look at an example.  Disclaimer: I am not very familiar
with this example but am taking it from the RFCs that have been
published so some of my facts may not be facts at all but incorrect
conclusions based on the documents that are publicly available (of
course this may still serve some purpose).

I see from the RFC index that RFC 1730 was the Proposed Standard for
IMAP4.  This RFC has been obsoleted by RFC 2060 which is labeled as
IMAP revision 1.  The comments at the header of RFC 2060 states that
changes were made in an upward compatible way and that IMAP commands
that were made obsolete are described in another informational RFC
such that servers can support older clients.

Specifically:

"IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
 unpublished IMAP2bis protocols.  In the course of the evolution of
 IMAP4rev1, some aspects in the earlier protocol have become obsolete.
 Obsolete commands, responses, and data formats which an IMAP4rev1
 implementation may encounter when used with an earlier implementation
 are described in [IMAP-OBSOLETE]."

Again, based on the RFC index, IMAP4 is a Proposed Standard and stands
as an example of a protocol that is at that level and enjoys
widespread deployment.

> Let's save it for when there is a real need.  Now is not that time.

Obviously we have differing opinions about the IETF standards process
and the history behind other protocols and what that means for our
work.

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.

--

- Spencer -