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
