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

[David Noveck <[e-mail]>]

Regarding:

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.

I'd like to propose the following alternate text:

This document describes the NFSv4.2 protocol as a set of extensions to
the specification for NFSv4.1. That specification remains current and
forms the basis for the additions defined herein.  In addition, the
specfication
for NFSv4.0 remains current as well.

It is necessary to implement all the REQUIRED features of NFSv4.1 before
adding NFSv4.2 features to the implementation.



On Wed, Jan 20, 2016 at 6:53 PM, Barry Leiba <[e-mail]>
wrote:

> 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.
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>