From: Mike Eisler (mike@eisler.com)
Date: 11/07/00-11:05:16 AM Z
Message-Id: <200011071707.JAA21380@eagle.webpros.com> Date: Tue, 7 Nov 2000 09:05:16 -0800 (PST) From: Mike Eisler <mike@eisler.com> Subject: Re: NFSv4 at Proposed Standard (was Re: downgrade/upgrade) 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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:22 AM Z CST