Hi Tom, Thanks for the quick reply! We updated the document (see list of files below). We have a few followup questions/comments:
a) We updated the abbreviated title as shown below to align with the updated document title. Let us know any concerns. Note that the abbreviated title only appears in the pdf output (in the running header at the top of each page), so you won’t see this change in the diff files. Original: LAYOUT_WCC Updated: WCC in in NFSv4.2's Flexible File Layout b) After making updates, we see that the document title mentions extensions to NFSv4.2 while the abstract mentions extensions to pNFS. Are any further updates needed? Note that the sentence after the one below mentions pNFS. Current (abstract): This document specifies extensions to Parallel NFS (pNFS) for improving Weak Cache Consistency (WCC). Perhaps: This document specifies extensions to NFSv4.2 for improving Weak Cache Consistency (WCC). c) About adding the terms to the Definitions section, we see that some terms like READ and WRITE are used in the context of both NFSv3 (RFC 1813) and NFSv4 (RFC 8881). Same with the size attribute in Table 1. Would listing the terms in the Definitions section cause any issues because of this? To make the three current sentences a bit easier to read, we could further update as follows: Perhaps: The client is restricted to performing the following NFSv3 operations on the filehandles provided in the layout: READ, WRITE, and COMMIT (see Sections 3.3.6, 3.3.7, and 3.3.21 of [RFC1813], respectively) ... As such, the following NFSv3 operations are commonly used by the metadata server: CREATE, GETATTR, and SETATTR (see Sections 3.3.8, 3.3.1, and 3.3.2 of [RFC1813], respectively). ... Then it can determine the following for the metadata file: time_modify, time_metadata, and time_access (see Sections 5.8.2.43, 5.8.2.42, and 5.8.2.37 of [RFC8881], respectively). d) > I was waiting for this one Yes, we always ask about inclusive language! We updated “white space” to “blank space” as in RFC 9754. — FILES (please refresh) — Updated XML file: https://www.rfc-editor.org/authors/rfc9766.xml Updated output files: https://www.rfc-editor.org/authors/rfc9766.txt https://www.rfc-editor.org/authors/rfc9766.pdf https://www.rfc-editor.org/authors/rfc9766.html Diff file showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9766-auth48diff.html https://www.rfc-editor.org/authors/rfc9766-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9766-diff.html https://www.rfc-editor.org/authors/rfc9766-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9766 Thank you, RFC Editor/rv > On Apr 9, 2025, at 6:06 PM, Thomas Haynes <log...@gmail.com> wrote: > > > >> On Apr 9, 2025, at 12:39 PM, rfc-edi...@rfc-editor.org wrote: >> >> 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 > > I’m fine with this change. > > >> --> >> >> >> 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). > > > This is fine as well > > >> --> >> >> >> 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)"? > > Yes > > >> >> 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. > > > I am fine with the change. > > >> --> >> >> >> 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]). > > > I am fine with the change. > > > >> --> >> >> >> 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. > > > I am fine with the change. > > >> --> >> >> >> 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]) ... >> --> > > > That is fine as well, we probably added a new section between edits. > > Verified the section is correct…. > > >> >> >> 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 >> --> >> > > No, it is not allocated in an IANA registry - it is added to the overall .xdr > for NFSv4.2 > > > >> >> 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 >> ... >> --> > > > This is fine to change. > > > >> >> >> 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]), ... >> --> >> > > This is correct > > No clue how I got that one wrong. > >> >> 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. > > > The 3rd option is fine. > > > > >> --> >> >> >> 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]). >> --> > > > Yes, nice catch. > > >> >> >> 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: >> --> >> >> > > It is cut and past from the delstid draft. > > … description of the new NFSv4.2 operation LAYOUT_WCC. > > >> 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. >> --> > > > That is fine, this is pretty much boilerplate for us from before that policy. > > > >> >> >> 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]). > > > It might be easier to do what we did for Section 1.1 of RFC 9754. > > Further, the definitions of the following terms are referenced as > follows: > > * CB_GETATTR (Section 20.1 of [RFC8881]) > > * change (Section 5.8.1.4 of [RFC8881]) > > * CLOSE (Section 18.2 of [RFC8881]) > > And then all of the normal text will read cleanly. > > Ditto for below. > > If you don’t want to follow RFC 9754, I am fine with the proposed changes > above and below: > > >> >> 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 >> > > > Thanks, that is fine. > > > >> 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? >> --> >> > > > I think they are all correct. > > >> >> 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"? > > Yes please > >> >> 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 >> --> > > I was waiting for this one, in RFC 9754, we agreed on: > > The effect of the script is to remove leading blank space from each > line, plus a sentinel sequence of "///". XDR descriptions with the > sentinel sequence are embedded throughout the document. > > > > >> >> >> 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
