[nfsv4] Gunter Van de Velde's No Objection on draft-ietf-nfsv4-delstid-05: (with COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

Gunter Van de Velde has entered the following ballot position for
draft-ietf-nfsv4-delstid-05: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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

# Gunter Van de Velde, RTG AD, comments for draft-ietf-nfsv4-delstid-05

Many thanks for writing this document.

Please find next some observations and non-blocking comments encountered during
my processing of this work. I am not very familiar with NFS technologies, hence
maybe some of my observations and comments could be due to unexperienced.

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/
documenting the handling of ballots.

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

10      Abstract
11
12         The Network File System v4 (NFSv4) allows a client to both open a
13         file and be granted a delegation of that file.  This delegation
14         provides the client the right to authoritatively cache metadata on
15         the file locally.  This document presents several extensions for both
16         the opening and delegating of the file to the client.  This document
17         extends both NFSv4.1 (see RFC8881) and NFSv4.2 (see RFC7863).

[major]
The title of the document says "Extending the Opening of Files in NFSv4.2"
however the abstract says that this works extends both NFSv4.1 (see RFC8881)
and NFSv4.2 (see RFC7863)

88         authority for the file's metadata and data.  This document presents a
89         number of extensions which enhance the functionality of opens and
90         delegations.  These allow the client to:

[minor]
cosmetic rewrite textblob proposal

"
This document introduces a set of extensions designed to enhance the
functionality of file opens and delegations. These extensions enable the client
to: "

98         *  during the OPEN procedure, get either the open or delegation
99            stateids, but not both.
100
101        *  cache both the access and modify times, reducing the number of
102           times the client needs to go to the server to get that
103           information.

[minor]
stateid is speciefied in
https://datatracker.ietf.org/doc/html/rfc7530#section-9.1.4

[minor]
cosmetic rewrite textblob proposal

"
* During the OPEN procedure, retrieve either the open stateid or delegation
stateid, but not both simultaneously.

* Cache both the access and modify timestamps, thereby reducing the frequency
with which the client must query the server for this information. "

105        Using the process detailed in [RFC8178], the revisions in this
106        document become an extension of NFSv4.2 [RFC7862].

[major]
See earlier in the abstract where is indicated that NFS4.1 is extended too

147        A compound with a GETATTR or READDIR can report the file's attributes
148        without bringing the file online.  However, either an OPEN or a
149        LAYOUTGET might cause the file server to retrieve the archived data
150        contents, bringing the file online.  For non-pNFS systems, the OPEN
151        operation requires a filehandle to the data content.  For pNFS
152        systems, the filehandle retrieved from an OPEN need not cause the
153        data content to be retrieved.  But when the LAYOUTGET operation is
154        processed, a layout type specific mapping will cause the data content
155        to be retrieved from offline storage.

[minor]
I am not familiar with terminology as GETATTR, READDIR, LAYOUTGET, pNFS
Should refereces be added if these are not wellknown in the technology area?

157        If the client is not aware that the file is offline, it might
158        inadvertently open the file to determine what type of file it is
159        accessing.  By interrogating the new attribute FATTR4_OFFLINE, a

[minor]
Is FATTR4_OFFLINE a particular abbreviation for something of meaning?
(i have no NFS experience)

170        /// typedef bool            fattr4_offline;

[minor]
Here lower case is used, while earlierand later the same with upper case is
used? Is this intentional?

189        The fattr4_open_arguments attribute is a new XDR extension which

[minor]
Should this attribute be upper case FATTR4_OPEN_ARGUMENTS ?

465        only supports NFSv4.2.  An implementation could add a NFSv3 server
466        which is a NFSv4.2 client gateway the two incompatible systems.  As

[minor]
The phrase seems wrong? What about:

"
An implementation may introduce an NFSv3 server that functions as an NFSv4.2
client, serving as a gateway between the two otherwise incompatible systems. "