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

From: Brent Callaghan <[email-masked]>
Date: Mon, 6 Nov 2000 17:38:13 -0800 (PST)

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: Mon, 6 Nov 2000 20:34:11 -0800 (PST)

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?

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 7 Nov 2000 00:55:22 -0600

> Keep implementing, keep interoperating, and make (minor) changes

Implementors will release product based upon the Proposed Standard.
Nothing we can do or what is written in the RFCs will prevent that
from occurring.  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 am not against making changes but we must all agree what the ground
rules are and where they will take us.

-- 

- Spencer -