Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] Please note that the title of the document has been updated as follows. However, perhaps the title can be improved to make it more informative; see the suggestion below and let us know your thoughts. Note that the title mentions "LAYOUT_WCC" but the abstract does not. Original: Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type Current: Addition of LAYOUT_WCC to NFSv4.2's Flexible File Layout Perhaps: Extensions for Weak Cache Consistency in NFSv4.2's Flexible File Layout --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] May we update the expansion for "pNFS" here to read simply "Parallel NFS (pNFS)"? Note that NFS is marked as well-known on the list at https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list. Also, should "write cache consistency" be updated to "Weak Cache Consistency" (used elsewhere in the document)? Original: This document specifies extensions to the parallel Network File System (NFS) version 4 (pNFS) for improving write cache consistency. Perhaps: This document specifies extensions to Parallel NFS (pNFS) for improving Weak Cache Consistency (WCC). --> 4) <!-- [rfced] We have a few questions about this sentence. a) Similar to the above, may we update the expansion of pNFS to read "Parallel NFS (pNFS)"? b) Should the word "server" before the comma be removed? Please clarify. c) Please confirm that "Section 12 of [RFC8435]" is correct. Or should it just be "[RFC8435]" (with no section number)? Original: In the Network File System version 4 (NFSv4) with a Parallel NFS (pNFS) Flexible File Layout (see Section 12 of [RFC8435]) server, there is no mechanism for the data servers to update the metadata servers for when the data portion of the file is modified. Perhaps: In the Parallel NFS (pNFS) flexible file layout [RFC8435], there is no mechanism for the data servers to update the metadata servers when the data portion of the file is modified. --> 5) <!-- [rfced] This format of this entry in the Definitions section differs from the others (i.e., the others are not complete sentences and start with a lowercase word). We suggest updating this entry for consistency. Would the following (or something similar) work? Original: weak cache consistency (WCC): In NFSv3, WCC allows the client to check for file attribute changes before and after an operation (See Section 2.6 of [RFC1813]). Perhaps: weak cache consistency (WCC): the mechanism in NFSv3 that allows the client to check for file attribute changes before and after an operation (See Section 2.6 of [RFC1813]). --> 6) <!-- [rfced] Please review "is regarded as" and "is likewise considered" in these sentences. Are these correct as is, or would updating as follows (i.e., "is regarded as having" and "is likewise considered to have") be an improvement? Original: In that situation, the retrieved attribute information is regarded as strict server-client consistency. ... This combined approach is likewise considered strict server- client consistency. Perhaps: In that situation, the retrieved attribute information is regarded as having strict server-client consistency. ... This combined approach is likewise considered to have strict server- client consistency. --> 7) <!-- [rfced] We updated "Section 4" to "Section 5" in these sentences. Please confirm this change is correct. Section 5 of RFC 9754 is titled "Proxying of Times". Original: With the flexible file layout type, the client can leverage the NFSv3 WCC to service the proxying of times (See Section 4 of [I-D.ietf-nfsv4-delstid]). ... * Whenever it sends a SETATTR to refresh the proxied times (See Section 4 of [I-D.ietf-nfsv4-delstid]) ... Updated: With the flexible file layout type, the client can leverage the NFSv3 WCC to service the proxying of times (see Section 5 of [RFC9754]). ... * Whenever it sends a SETATTR to refresh the proxied times (see Section 5 of [RFC9754]) ... --> 8) <!-- [rfced] Please confirm that value 77 is not intended to be allocated in an IANA registry. Original: 3. Operation 77: LAYOUT_WCC - Layout Weak Cache Consistency --> 9) <!-- [rfced] Sections 3.1, 3.2, and 3.3 were missing from the Table of Contents because toc='exclude' was set for each of them. We removed toc='exclude'. We left the all caps as RFCs 7862 and 8881 use all caps for these, but let us know if you prefer initial capitalization. Original: 3. Operation 77: LAYOUT_WCC - Layout Weak Cache Consistency 3.4. Implementation 3.4.1. Examples of When to Use LAYOUT_WCC 3.4.2. Examples of What to Send in the LAYOUT_WCC 3.5. Allowed Errors ... Updated: 3. Operation 77: LAYOUT_WCC - Layout Weak Cache Consistency 3.1. ARGUMENT 3.2. RESULT 3.3. DESCRIPTION 3.4. Implementation 3.4.1. Examples of When to Use LAYOUT_WCC 3.4.2. Examples of What to Send in LAYOUT_WCC 3.5. Allowed Errors ... --> 10) <!-- [rfced] FYI - We updated "Section 5.8.2.25" to "Section 5.8.2.35" for space_used. Please confirm this is correct. Original: * Whenever it sends a GETATTR for any of the following attributes: size (see Section 5.8.1.5 of [RFC8881]), space_used (see Section 5.8.2.25 of [RFC8881]), ... Updated: * Whenever it sends a GETATTR for any of the following attributes: size (see Section 5.8.1.5 of [RFC8881]), space_used (see Section 5.8.2.35 of [RFC8881]), ... --> 11) <!-- [rfced] Would updating "is going to want to correlate" in one of the following ways improve this sentence while retaining the intended meaning? Original: the metadata server is going to want to correlate these times in order to detect later modification to the data file. Perhaps: The metadata server will want to correlate these times in order to detect later modification to the data file. Or: The metadata server will correlate these times in order to detect later modification to the data file. --> 12) <!-- [rfced] Should "Section 18.34" here be updated to "Section 18.30"? Current: The ffdsw_attributes are processed similar to the obj_attributes in the SETATTR arguments (See Section 18.34 of [RFC8881]). --> 13) <!-- [rfced] Please review the sentences below and let us know if any updates are needed. We ask because this document does not define new flags. Original: This document contains the external data representation (XDR) [RFC4506] description of the new open flags for delegating the file to the client. ... The reader can feed this document into the following shell script to produce the machine-readable XDR description of the new flags: --> 14) <!-- [rfced] Please note that we have removed Section 4.1 because readers should refer to the Copyright Notice included in the document. While we note the text in Section 4.1 is aligned with the current copyright, the referenced material points to http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf, which could be updated and cause confusion in the future. We also note that similar text appears in a few other RFCs. However, we believe this is not ideal practice and should be avoided. --> 15) <!-- [rfced] The following sentences are difficult to follow because they contain many parentheticals. We updated as indicated below; please review and let us know if you prefer a different solution. a) We updated these sentences to use a colon to introduce the list. Let us know if you prefer to use a bulleted list or to add these to the Definitons section. Original: The client is restricted to performing NFSv3 READ (Section 3.3.6 of [RFC1813]), WRITE (Section 3.3.6 of [RFC1813]), and COMMIT (Section 3.3.21 of [RFC1813]) operations on the file handles provided in the layout. ... As such, the NFSv3 CREATE (see Section 3.3.8 of [RFC1813]), GETATTR (see Section 3.3.1 of [RFC1813]), and SETATTR (see Section 3.3.2 of [RFC1813]) are operations commonly used by the metadata server. ... Then it can determine the time_modify (see Section 5.8.2.43 of [RFC8881]), time_metadata (see Section 5.8.2.42 of [RFC8881]), and time_access (see Section 5.8.2.37 of [RFC8881]) for the metadata file. Updated (revised to include a colon introducing the list): The client is restricted to performing the following NFSv3 operations on the filehandles provided in the layout: READ (Section 3.3.6 of [RFC1813]), WRITE (Section 3.3.7 of [RFC1813]), and COMMIT (Section 3.3.21 of [RFC1813]). ... As such, the following NFSv3 operations are commonly used by the metadata server: CREATE (see Section 3.3.8 of [RFC1813]), GETATTR (see Section 3.3.1 of [RFC1813]), and SETATTR (see Section 3.3.2 of [RFC1813]). ... Then it can determine the following for the metadata file: time_modify (see Section 5.8.2.43 of [RFC8881]), time_metadata (see Section 5.8.2.42 of [RFC8881]), and time_access (see Section 5.8.2.37 of [RFC8881]). b) For this one, we updated to use a bulleted list as there were so many items in the list. Let us know if you prefer another format or to move these to the Definitions section. Original: * Whenever it sends a GETATTR for any of the following attributes: size (see Section 5.8.1.5 of [RFC8881]), space_used (see Section 5.8.2.25 of [RFC8881]), change (see Section 5.8.1.4 of [RFC8881]), time_access (see Section 5.8.2.37 of [RFC8881]), time_metadata (see Section 5.8.2.42 of [RFC8881]), and time_modify (see Section 5.8.2.43 of [RFC8881]). Updated: * Whenever it sends a GETATTR for any of the following attributes: - size (see Section 5.8.1.5 of [RFC8881]) - space_used (see Section 5.8.2.25 of [RFC8881]) - change (see Section 5.8.1.4 of [RFC8881]) - time_access (see Section 5.8.2.37 of [RFC8881] - time_metadata (see Section 5.8.2.42 of [RFC8881]) - time_modify (see Section 5.8.2.43 of [RFC8881]) --> 16) <!-- [rfced] Terminology a) We see the following forms used in the document. We updated to "flexible file layout" per RFC 8435. Flexible File Layout Flex Files Layout flex file layout flexible file layout b) We see both "extensions" (plural) and "extension" (singular) used in this document. Are all instances correct in context? Or should any plural instance be updated to singular, or vice versa? --> 17) <!-- [rfced] How should we set the "type" attribute of each sourcecode element? Perhaps the three sourcecode blocks in Section 3 should be set to "xdr" and the ones in Section 4 to "shell"? If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to let us know. Also, it is 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 the following should be updated: white space --> Thank you. RFC Editor On Apr 9, 2025, at 12:35 PM, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/04/09 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 * rfc-edi...@rfc-editor.org (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). * auth48archive@rfc-editor.org, 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, auth48archive@rfc-editor.org 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/rfc9766.xml https://www.rfc-editor.org/authors/rfc9766.html https://www.rfc-editor.org/authors/rfc9766.pdf https://www.rfc-editor.org/authors/rfc9766.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9766-diff.html https://www.rfc-editor.org/authors/rfc9766-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9766-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9766 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9766 (draft-ietf-nfsv4-layoutwcc-07) Title : Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type Author(s) : T. Haynes, T. Myklebust WG Chair(s) : Brian Pawlowski, Christopher Inacio Area Director(s) : Gorry Fairhurst, Mike Bishop -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
