Jeff, Thank you for your reply; please see the follow-ups below. The revised files are here (please refresh): https://www.rfc-editor.org/authors/rfc9764.html https://www.rfc-editor.org/authors/rfc9764.txt https://www.rfc-editor.org/authors/rfc9764.pdf https://www.rfc-editor.org/authors/rfc9764.xml
This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9764-diff.html https://www.rfc-editor.org/authors/rfc9764-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9764-auth48diff.html https://www.rfc-editor.org/authors/rfc9764-auth48rfcdiff.html (side by side) Re: 4) Section 4.5, where "The above text" refers to the entire section, per your reply. This sentence has not been been updated. Please consider whether it would be more precise as follows. Orig: The above text also applies to most, if not all, BFD techniques. Perhaps: This section applies to most, if not all, BFD techniques. Re: 7) Security Considerations, you replied: > The deviation was intentional, but perhaps may be better served by preserving > the original boilerplate while adding on the additional clarification > sentence. We have not updated the document; please provide the new text. We will wait to hear from you again and from your coauthors before continuing the publication process. This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9764 Thank you. RFC Editor/ar > On Apr 1, 2025, at 6:13 AM, Jeff Haas <jhaas=40juniper....@dmarc.ietf.org> > wrote: > >> 1) <!--[rfced] Please insert any keywords (beyond those that appear in >> the title) for use on >> https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!NEt6yMaO-gk!GQvFADv7L6oq2G5CIgK-F7tTEnxEWWrj6fta8nxrK-RhcbbiS7fxr8O8G2gIUIzZy5GpA1CljWD1BvDKhjGLyn0$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!NEt6yMaO-gk!GQvFADv7L6oq2G5CIgK-F7tTEnxEWWrj6fta8nxrK-RhcbbiS7fxr8O8G2gIUIzZy5GpA1CljWD1BvDKhjGLyn0$> >> . --> > > No additional keywords are expected. > >> 2) <!--[rfced] How may this sentence be updated for clarity? >> Specifically, the text after the semicolon is not an independent clause, >> and the numbers are missing units. >> >> >> Original: >> The minimum size of this variable MUST NOT be >> smaller than permitted by the element of BFD procedure; 24 or 26 - >> see Section 6.8.6 of [RFC5880]. >> >> >> Perhaps: >> The minimum size of this variable MUST NOT be >> smaller than 24 or 26 bytes, as permitted by the element of BFD >> procedure; see Section 6.8.6 of [RFC5880]. > > Let's go with the "Perhaps" version above. > >> 3) <!--[rfced] Please review usage of "Large BFD Packet" and variations >> within this document. Should it be simply lowercase (e.g., "large >> BFD packets")? >> Alternatively, you might consider adding a sentence along the lines of >> The term "Large BFD Packets" is to refer to the mechanism >> specified in this document. > > I'm mostly ambivalent as to which form we go with. IETF style for > capitalization for proper nouns as used in protocols is sometimes > inconsistent. > > For this document, we have two competing motivations for capitalization: > - Capitalizing Large helps indicate that this is a compound proper noun and > highlights that this is the thing that we're exercising our procedures over. > - "large", in lower case, acknowledges that this is simply an adjective > relating to size. > > In reviewing the current text after first round of edits, the capitalization > in > the various section titles covers the first sense noted above. It also fits > the style guide for capitalization within such section titles. > > In the remainder of the document outside of the titles, it seems we are using > only the second sense as an adjective. For these, I think it's fine to use the > lower-case form of the capitalization. > >> a) "Large BFD Packets" vs. "Large BFD packets" >> >> >> Original: >> processing Large BFD Packets ... >> accepting Large BFD Packets ... (2 instances) >> >> >> Perhaps: >> processing large BFD packets ... >> accepting large BFD packets ... (2 instances) > > The perhaps forms is fine. > >> Original (Section 4.1): >> If Large BFD Packets is enabled on a session ... >> >> >> Perhaps: >> If accepting large BFD packets is enabled on a session ... > > The perhaps form si fine. > >> Original (Section 5.1): >> configure Large BFD packets >> >> >> Perhaps: >> configure large BFD packets > > The perhaps form is fine. > >> b) "BFD with Large Packets" >> >> >> Original (as in Sections 4.3 - 4.5): >> BFD with Large Packets >> >> >> Perhaps (as appears once in Section 4.2): >> BFD with large packets > > The perhaps form is fine. > >> Original (for example): >> an application using BFD with Large Packets >> >> >> Perhaps: >> an application using BFD with large packets > > The perhaps form is fine. > >> c) "BFD Encapsulated in Large Packet" >> >> >> Original (Section 5.1): >> that BFD Encapsulated in Large Packet is supported >> >> >> Perhaps (lowercase and adding 's'): >> that BFD encapsulated in large packets is supported > > The perhaps form is fine. > >> 4) <!--[rfced] Please clarify; does "The above text" mean all of Section 4.5 >> or specifically the preceding paragraph or otherwise? > > The entire section. > >> Original: >> The above text also applies to most, if not all, BFD techniques. >> --> >> >> >> >> >> 5) <!--[rfced] FYI that the YANG module has been updated per the >> formatting option of pyang. Please let us know any concerns. > > I have no concerns. > >> 6) <!-- [rfced] Some author comments are present in the XML. Please confirm >> that no updates related to these comments are outstanding. Note that the >> comments will be deleted prior to publication. > > The editorial comments may be removed. They were helpful to tracking IESG > pedantry during review. > >> 7) <!--[rfced] Regarding the following statement: >> >> >> Original: >> This section is modeled after the template described in Section 3.7 of >> [I-D.ietf-netmod-rfc8407bis]. >> >> >> Could you please confirm that this difference from the template is >> intentional? >> >> >> From Section 3.7.1 of draft-ietf-netmod-rfc8407bis: >> Modules that use the groupings that are defined in this document >> should identify the corresponding security considerations. For >> example, reusing some of these groupings will expose privacy-related >> information (e.g., 'node-example'). >> >> >> From this document: >> Modules that use the groupings that are defined in this document >> should identify the corresponding security considerations. This >> module defines one such grouping, "bfd-large-common", which contains >> the "pdu-size" data node whose security considerations are documented >> above. > > The deviation was intentional, but perhaps may be better served by preserving > the original boilerplate while adding on the additional clarification > sentence. > >> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the online >> Style Guide >> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/ >> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/>*inclusive_language__;Iw!!NEt6yMaO-gk!GQvFADv7L6oq2G5CIgK-F7tTEnxEWWrj6fta8nxrK-RhcbbiS7fxr8O8G2gIUIzZy5GpA1CljWD1BvDKdmUPK9A$ >> > >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. > > I see nothing that we'd change relevant to this review criteria. > > -- Jeff > > > Juniper Business Use Only -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
