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

From: Mike Eisler <[email-masked]>
Date: Tue, 7 Nov 2000 15:01:53 -0800 (PST)

To echo a recent SNL skit, I've no idea what that was about.

It certainly doesn't answer my two part question.

It seems to be suggesting that I or someone else what to change the
IETF standards process, but I don't see the evidence for that.

	-mre

>From: Brian Pawlowski <[email-masked]>
>Subject: Re: NFSv4 at Proposed Standard (was Re: downgrade/upgrade)
>To: [email-masked]
>Date: Tue, 7 Nov 2000 13:37:59 -0800 (PST)
>Cc: [email-masked], [email-masked]
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>
>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.
>
>
>
>> 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 16:51:31 -0800 (PST)

Thank you for that feedback.

If elected President - ooops, wrong alias.

So, let me rephrase my concern.

	So here we are in the position that implementation experience
	has led us to tweak the proposed Proposed Std.

	:-)

	Because someone might ship to the Proposed Std, it has been
	raised that we should pull the PS and update and resubmit.

	There are two fundamental flaws to this path?  First - what is
	the "correct" draft to submit as PS, and why would one be led
	to believe that it is less subject to change than any other
	draft?

	One could argue that we keep implementing until it all works
	and submit that as a Proposed Std.  That's fine, except for the
	second flaw...

	It is allowed that changes can be made between the PS and Draft
	Standard reflecting implementation work and experience.

	I guess I was sort of (rigidly) of the view point that we were
	working towards Draft Standard, and the Proposed Standard was a
	step on the way to open up the spec for wider review - achieved
	by its recognition of having been determined by the working
	group and the IESG (mumble) as having sufficient merit for wide
	review.

	It was our belief at the time of submission given our
	experience (more than officially required I thought) that we
	had a "correct" draft.  We cut off functional additions, and
	went on the search for flaws - while the inexorable wheels of
	the IETF turned to assign an RFC #.

	It is almost a fluke that we are not a Proposed Std with an RFC
	# I thought, a result of editor queues?

Stepping back, it is the mission of this "group" (which is expanding
beyond the formal working group that hammered out the draft through the
hands of Spencer Shepler) to produce an NFS Version 4 specification that
provides functionality as specified, and proven to be interoperable
given independent (two at least) implementations.  This is what I have
been targetting, and this is the (reduced) definition of the Draft
Standard.

People have certainly shipped to a Proposed Standard in the past.  And
I heard tell from some long term IETF participant that people have
certainly screwed up shipping to a Proposed Standard as the spec
migrated away from what they shipped.:-)

Them's the break - you play, you may pay.

Practically speaking, people will implement as fast as they do,
problems will be found (perfection eludes at least me), and the spec
will be tweaked to reflect correction of protocol flaws.

The "IETF process" to me provides a framework to manage all this, with
well-defined levels of "agreement".

Will someone make a clear proposal as to what action(s) we can take as a
group to ensure some degree of goodness and responsibility in managing
the completion of the working group's primary charter?  I would like a
proposal for resubmission of the draft as Proposed Standard to cover

	1. What are the "exit conditions" for the
	   new submission?

	2. What are your expectations for the permanence
	   of the definition embodied in the new PS submission, and WHY
	   you reach that conclusion?

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.

Insights are greatly requested.  Hell, I would even garner delight from
comments and questions.

beepy