Subject: [nfsv4] Making v4.1 a reality

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 8 Apr 2004 07:11:15 -0700

For the very very busy, let me summarize: We need to get going on v4.1
and should be ready, at the June Bakeathon to do the planning for the 
actual writing of the spec.  I urge you not to hit delete and to keep 
reading.

There's been a lot of discussion in the past of how to decide when a
minor version was ready to happen.  For a while, we talked about time-
based minor versions and then interest seemed to lag.  Another approach 
mentioned was to cut off a minor version when it had enough stuff.  I'm 
going to argue that it has been quite a while and that we have enough 
stuff and we should be thinking about going ahead with v4.1 and creating

a schedule (yikes!) for actually writing a spec.  The rest of this mail 
discusses where we are with v4.1, as input to the schedule discussion.  
At the end, I make some tentative suggestions for the beginnings of a 
v4.1 schedule.  My main purpose here is not to say that my approach 
to this issue is the correct one (although of course I think it is :-),
but to get some discussion going with the hope that the working group
can arrive at a consensus.

The most important thing to recognize is that v4.1 has already a made
a lot of progress.  I think we now have a set of content that will 
represent a significant advance for v4, but which is small enough that 
making a v4.1 spec a reality is not, or at least should not be, a
daunting 
task.  We have internet drafts for many significant items that will be 
included in v4.1.  I would argue that we now have them for *all* the 
major items of v4.1, i.e. that we should draw a line under the content 
for v4.1, at least for major items, i.e. things that involve a
significant
protocol development effort.  I think that if we don't draw a line 
under v4.1 soon, we will be faced with additional content, v4.1 will be 
delayed, get bigger and bigger, making the minor versioning process 
more and more difficult.  I think now is the time to act to prevent
that.  
What does the working group think? 

Let's look at the existing items on the presumed-to-be-in-v4.1
list.  I want to make sure the group agrees on the content of
the list and that I haven't forgotten anything:

     Sessions

     RDMA
   
     CCM
  
     Directory Delegations

All of these items have an associated internet draft, so at least we
have a relatively complete proposal.  Unless someone has some other 
proposal just about ready to submit (are there any?) it is hard to 
imagine any comparable item not holding up v4.1 a lot.

Of these items, sessions is the farthest along with a number of 
iterations of the draft and even some significant prototype
implementation
work.  I understand Tom Talpey will be telling the working group about
that.  CCM has not had as much attention but I don't see it as at all
troublesome.  (I'm assuming that CCM needs to be referenced in the
v4.1 spec, but maybe it can be done totally independently.  Can Mike
comment
on this?).  There hasn't been much (or perhaps any) discussion of the
directory delegations draft.  I think we need that discussion to refine
the existing proposal so that we have something that can go into v4.1.
My impression is that there are people who are very interested in having
directory delegations in v4.1.  I urge them to read the directory
delegations draft and comment on what changes they would like to see.
If they think the existing draft is perfect, then they can simply say
that.

RDMA has some associated difficulty because of the charter issue, but
because of how Tom, Spencer and Brent have structured things (Thanks,
guys) the issue can be successfully finessed.  While I'm sure our 
co-chairs are doing the best they can as the area directors grind 
exceedingly fine in considering this, there doesn't appear to be any 
way of coming up with an ETA for the charter change.  My answer is
that we can proceed to writing the v4.1 spec without RDMA for the 
moment, in the expectation that the area directors will eventually 
do the right thing.  Since RDMA is just another transport, we can 
have the v4.1 spec make the point that it may be used with multiple 
transports.  When and if the charter change comes through, we can be 
more explicit about the opportunities that certain forms of transport 
provide.  Until the charter change we cannot refer to RDMA in a working 
group document, but that does not prevent us from contemplating, purely 
as individuals, what we might put in a v4.1 spec regarding RDMA, should 
it happen that such a charter change is approved :-)

So, besides the "major items" what other smaller things might be
included?

One class of things is minor operation extensions.  I think Mike Eisler 
already has a draft out for SECINFO extensions.  Are there others that 
a real deadline would bring forth?

Similarly with requests for new attributes.  Any of those that people 
want to get into V4?

Another class of things is improved spec explanations of some areas.  
These are not protocol changes for v4.1, but needed changes in the spec
to make things clearer.  Given that there will be a new spec for v4.1,
I think it makes sense to clean up certain areas where the existing 
spec is not clear enough for people to implement.  In a lot of 
cases, the necessary information can be ferreted out of the group
archives but the spec would be much preferable.  As an example, I'm 
working on the changes to define clearly how referrals should be 
implemented in v4, which a spec deadline could encourage me to 
actually finish and submit in our lifetimes.  I believe there may 
be material relating to ACL implementation, that makes sense to 
include in the v4.1 spec.

So as to the process of writing the spec, I think we have a 
reasonable base in RFC3530.  Given that the changes are not
enormous (at least compared to the v3-v4 delta), getting a spec
together should not be all that onerous, especially given the
work that has already been done defining the major features
that we want to include.  I think it makes most sense to have 
the various draft authors be responsible for turning their drafts 
into the appropriate deltas for turning RFC3530 into a v4.1 spec.  
The alternative, having Spencer do it all, has a certain attraction,
but it really isn't fair.

So here is my rough guesses at a schedule.  Where am I really off?

    Basic drafts for all major content submitted by April 1.  In 
    other words, no more.

    Group decisions on major content (what's in, what's out, and
    resolution of any fundamental issues on scope) by May 1.

    Proposals, including relevant protocol details for all changes
    that involve OTW changes by May 1.

    Group consensus on what changes should go into v4.1 and in
    what form by June 1.

    Suggested content for all other spec changes by June 1.  These 
    should be fairly detailed but do not have to be at the level of
    spec deltas.

This is aggressive but if we can do this then we can get together 
and discuss the writing of the spec face-to-face at the Bakeathon.  
I'm talking about a real working session where we plan the actual 
writing of the spec (i.e. Spencer gives us our writing assignments).
I hope I have not just reduced Bakeathon attendance substantially, 
but I really think it makes sense to get going on this soon. 

So to summarize my views:

1) It's time to draw a line under the content of v4.1 at least for 
   major items.

2) We need to establish a schedule for any smaller additions to the
   v4.1 content.

3) June 1 seems a reasonable date to rap up the v4.1 content, with 
   any additions thereafter limited to exceptional circumstances.

4) We should start planning on the actual writing of the v4.1 spec
   at the June Bakeathon. (the planning, not the actual writing at
   the Bakeathon)

5) We can (and should) have a reasonable v4.1 draft by the end of
   the year.  There will still be stuff to fix up but we will have 
   something that people can use for early implementation work.

I'd like to get some discussion on these ideas started.  If you 
disagree with any or all of these ideas, let's talk about it and
see where the discussion leads (and if you agree with all of them,
then saying that might be nice, too :-).

Thanks for listening.

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

---

From: Brent Callaghan <[email-masked]>
Date: Thu, 08 Apr 2004 14:12:51 -0700

The IETF process prefers to keep working groups narrowly focused.
Hence a charter with specific accomplishments and a set of milestones
leading to (hopefully) a successful and timely conclusion.

However, the NFSv4 WG seems to have a constantly changing charter,
a smorgasbord of features, and no end in sight.  The NFSv4 WG
should be left to finish what it started: NFSv4.0 - get it to Draft status.

Wouldn't it be better to begin NFSv4.1 work within a new WG
and leverage the IETF process to define what we'll do in it ?

I think Dave's message would be a great kickoff for a BOF at
the next IETF meeting.

	Brent

Noveck, Dave wrote:
 > <deleted>