[nfsv4] Review of draft-haynes-nfsv4-delstid-00

[David Noveck <[e-mail]>]

I have read the document and believe all of the extensions suggested in
this document are worthy of serious consideration by the working group,
but, as we are unsure which of these the working group will choose to
pusue, I don't think we can be sure of the structure of the working group
document(s) that will be pursued.  I hope we will get a better sense of
that at IETF 102.

There are a number of specific issues of presentation that I want to call
your attention to.   As these made it rather difficult to understand the
various individual extensions proposed, I suggest that you take note of
these in preparing further I-D versions.  Some of these might also be
useful in preparing your presentation for IETF 102.

   - There was a lot of uncetainty about features involving delegations
   that results from confusing text that mentions "delegations" but in fact
   only refers to write delegations.  Note that read delegations do not give
   the client the ability to open the file on the client without reference to
   the server but much of the text assumes that returning any delegation will
   make it unnecessary to return an open stateid.
   - It is very confusing that section 2 includes two of your extensions
   without clearly distinguishing between them.  Adding to the confusion is
   the fact that the motivation of the open support attribute is dependent on
   the added flags bits which appear later.  I suggest you give each of the
   proposed extensions its own section, including a statement of the
   motivation for it.  Note that section 4.1 is a good explanation of the need
   for the time-attribute proxying feature but it is hidden and appears after
   the feature is laid out.  The place for the motivation of a feature is near
   the beginning of the description that feature.   After all, you know why
   the feature is needed but you can't expect the reader to have the same
   insight, and it is unrealistic to assume he is going to assimilate the
   protocol details and then correlate them with text explaiing th motivation
   that appears later.
   - The material in sections 5 and 5.1 is distracting.   You need to look
   at RFCs 8275 and 8276 as a model for dealing with XDR extension issues,
   rather than the pNFS RFCs.   I don't see the need for a consolidated XDR
   file such as is appropriate to a pNFS mapping type or a separate licensing
   section.

With regard to the individual exensions, I have, in some cases, issues with
how you have chosen to do the feature while agreeing that these cover
important issues that it is worthwhile to address:

   - With regard to the offline file support, I don't agree with the
   assumption that the server will necessarily have to bring the file online
   in order to open it.  Also, requiring him to do a GETATTR in one compound
   and then decide whether to open the file adds to complexity.  Given that
   you are extending open, you should consider bits that indicate that an
   offline file is not to be opened, or that bringing the file online be
   deferred until the first IO operation.  I still think the attribute is
   useful but don't think it should be the only  piece of offline file support
   specified.
   - With regard to the open-support attribute. I like the general idea.
   It is certainly better than forcing the client to try various bits and deal
   with NOTSUPP errors.  However, I think that basing this on bitmaps adds
   unneded complexity, in that you need separate bit number definitions for
   each existing flag and have the task of adding a bit nmber whenever you
   extend the protocol by adding a flag.  It would be simpler for this
   attribute to parallel the current definition of open and use flags where
   OPEN uses flags.  Also, definition of bit numbers for combinations of flags
   (e.g. _NONE, _BOTH) probably will become unworkable if we add more bits to
   share and deny such as DELETE.
   - With regard to the time-attribute-proxying feature, I don't understand
   why new attributes are needed rather than basing this on  setting the
   attributes that are being proxied.  One option that should be considered is
   extending the union time_how to provide for this case. I also have problems
   with requirements that SETATTR's be done the same in COMPOUND as the
   DELEGRETURN.  I'm not sure why this is needed.  If it is really necessary
   that setting of these attribute needs to be tightly bound to the delegation
   return, an extended delegation return operation should be considered.   If
   you do use SETATTRs, then the stateid would have to be that of the
   delegation.  Given what section 18.30 of RFC5661 currently says about the
   stateid in SETATTR, the very limited discussion of the stateid in that
   section would have to be extended.   The best way to do that would for the
   eventual RFC to include a new section essentially replacing section 18.30
   of RFC5661.