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

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

What does this mean to you in practice?

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?
		
IETF's processes may allow such a thing. However, my experience is that
IETF working groups tend to take great care in not breaking
compatibility. GSS-API v1 to v2 for example. And with good reason, as
there will be users of the software who will be impacted.

Or did you have in mind a different path?

(The minor versioning path is a possible way to address this, but
minor versioning doesn't help when one has to widen the
width of a field, such as stateid. And if the proposals on the table
for changing the scope of the stateid have consensus, 64 bits
simply isn't going to cut it). 

I think if we proceed with publication of NFSv4 as is (more or less),
then we are looking at NFSv5. Which is fine, but people need to
understand the implications.

	-mre

> I agree with Brent.
> 
> Further the IETF process outlined does not require implementation experience
> leading to Proposed Std - so the work done is only required under
> Draft Std.
> 
> I believe we should proceed as Proposed Std, and then target Draft
> Std submission on completion of two implementations... Since
> as implementations are completed a couple more tweaks may arise.
> This argues against prescience that "pulling" the document now
> is any different than pulling the document later (before the completion
> of at least two implementations).
> 
> The Draft Std is the defined vehicle for those changes.
> 
> Comments?
> 
> > 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

---

From: Brian Pawlowski <[email-masked]>
Date: Tue, 7 Nov 2000 13:37:59 -0800 (PST)

The IETF doesn't even require an implementation for Proposed Std -
explain the cradle death of some specs that never bear fruit...

I really want to target Draft Std.  I feel extremely uncomfortable
with the low bar of requirement (evinced by our current predicament
I would point out) or Proposed Std.

At this point, I would say

	Yep the Draft Std will be different.

Certainly an incentive for any intelligent observer to not
ship based on the Proposed Std.

I would rather use the defined steps in the IETF process, and
accept established wisdom that changes may be introduced between
Proposed Std to Draft Std reflecting implementation experience.

	Which is exactly what just happened.

Calls to redefine the IETF stds process for the NFS V4 group alone seem
terribly unwise.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 7 Nov 2000 16:33:33 -0600

Okay.  RFC 2026, section 4.1.2 states:
"A specification from which at least two independent and interoperable
 implementations from different code bases have been developed, and
 for which sufficient successful operational experience has been
 obtained, may be elevated to the "Draft Standard" level.  For the
 purposes of this section, "interoperable" means to be functionally
 equivalent or interchangeable components of the system or process in
 which they are used.  If patented or otherwise controlled technology
 is required for implementation, the separate implementations must
 also have resulted from separate exercise of the licensing process.
 Elevation to Draft Standard is a major advance in status, indicating
 a strong belief that the specification is mature and will be useful."

The key words to me are: "sufficient successful operational experience"

This means to me that a major portion of the product has been shipped
and used in some significant fashion.

We have to accept that products will be shipped based on a Proposed
Standard.  Another example is IPv6.  Products were shipped with only a
Proposed Standard.

It is kind of a catch 22.  We need enough experience to move forward
to Draft Standard but we need a Proposed Standard to implement against
and provide product.

If the WG decides that incompatible changes are needed, I would follow
Ran's observation that the WG go ahead with the current draft as a
Proposed Standard and then immediately work to publish another RFC at
Proposed Standard level with the desired changes.

This would allow for the all of our desires.

Spencer

-- 

- Spencer -