Hi Tom, We have marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9766).
Once Trond approves the document, we can move forward in the publication process. Best regards, RFC Editor/rv > On Apr 10, 2025, at 11:51 PM, Thomas Haynes <log...@gmail.com> wrote: > > Hi Rebecca, > > I am satisfied with the document. Thank for the edits! > > Tom > >> On Apr 10, 2025, at 6:42 PM, Rebecca VanRheenen >> <rvanrhee...@staff.rfc-editor.org> wrote: >> >> Hi Tom, >> >> Thank you for your reply. We updated the document; all of our questions have >> now been addressed. >> >> Please review the document carefully to ensure satisfaction as we do not >> make changes once it has been published as an RFC. Contact us with any >> further updates or with your approval of the document in its current form. >> We will await approvals from each author prior to moving forward in the >> publication process. >> >> — 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 10, 2025, at 3:06 PM, Thomas Haynes <log...@gmail.com> wrote: >>> >>> >>> >>>> 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
