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

From: Peter Staubach <[email-masked]>
Date: Mon, 12 May 2003 13:50:08 -0600 (MDT)

> 
> > 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

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 12 May 2003 13:09:33 -0700 (PDT)

>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]

---

From: David Robinson <[email-masked]>
Date: Mon, 12 May 2003 16:27:46 -0500

>>cancel trains that aren't full enough.

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
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.

My personal preference is more on towards a feature driven
minor release policy.  This will also help solve the problem
of having a minor revision that is not "interesting" enough
to justify vendors to do the work to support it. It is
better to slip a date than to produce a reduced set of functionality
that no one implements.

Some features will take more time to develop than others and
it may not be worth holding everything for the most complex
feature (e.g. CCM may be useful and done in 6 months while it
may take Repl/Migr 24 months). So we should plan for concurrent
activity with different end dates.

My suggestion is that the WG collect up the list of proposed
changes and create the "feature list" that is desireable
for the next release. Set a date, be practical that the date
will slip, but don't throw out features just because they
are late. Hopefully this will combine into minor versions
that will be successful, but not so open ended that we never
know when we will be done.

	-David

---

From: Brent Callaghan <[email-masked]>
Date: Mon, 12 May 2003 15:22:07 -0700

David Robinson wrote:
 > :

Yes.  Let's keep in mind that the NFSv4 WG exists at
the pleasure of the IESG.  The existence of a train
model, or NFS minor versions in no way justifies the
continued existence of the WG once the deliverables
on the charter are done.

	Brent

---

From: Robert Thurlow <[email-masked]>
Date: Mon, 12 May 2003 17:13:36 -0600 (MDT)

> the priority of changes needs to be a WG level issue.

This sounds better than what I wrote.  If a train appears
too light, we should seek consensus to cancel it.

> when trains become "are too full".  Is this a concern that needs to be

Yup - and it looks like Mike Eisler has some thoughts in a
message sent a bit after yours.  My thinking so far has
been to focus on how unwieldy the is set of deltas from
RFC3530 to present, and confess I'd never thought about
so much change that a single minor rev gets unwieldy.

Rob T

---

From: Robert Thurlow <[email-masked]>
Date: Mon, 12 May 2003 17:22:06 -0600 (MDT)

> what a WG will and will not do.

I see the concern, but I don't agree because we are NOT
proposing a mechanism to support a lot of off-charter
work.  The charter sets out what we have agreed to work
on, with the IESG's consent, and no feature proposal
should be accepted as minor revision fodder by the WG
chairs unless it fits under the current charter.  A
magically clever idea should be submitted as a personal
draft and debated in terms of the propriety of a charter
extension.

Rob T