[nfsv4] Barry Leiba's No Objection on draft-ietf-nfsv4-minorversion2-40: (with COMMENT)

["Barry Leiba" <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-nfsv4-minorversion2-40: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I appear to be in the minority here, in that I *did* understand this
document's place relative to 4.0, and 4.1.  Still, I agree that
clarifying that is really important, and I'll suggest a specific
clarification in Section 1.1):

OLD
   This document describes the NFSv4.2 protocol.  With respect to
   NFSv4.0 and NFSv4.1, this document does not:
NEW
   This document describes the NFSv4.2 protocol as extensions to
   the specifications of NFSv4.0 and NFSv4.1. Those specifications
   remain current and form the basis for the additions defined
   herein.  It is necessary to implement those before adding
   NFSv4.2 to the implementation.
   
   With respect to NFSv4.0 and NFSv4.1, this document does not:
END

-- Section 1.2 --

   A major goal of the design of NFSv4.2 is to take common local file
   system features and offer them remotely.

This sounds like it means to be a change in goals relative to 4.0 and
4.1.  I think it would fit better to say it this way, and would add to
the clarification above:

NEW
   A major goal of the enhancements provided in NFSv4.2 is to take
   common local file system features that have not been available
   through earlier versions of NFS, and to offer them remotely.
END

-- Section 6.1 --

   Hole:  A byte range within a Sparse file that contains regions of all
      zeroes.  A hole might or might not have space allocated or
      reserved to it.

I'm wondering about the "regions of" here: If I have a byte range that
contains two regions of all zeroes and something that's not all zeroes in
between those two regions, I do not have a (single) hole, do I?  Why does
this say "regions of"?

And a question: Is there any disctinction between a byte-range within a
sparse file that happens to contain all zeroes... and one that is
recorded in metadata as being all zeroes?  Can some file systems write a
region of zeroes without "knowing" that they have created a hole?  Does
this distinction matter here?

-- Section 6.2.1 --

   Note that as the client has no a priori
   knowledge of whether a hole is present or not

(No need to respond to this; take it or leave it as you please.)  I have
a general preference for avoiding Latin terms, as they're not properly
understood by everyone.  In this case, too, "a priori" has a connotation
that goes beyond the literal Latin translation.  I think it'd be better
to word this as "Because the client does not know in advance whether a
hole is present or not".

   READ_PLUS extends the response with a new arm representing holes to
   avoid returning data for portions of the file which are initialized
   to zero and may or may not contain a backing store.  Returning data
   blocks of uninitialized data wastes computational and network
   resources, thus reducing performance.

It wouldn't be "uninitialized" data, would it?  It'd be zeroes.  I think
you might just want to say "Returning actual data blocks corresponding to
holes", yes?

   By contrast, if a READ_PLUS occurs in the middle of a hole,
   the server can send back a range which starts before the offset and
   extends past the range.

I'm not sure how a range can extend past itself ("a range which ...
extends past the range").  I think you just want to say "a range
representing the hole."

-- Section 6.2.2 --

   DEALLOCATE can be used to hole punch, which allows the client to
   avoid the transfer of a repetitive pattern of zeros across the
   network.

This is the first time you've mentioned DEALLOCATE where I think I
understand that it is a way of doing a WRITE wherein the client sends the
representation of a hole to the server, rather than actually doing a
WRITE.  (I had previously thought it was used to tell the server to undo
an ALLOCATE, but it now seems that they are related things, but are not
duals.)

You might want to be more clear about this here, especially if what I say
in the previous paragraph is wrong.

-- Section 7 --

   Lesser space MAY be
   consumed for backups after block deallocation.

I don't think this is a proper 2119 MAY; it sounds like a statement of
fact, not a protocol option.