> 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
