Subject: [nfsv4] Proposed agenda items for next (6/27) conference call

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 19 Jun 2006 09:21:41 -0400

The following are the items I know about.  If there are other things
that people would like to discuss, let me know and I'll add them to the
agenda, adjusting other stuff as necessary.
 
The first item is the beginning of the discussion of the
location-related chapters of the spec.  I gave these to Spencer a while
back with the intention that they would be incorporated in the next v4.1
spec draft and that we could discuss them at a conference call soon
thereafter.  Things haven't worked out that way, and I've decided to
send out the standalone versions so that we could begin the discussion
of these chapters and particularly of the details of fs_locations_info
and fs_status.  Particularly given the additional delay for
incorporation in the drafts and thus discussion, there is a risk that
this stuff could become the long pole for v4.1.  Anyway, I'd like us to
get started on that discussion as soon as possible which means the 6/27
conference call.  I have submitted these as an individual draft (2.5
hours before the deadline) so unless there is some screw-up there should
be no issue about discussing this stuff in Montreal, even if Spencer is
not able to get the next spec draft out by the 6/26 9AM deadline.  The
html version of my draft is at
http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/file11/LocationChapter
s.html.
 
The second item is that I'd like us to begin consideration of a schedule
for the v4.1 spec. I know that we discussed this at a previous call, but
I've become concerned at the fact that we don't really have a schedule
we can believe in.  The process we have followed is basically to pick a
desirable completion date, work backwards to compute various deadlines
that we would have to meet to make that date, miss those deadlines, and
start all over again.  I'd like us to try to formulate a more reasonable
schedule based on at least somewhat realistic estimates of when we
really expect stuff to be done, and figure out a completion date from
that.  If we don't like the resulting date, then we have to figure out
what we need to do differently to meet a more aggressive date. I don't
expect us to have a schedule or plan on 6/27 but I'd like to begin the
discussion so that people can start thinking through the issues and we
can continue consideration of this in Montreal.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 20 Jun 2006 06:27:16 -0500

> can continue consideration of this in Montreal.

Having a more exacting task list and resultant volunteers/assignments
and therefore schedule is fine.  I would suggest that we not postpone
the discussion for venues where participation is less than those
that are able to help with the overall task of finishing the
minor version I-D.  Therefore, the discussion should start here
on the alias (which we have done).

---

Obviously, we need to have an Internet Draft that is complete
and ready for working group last call.  So, that means that it is
of reasonable quality in readabiliy, completeness, and correctness.

Since the outset of this effort there seems to have been a desire
to produce an NFSv4.1 I-D that is of higher overall quality than
what was produce for 4.0.  This has been exemplified by the WG's
desire to have implementation experience for the functionality in 
the protocol specification.

So the first order of business is to see if this is still desired
by the WG.  Do we want to require implementation experience?
In what form?  Will we require some simple form of implementation
report from those that have done the work?

Are there other requirements of the NFSv4.1 work that is similar
to implementation experience that should be discussed/required?

With respect to the individual tasks that need to be accomplished
leading up to WG last call, I would propose the following general
outline as a starting point.  Please provide additions to this
list or a restructuring that would best capture the remaining
work.

---

Minor vesion completion tasks

Stage 1
-------
- Inclusion of all functionality descriptions
- Inclusion of all major introductory or explanatory text
- Major restructuring complete
- First draft of IANA and Security Considerations
- Complete .x file matching document
- First full document review for:
	- MAY/SHOULD/MUST usage
	- normative references
	- intra-document consistency at macro level
	- missing descriptive or explanatory text

Stage 2
-------
- Implementation reports
- Major copyediting work complete
  (consistency of voice and simplication of language
   for non-native English readers)
- Second full document review for:
	- MAY/SHOULD/MUST usage
	- intra-document consistency at micro level
	- minor editorial issues
- Solicit input from any other working groups
  or area directors (as required)

Stage 3
-------
- Preparation for WG last call
- Final full review for all issues.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 20 Jun 2006 17:19:58 -0400

On Mon, Jun 19, 2006 at 09:21:41AM -0400, Noveck, Dave wrote:
> for the v4.1 spec.

The minor version process seems to have been designed to allow small,
incremental improvements.  Such improvements would have a clear advantage over
a single monolithic 4.1--we could get them to users and get implementation
experience earlier.

To give a concrete (somewhat arbitrary) example: the RECLAIM_COMPLETE proposal
adds a single new operation and a few pages of text.  We could easily package
it up in a 4.1 draft and implement it before our next testing event.  Users
would see a clear improvement in reboot recovery times (and possibly in
reliability).  And releasing a RECLAIM_COMPLETE-only v4.1 wouldn't have to slow
down other ongoing minor-version work.

If we tie together sessions, pnfs, directory delegations, etc., etc., we commit
ourselves to a process that may not produce user-visible changes for years.

--b.