Subject: RE: [nfsv4] NFS Version 4 Minor Revisions

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 12 May 2003 14:27:36 -0700

In part, this is the dark side of the no-new-mandatory-features-
in-a-minor-version rule.  Since everything is optional, your option
and my option may not coincide, in which case interoperability
testing for a v4.x may succeed without proving anything.

Of course, making features mandatory may not help.  You can't 
force people to implement the next minor version, if they are
happy enough with the current one.

What this suggests to me is that we should be careful that we
don't incorporate features into minor versions if there isn't
substantial interest in actually implementing them.  We're
not going to have enforceable contracts (would require lawyers,
Ugh), but I think we need to make clear that a feature being
well-thought-out, well-specified and useful is not sufficient if 
we don't have enough real interest in getting implementations
done so as to make it likely that we will have real (as opposed
to trivially successful) interoperability testing.

-----Original Message-----
From: Haynes, Tom 
Sent: Monday, May 12, 2003 4:10 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nfsv4] NFS Version 4 Minor Revisions

> 
> > 
> > > Does the WG really need to decide between a "Feature"
> > > vs "Train" policy ?
> > 
> > I think we should, and should choose the 'train' model
> > because of the predictability and to provide a deadline
> > to make us get stuff done.  The WG chairs are free to
> > cancel trains that aren't full enough.
> > 
> 
> Unless "aren't full enough" is equivalent to "are empty", I am not sure
> how the WG chairs could make such a unilateral decision.  I think that
> the priority of changes needs to be a WG level issue.
> 
> With any luck, we won't have to worry about the opposite issue, ie.
> when trains become "are too full".  Is this a concern that needs to be
> considered?
> 
> 		ps

>From past experience, yes, this is a valid concern.

Being too full means that different internal priority levels could
see vendors implementing their own subsets of the .N release.  What
we want is for each vendor to fully support a smaller set of
features.  We might also see problems when we start interoperability
testing.

At what point does a too full train become NFSv5?

-- 
Tom Haynes, ex-cfb
[email-masked]
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Mon, 12 May 2003 16:39:49 -0700 (PDT)

> From: David Robinson <[email-masked]>

> I am concerned that the train model will not pass muster
> with the AD's. They have been very vocal in this WG and
> in others to have charters that explicitly call out

Indeed, Scott Brander called this issue out at the
SFO WG meeting. We weren't however, told that we
couldn't do a date driven model; just warned told that our
time as formal WG within IETF's auspices is limited.

> what a WG will and will not do.  A train model could easily
> give the impression that the WG will never end, all it
> takes is one more "bright idea" and yet another train
> is formed.

If after the rdma and replication/migration work is concluded,
one more bright idea might cause a new wg to be chartered, or we'll
have to find another may to get it done outside a wg venue (but
still within IETF because new minor versions need standards track
RFCs).
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Mon, 12 May 2003 23:26:12 -0700 (PDT)

> From [email-masked] Mon May 12 17:28:16 2003
> >>>>> " " == Mike Eisler <[email-masked]> writes:

>      > I've some screens for when a minor version should be morphed to
>      > a major version, and of course others may have different
>      > screens:

>      > 1. when the total number of obsolete operations
> <snip>
>      > 	OR

>      > 2.  when the total number of lines of re-written (as aopposed

> Sounds like what you are really advocating is "be very very stingy
> about adding cool-sounding new features". No?

We can add cool features, but it starts looking ugly, think
harder about how to add it.

Of course, it would be nice if we all implemented the existing
set of defined cool features first. :-)

> This same question was asked during the Cthon, and IIRC the answer
> then was that we bump the major number:

>   1) If we need to add a new mandatory feature.

The existing minor versioning rule set allows us to declare a RECOMMENDED
feature from minor version X-1 to be MANDATORY in minor
version X.

>   2) If we need to remove support for existing features.

The same rule set lets us declare a feature as obsolete (a client or
server MUST NOT implement it).
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 13 May 2003 07:21:33 -0700

Mike Eisler wrote:
> When it gets too graphically offensive, do v5 (and hope the death
> march doesn't start again).

If we limit the work to cleanup and re-codifying features already
proven in v4 minor versions, I don't think we'll get into death
march mode.  For v4.0 we had a whole new protocol framework and 
also large set of features to define and implement.  If the features
are defined in minor versions, then only a new framework needs to
be done for v5 and that should be a lot easier.  

I think new features (not proven in a minor version) are very 
scary in a v5.  If someone has a bright idea that he says cannot
be done in any v4.x, I'd be very skeptical.  We should push to
do it in a v4 minor vesion, even if that is ugly/sub-optimal/etc.,
with the idea that if proven, we can then schedule a change of 
packaging (for cleanliness, elegance, and general goodness) in
v5.   

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]]
Sent: Monday, May 12, 2003 6:17 PM
To: [email-masked]; Haynes, Tom
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nfsv4] NFS Version 4 Minor Revisions

> At what point does a too full train become NFSv5?

This is an excellent question to start asking and answering now.

I've some screens for when a minor version should be morphed to
a major version, and of course others may have different screens:

	1. when the total number of obsolete operations
		in all the minor versions reaches a certain
		threshold ( personally don't know what that might
		be but I'll know when I see it).
		Depending on we do directory delegations, we could
		hit such a threshold immediately. I.e. if we have to
		add a stateid to every operation that modifies a
		directory, or reads one (READDIR, LOOKUP, etc.), then
		it passes my threshold of tolerance. But there are
		ways to inject a stateid without changing every
		op.

	OR

	2.  when the total number of lines of re-written (as aopposed to
		added or deleted ... added is OK, deleted is desirable)
		text in all the minor versions reaches a certain percentage of
		original specification.

When it gets too graphically offensive, do v5 (and hope the death
march doesn't start again).
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4