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

[Barry Leiba <[e-mail]>]

Nice, and an improvement over my version.  Thanks!

Barry

On Thu, Jan 21, 2016 at 10:46 AM, David Noveck <[e-mail]> wrote:
> 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
>
>