Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] Please review the following questions regarding this
document's title:
a) May we update "Extending" to "Extensions for"? Also, the abstract notes
that this document presents extensions for both opening and delegating files,
but the title only mentions opening of files. Should "Opening of Files" be
updated to "Opening and Delegating Files"?
Original:
Extending the Opening of Files in NFSv4.2
Perhaps:
Extensions for Opening and Delegating Files in NFSv4.2
b) How may we update the document's short title (which appears in the running
header of the PDF output) for consistency with the document title?
Original:
Deleg Stateid
Perhaps:
NFSv4.2 Extensions
Or:
Extending NFSv4.2
-->
2) <!-- [rfced] FYI - We updated "for both the opening and delegating of the
file
to the client" as follows. Let us know any concerns.
Original:
This document presents several extensions for both
the opening and delegating of the file to the client.
Updated:
This document presents several extensions for both
opening the file and delegating it to the client.
-->
3) <!-- [rfced] This document contains some sentences that are difficult to
follow because they contain many parentheticals. Below are two examples
(but the document contains more):
Original:
A compound (see Section 2.3 of [RFC8881]) with a GETATTR (see
Section 18.7 of [RFC8881]) or READDIR (see Section 18.23 of
[RFC8881]) can report the file's attributes without bringing the file
online. However, either an OPEN or a LAYOUTGET (see Section 18.43 of
[RFC8881]) might cause the file server to retrieve the archived data
contents, bringing the file online.
...
Either type of
stateid is sufficient to enable the server to treat the file as if it
were open, which allows READ (See Section 18.25 of [RFC8881]), WRITE
(See Section 18.38 of [RFC8881]), LOCK (See Section 18.12 of
[RFC8881]), and LAYOUTGET (see Section 18.50 of [RFC8881]) operations
to proceed.
Many of these sentences include operations (e.g., GETATTR and READ), and the
parentheticals point to sections in RFC 8881 that define those operations. To
improve readability of sentences like this, we recommend adding the operations
to the Definitions section (i.e, Section 1.1) and then omitting the
parentheticals from the sentences.
You may also consider doing the same for other terminology from [RFC8881],
e.g., delegation, stateid, compound, parallel NFS (pNFS), change attribute,
time_metadata attribute, time_access attribute, time_modify attribute, and
NFS4ERR_DELAY.
Let us know your thoughts.
Perhaps (add to Section 1.1; sentence form with no section pointers):
The following operations are used in this document as defined in [RFC8881]:
CB_GETATTR, CLOSE, DELEGRETURN, GETATTR, LAYOUTGET, LOCK, OPEN,
READ, READDIR, SETATTR, and WRITE.
Or (add to Section 1.1; list form with section pointers):
The following operations are used in this document as defined in [RFC8881]:
CB_GETATTR: Section 20.1 of [RFC8881]
CLOSE: Section 18.2 of [RFC8881]
DELEGRETURN: Section 18.6 of [RFC8881]
GETATTR: Section 18.7 of [RFC8881]
LAYOUTGET: Section 18.43 of [RFC8881]
LOCK: Section 18.10 of [RFC8881]
OPEN: Section 18.16.1 of [RFC8881]
READ: Section 18.22 of [RFC8881]
READDIR: Section 18.23 of [RFC8881]
SETATTR: Section 18.30 of [RFC8881]
WRITE: Section 18.32 of [RFC8881]
-->
4) <!-- [rfced] We moved the parenthetical to appear after "delegation stateid"
in this sentence. Section 8.2 of RFC 8881 defines stateids and mentions
both "delegation stateid" and "OPEN stateid". Let us know any concerns.
Original:
* during the OPEN procedure, retrieve either the open stateid (see
Section 8.2 of [RFC8881]) or delegation stateid, but not both
simultaneously.
Updated:
* retrieve either the open or delegation stateid (see
Section 8.2 of [RFC8881]), but not both simultaneously, during the OPEN
procedure; and
-->
5) <!-- [rfced] We updated the section numbers below for accuracy with RFC 8881.
Please review and confirm that these changes are correct.
Original:
Either type of stateid is sufficient to enable the server to treat the file
as if it were open, which allows READ (See Section 18.25 of [RFC8881]),
WRITE (See Section 18.38 of [RFC8881]), LOCK (See Section 18.12 of
[RFC8881]), and LAYOUTGET (see Section 18.50 of [RFC8881]) operations to
proceed.
Updated:
Either type of stateid is sufficient to enable the server to treat the file
as if it were open, which allows READ (see Section 18.22 of [RFC8881]), WRITE
(see Section 18.32 of [RFC8881]), LOCK (see Section 18.10 of
[RFC8881]), and LAYOUTGET (see Section 18.43 of [RFC8881]) operations
to proceed.
-->
6) <!-- [rfced] Is a word missing in "filehandle to the data content"? Or is
this correct as is?
Original:
For non-parallel NFS (pNFS)
systems (see Section 12 of [RFC8881]) , the OPEN operation requires a
filehandle to the data content.
Perhaps:
For non-parallel NFS
systems (see Section 12 of [RFC8881]), the OPEN operation requires a
filehandle to retrieve the data content.
-->
7) <!-- [rfced] May we update "[RFC8178] (see Section 4.4.2)" as follows? Or do
you prefer the original?
Original:
[RFC8178] (see Section 4.4.2) allows for extending a particular minor
version of the NFSv4 protocol without requiring the definition of a
new minor version.
Perhaps:
Section 4.4.2 of [RFC8178] allows for extending a particular minor
version of the NFSv4 protocol without requiring the definition of a
new minor version.
-->
8) <!-- [rfced] May we update "only one of" in the title of Section 4 as
follows?
Original:
4. OPEN grants only one of Open or Delegation Stateid
Perhaps:
4. OPEN Grants Either an Open or a Delegation Stateid
-->
9) <!-- [rfced] We do not see "OPEN4resok.stateid" in Section 18.16.2 of RFC
8881.
Should this be updated to "OPEN4resok"?
Original:
The open stateid field,
OPEN4resok.stateid (see Section 18.16.2 of [RFC8881]), MUST be set to
the special all zero stateid in this case.
Perhaps:
The open stateid field,
OPEN4resok (see Section 18.16.2 of [RFC8881]), MUST be set to
the special all-zero stateid in this case.
-->
10) <!-- [rfced] Would it be helpful to update "then the server has three
options"
in one of the following ways?
Original:
If the client then opens the file for read-write (with
OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION set), then the server has
three options:
1. Only an open stateid with the correct seqid.
2. Only a delegation stateid with the open stateid now having an
incorrect seqid as it needs to be upgraded.
3. Both an open (which will be upgraded) and a delegation stateid.
Perhaps:
If the client then opens the file for read-write (with
OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION set), the server
can return one of the following three options:
1. Only an open stateid with the correct seqid.
2. Only a delegation stateid with the open stateid now having an
incorrect seqid as it needs to be upgraded.
3. Both an open stateid (which will be upgraded) and a delegation stateid.
Or:
If the client then opens the file for read-write (with
OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION set), then the server has
three options. The server can return:
1. only an open stateid with the correct seqid,
2. only a delegation stateid (with the open stateid now having an
incorrect seqid as it needs to be upgraded), or
3. both an open stateid (which will be upgraded) and a delegation
stateid.
-->
11) <!-- [rfced] Please review "That takes" in the second sentence below. Would
updating to "This involves" be an improvement? Also, would it be helpful
to update the long third sentence to be a bulleted list?
Original:
Consider a small workload of creating a file with content. That
takes 3 synchronous and 1 asynchronous operations with existing
implementations. The first synchronous one has to OPEN the file, the
second synchronous one performs the WRITE to the file, the third
synchronous one has to CLOSE the file, and the fourth asynchronous
one uses DELEGRETURN (see Section 18.6 of [RFC8881]) to return the
delegation stateid.
Perhaps:
Consider a small workload of creating a file with content. This
involves three synchronous operations and one asynchronous operation with
existing
implementations:
* The first synchronous operation has to OPEN the file.
* The second synchronous operation performs the WRITE to the file.
* The third synchronous operation has to CLOSE the file.
* The asynchronous operation uses DELEGRETURN (see Section 18.6 of
[RFC8881]) to return
the delegation stateid.
-->
12) <!-- [rfced] For readability, may we adjust the text below as follows? In
the
suggested text below, we moved the phrase "to notify...values" to the
beginning of the sentence and used a semicolon to split up the long
sentence.
Original:
While the client could send a compound of the form: SEQ, PUTFH,
SETATTR (time_modify | time_access), DELEGRETURN, to notify the
server of the proxied values, that SETATTR (see Section 18.30 of
[RFC8881]) operation would cause either or both of change (see
Section 5.8.1.4 of [RFC8881]) or time_metadata (see Section 5.8.2.42
of [RFC8881]) to be modified to the current time on the server.
Perhaps:
To notify the server of the proxied values, the client could send a
compound of the form SEQ, PUTFH, SETATTR (time_modify |
time_access), DELEGRETURN; however, the SETATTR operation (see
Section 18.30 of [RFC8881]) would cause either or both of the change
attribute (see Section 5.8.1.4 of [RFC8881]) or time_metadata
attribute (see Section 5.8.2.42 of [RFC8881]) to be modified to the
current time on the server.
-->
13) <!-- [rfced] Is "pass these times up" correct, or should this be updated to
"pass on these times"?
Original:
As a result, it can not pass
these times up to an application expecting POSIX compliance, as is
often necessary for correct operation.
Perhaps:
As a result, it cannot pass on
these times to an application expecting POSIX compliance, as is
often necessary for correct operation.
-->
14) <!-- [rfced] May we update this sentence as follows to improve clarity? Note
that the suggested text a) clarifies what "it" refers to, b) revises
"fattr4_time_deleg_access attribute and fattr4_time_deleg_modify
attribute changes", and c) updates "or reject" to ", or it MUST reject".
Original:
Further, when it gets a SETATTR with those attributes being set, then
it MUST accept those fattr4_time_deleg_access attribute and
fattr4_time_deleg_modify attribute changes and derive the change time
or reject the changes with NFS4ERR_DELAY (see Section 15.1.1.3 of
[RFC8881]).
Perhaps:
Further, when a server gets a SETATTR with those attributes set, then
it MUST accept those changes in the fattr4_time_deleg_access and
fattr4_time_deleg_modify attributes and derive the change time,
or it MUST reject the changes with NFS4ERR_DELAY (see Section 15.1.1.3 of
[RFC8881]).
-->
15) <!-- [rfced] We are having trouble parsing the text after "either". Please
clarify.
Original:
The SETATTR SHOULD either be in a
separate compound before the one containing the DELEGRETURN or when
in the same compound, as an operation before the DELEGRETURN.
Perhaps:
The SETATTR SHOULD be either 1) in a
separate compound before the one containing the DELEGRETURN or 2)
in the same compound as an operation before the DELEGRETURN.
-->
16) <!-- [rfced] FYI - We have reworked the text below to be a bulleted list for
ease of the reader. Please review.
Original:
When the client presents either
fattr4_time_deleg_access or fattr4_time_deleg_modify attributes to
the server, the server MUST decide for both of them whether the time
presented is before the corresponding time_access (see
Section 5.8.2.37 of [RFC8881]) or time_modify (see Section 5.8.2.43
of [RFC8881]) attribute on the file or past the current server time.
Current:
When the client presents either
the fattr4_time_deleg_access or the fattr4_time_deleg_modify
attributes to the server, the server MUST decide for both of them
whether the time presented is:
* before the corresponding time_access attribute (see Section 5.8.2.37 of
[RFC8881]) or time_modify attribute (see Section 5.8.2.43 of [RFC8881])
on the file, or
* past the current server time.
-->
17) <!-- [rfced] We updated the sourcecode type in Sections 2.1, 3.1, and 5.2 to
"xdr". Please confirm that this is correct.
Should the sourcecode type be set for the sourcecode in Sections 4.1 and 6?
Note that the current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.
-->
18) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether "white space" should be updated in the
text below:
Original:
The effect of the script is to remove leading white space from each
line, plus a sentinel sequence of "///".
-->
Thank you.
RFC Editor/kf/rv
On Mar 17, 2025, at 2:26 PM, [email protected] wrote:
*****IMPORTANT*****
Updated 2025/03/17
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9754.xml
https://www.rfc-editor.org/authors/rfc9754.html
https://www.rfc-editor.org/authors/rfc9754.pdf
https://www.rfc-editor.org/authors/rfc9754.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9754-diff.html
https://www.rfc-editor.org/authors/rfc9754-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9754-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9754
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9754 (draft-ietf-nfsv4-delstid-08)
Title : Extending the Opening of Files in NFSv4.2
Author(s) : T. Haynes, T. Myklebust
WG Chair(s) : Brian Pawlowski, Christopher Inacio
Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
