Re: [nfsv4] NFSv4.2

[<[e-mail]>]

I'll agree in part and disagree in part.

There are definitely things that the group has decided are important to
get in, are not big, and don't seem to fit in a errata framework.  

As to the amount of space devoted to that sort of thing, I agree that
they will not be a big portion.  However, I think that these things will
have the highest priority for inclusion.  One thing to note is that we
may have such items come up without interoperability testing per se.
Plans for NFSv4.1 are becoming more real and clients are thinking about
a world of possible servers and servers the reverse.  As a result,
client designs are thinking about failure issues in connection with
servers implementing clientid trunking for example, and as a result some
matters of detail are brought out, even before testing.  Some of these
may be dealt with via errata but some may not.

In any case, this disagreement does not matter that much.  If we can
quantify our respective positions, one of us will be able to say "I told
you so", over a beer, and but that won't affect v4.2.

> Is the next step getting the requirements document
> updated and resubmitted?

This raises an interesting issue, which I'll introduce by asking about
updates that might be done.

Normally the purpose of a requirements document is to define work that
needs to be done.  The context here is that Mike's document was not
accepted as a working group document, for reasons that have nothing to
do with the quality of the document.  Let me slightly correct that, for
reasons that have nothing to do with any lack of quality of the document
:-).  It was never a working group document, and yet somehow the working
group worked on many of these things, although not all of them.

I think we want to have a relatively small v4.2 so are the things that
don't make it, simply because they are not ready, no longer requirements
for v4.2?  Should they be taken out of the document?  The working group
could then say it met all its v4.2 requirements but many of the things
not done are still needed.  Let's only remove things that we decide
don't need to be done.

We do need to add some additional things but again, whether they are
sufficiently far along to make v4.2 is not the issue.  The issue is
whether they need to be worked on.

So I'm going to argue that the concept of a requirements document for a
specific minorversion is not a valid one.  I suggest that we update the
document to reflect changes but not remove things because they will not
be in specific minor version.  The (working group) document should be
"Requirements for Future NFSv4 Extension" and should cover all
reasonably foreseeable minor versions as well as work that may be done
in the form of a pNFS mapping type or other extension mechanism not tied
to a minor version.  The charter can indicate that work is being done
for the items defined in that document, with particulars reflecting the
path of development.  As far as minor versions, the charter can give
target dates for v4.2 and give some sense of reasonable cadence of
subsequent minor versions necessary to address the issues in the
requirements document.



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Tom Haynes
Sent: Wednesday, July 28, 2010 9:02 PM
To: [e-mail]
Subject: [nfsv4] NFSv4.2

It was clear in the meeting that we all have an interest in
getting NFSv4.2 into the charter.

I think we also don't know what it will look like. We have
a great starting off point with Mike's document, but we have
seen some more proposals as drafts since then.

My view of NFSv4.2 is that it will be neither a large
document nor a large set of changes to the protocol. It will
be a collection of small changes with many of them
being optional.

I personally do not think there will be much space
devoted to fixing things in NFSv4.1, because I don't
envision implementations being far enough along to
find such interoperability issues.

Does anyone have another take on what 4.2 should
be?

Is the next step getting the requirements document
updated and resubmitted?
_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4