> On Apr 10, 2025, at 10:27 AM, Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > > 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
That looks good on the pdf. > > > 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). This is better. > > > 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). > Yes, that flows better. > > 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
