Hi Brian, Thank you for providing the XML files with updates to the terminology (per the cluster-wide questions) and answers to our questions. We have added further updates based on your replies; the updated files are below. Please see some additional questions/clarifications.
1) Please let us know if you would like to add any keywords (beyond those in the title) for use on https://www.rfc-editor.org/search. 2) We did not see a reply to this question: Because this document will likely be published at the same time as 3376bis, we have updated the reference to refer to RFC 9776. Please let us know if any corrections are needed. Please consider whether it is appropriate to refer to [BCP57] and [STD100], or if referring to the specific RFCs is preferred. 3) In RFCs-to-be 9776 and 9777, “Source Timer” is uppercase when singular; otherwise, the plural form is lowercase. In RFC-to-be 9777, “filter timer” is lowercase in the running text and uppercase in tables. Are any further updates needed for consistency (i.e., make the singular form of “filter timer” uppercase in the running text)? 4) We hyphenated some instances of “State Change Report” for consistency (e.g., “State-Change Report”). This term is also hyphenated in RFC-to-be 9776. We also hyphenated “State Change Record” and “State Change Messages”; if that is not preferred, please let us know. Should “State-Change Messages” (title of A.1) perhaps be “State-Change Report Messages”? 5) In the running text, we updated "MLDv2 Multicast Listener Report” to "Version 2 Multicast Listener Report” (2 instances) to match the “ICMPv6 “type” Numbers" registry <https://www.iana.org/assignments/icmpv6-parameters>. In the running text, we made the following updates (1 instance each) for consistency and to match the registry. If it is not preferred to include the values here, please let us know. Version 1 Multicast Listener Done -> MLDv1 Multicast Listener Done (Type = decimal 132) Version 1 Multicast Listener Report -> MLDv1 Multicast Listener Report (Type = decimal 131) MLDv1 Multicast Listener Report -> MLDv1 Multicast Listener Report (Type = decimal 131) --Files-- The updated XML file is here: https://www.rfc-editor.org/authors/rfc9777.xml The updated output files are here: https://www.rfc-editor.org/authors/rfc9777.txt https://www.rfc-editor.org/authors/rfc9777.pdf https://www.rfc-editor.org/authors/rfc9777.html These diff files show all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9777-auth48diff.html https://www.rfc-editor.org/authors/rfc9777-auth48rfcdiff.html (side by side) These diff files show all changes made to date: https://www.rfc-editor.org/authors/rfc9777-diff.html https://www.rfc-editor.org/authors/rfc9777-rfcdiff.html (side by side) Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Please contact us with any further updates or with your approval of the document in its current form. We will await approval from the author prior to moving forward in the publication process. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9777 Best regards, RFC Editor/kc > On Mar 11, 2025, at 8:51 AM, Brian Haberman via auth48archive > <auth48archive@rfc-editor.org> wrote: > > Hi, > The attached XML contains responses to the questions and a few minor > edits. > > Regards, > Brian > > <rfc9777-bkh.xml> > >> On Mar 11, 2025, at 2:20 AM, rfc-edi...@rfc-editor.org wrote: >> >> Brian, >> >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the XML file. >> >> 1) <!--[rfced] May we update the short title that spans the top of the >> PDF file from "MLDv2 Revision" to "MLDv2 for IPv6" for clarity >> and to match the document title more closely? >> >> Original: >> MLDv2 Revision >> >> Perhaps: >> MLDv2 for IPv6 >> --> >> >> >> 2) <!-- [rfced] While we understand the original document was published >> with much of the text we are questioning below, the questions are aimed at >> making the text as correct as possible. Please let us know if these >> updates are incorrect or undesirable. >> --> >> >> >> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. --> >> >> >> 4) <!--[rfced] In the Abstract, is it preferred to lead with the Updates >> relationship, e.g., "This document updates RFC 2710" (first >> sentence), or should that text be grouped with "This document >> obsoletes RFC 3810" (last sentence), which would also match the >> Abstract in draft-ietf-pim-3376bis-12? >> >> Also, note that we updated the expansion of "MLD" so that it does >> not include "Protocol" for consistency. >> >> Original: >> This document updates RFC 2710, and it specifies Version 2 >> of the Multicast Listener Discovery Protocol (MLDv2). >> >> This document obsoletes RFC 3810. >> >> Perhaps: >> This document specifies the Multicast Listener Discovery >> version 2 (MLDv2) protocol. >> >> This document updates RFC 2710 and obsoletes RFC 3810. >> --> >> >> >> 5) <!--[rfced] Is "on the one hand" and "on the other hand" necessary in >> this sentence? While we understand that it was included in RFC >> 3810, please consider, for ease of reading, if you would like to >> remove it and perhaps include "respectively", if performing the >> "multicast router part" corresponds to collecting the multicast >> listener information and the "multicast address listener part" >> corresponds to informing other neighboring multicast routers of >> its listening state, as shown below. >> >> Original: >> Note that a multicast router may itself be a listener of one or more >> multicast addresses; in this case it performs both the "multicast >> router part" and the "multicast address listener part" of the >> protocol, to collect the multicast listener information needed by its >> multicast routing protocol on the one hand, and to inform itself and >> other neighboring multicast routers of its listening state on the >> other hand. >> >> Perhaps: >> Note that a multicast router may itself be a listener of one or more >> multicast addresses; in this case, it performs both the "multicast >> router part" and the "multicast address listener part" of the >> protocol, to collect the multicast listener information needed by >> its multicast routing protocol and to inform itself and other >> neighboring multicast routers of its listening state, respectively. >> --> >> >> >> 6) <!-- [rfced] We believe these values correspond to the values assigned >> in <https://www.iana.org/assignments/icmpv6-parameters>. Some of the names >> are slightly different (e.g., no version number). Should these be made >> consistent, or is this as expected? >> >> Original: >> * Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710] >> >> * Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710] >> >> In the IANA registry: >> 131 Multicast Listener Report >> 132 Multicast Listener Done >> --> >> >> >> 7) <!--[rfced] For consistency with the other subsections, we added >> introductory text to Sections 5.1.1, 5.1.2, 5.2.2, 5.2.6, and >> 9.3. Please let us know if any further updates are needed. >> >> Note that Sections 5.1.2 and 5.2.2 contain the same text; however, >> Section 5.1.2 does not include a reference to RFC 8200. Should >> Section 5.1.2 be updated to match, or is this variance intentional? >> And may we list RFC 4443 before RFC 8200? >> >> Some examples: >> >> Original: >> 5.1.1. Code >> >> Initialized to zero by the sender; ignored by receivers. >> >> 5.1.2. Checksum >> >> The standard ICMPv6 checksum; it covers the entire MLDv2 message, >> plus a "pseudo-header" of IPv6 header fields [RFC4443]. >> >> 5.2.2. Checksum >> >> The standard ICMPv6 checksum; it covers the entire MLDv2 message, >> plus a "pseudo-header" of IPv6 header fields [RFC8200] [RFC4443]. >> >> Perhaps: >> 5.1.1. Code >> >> The Code field is initialized to zero by the sender and ignored >> by receivers. >> >> 5.1.2. Checksum >> >> The Checksum field is the standard ICMPv6 checksum; it covers >> the entire MLDv2 message, plus a "pseudo-header" of IPv6 >> header fields [RFC4443] [RFC8200]. >> >> 5.2.2. Checksum >> >> The Checksum field is the standard ICMPv6 checksum; it covers >> the entire MLDv2 message, plus a "pseudo-header" of IPv6 header >> fields [RFC4443] [RFC8200]. >> --> >> >> >> 8) <!-- [rfced] Please review whether any of the notes in this document >> should be in the <aside> element. It is defined as "a container for >> content that is semantically less important or tangential to the >> content that surrounds it" >> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >> --> >> >> >> 9) <!--[rfced] Tables 6 and 9 do not have titles; would you like to add >> them? If so, please provide the desired text. >> --> >> >> >> 10) <!--[rfced] Has the following comment been addressed by the authors? >> Please see Table 6 (Section 7.3). >> >> Author comment in the XML: >> Are we missing an INCLUDE mode where no source elements are present? >> --> >> >> >> 11) <!--[rfced] The following sentence is hard to read. May we add "and" >> and two commas for easier readability as shown below? >> >> Original: >> It is not until after the Last Listener Query Time milliseconds >> without receiving a record that expresses interest in the queried >> multicast address or sources that the router may prune the >> multicast address or sources from the link. >> >> Perhaps: >> It is not until after the Last Listener Query Time milliseconds, >> and without receiving a record that expresses interest in the queried >> multicast address or sources, that the router may prune the >> multicast address or sources from the link. >> --> >> >> >> 12) <!-- [rfced] We see "Send Q(MA,X-A)" not "Send Q(MA,X)" in Table 8. Is >> this variance okay or is an update needed? >> >> Current: >> When a table action "Send Q(MA,X)" is encountered by the Querier in >> Table 8 (Section 7.4.2), the following actions must be performed for >> each of the sources in X that send to multicast address MA, with the >> source timer larger than LLQT: >> >> Perhaps: >> When a table action "Send Q(MA,X-A)" is encountered by the Querier in >> Table 8 (Section 7.4.2), the following actions must be performed for >> each of the sources in X that send to multicast address MA, with the >> source timer larger than LLQT: >> --> >> >> >> 13) <!-- [rfced] Erratum 6725 is for RFC 3376, not RFC 3810. Should the text >> that references Erratum 6725 be removed from this document and >> perhaps added to RFC 9776? >> >> Current: >> The following summarizes the changes made since [RFC3810]. >> >> ... >> >> * Added text to clarify the Group Membership Interval timer changes >> per Erratum 6725. >> --> >> >> >> 14) <!-- [rfced] Please review each artwork element and let us know if any >> should be marked as sourcecode (or another element) instead. >> >> In addition, please consider whether the "type" attribute of any sourcecode >> element should be set. >> >> The current list of preferred values for "type" is available at >> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. >> If the current list does not contain an applicable type, feel free to >> suggest additions for consideration. Note that it is also acceptable >> to leave the "type" attribute not set. >> --> >> >> >> 15) <!-- [rfced] Terminology >> >> a) Throughout the text, the following terminology appears to be used >> inconsistently. Please review these occurrences and let us know if/how they >> may be made consistent. >> >> Multicast Address Listening state vs. Multicast Address Listener state >> [Note: are these states different, or should the state be either >> "Listening" or "Listener"? Also consider instances of >> "multicast listening state" and "multicast listener status".] >> >> Multicast Address Listener vs. multicast address listener >> Multicast Address Record vs. multicast address record >> Multicast Listener Report vs. multicast listener report >> >> b) We updated the text to reflect the forms on the right. Please let us >> know if any additional changes are needed. >> >> Filter Mode Change records -> Filter Mode Change Records (1 instance) >> Hop-By-Hop -> Hop-by-Hop (for consistency and to align with other RFCs) >> Multicast Address Specific query -> Multicast Address Specific Query (2) >> Multicast Address and Source specific query -> >> Multicast Address and Source Specific Query (1) >> Multicast Listener Done Messages -> Multicast Listener Done messages (1) >> Querier State -> Querier state (1) >> Source list -> source list (1) >> Source List Change records -> Source List Change Records (1) >> type value -> Type value (1) >> Version 2 -> version 2 (when referring to MLDv2) (2) >> >> c) We note that "Filter Mode" is uppercase when a part of "Filter >> Mode Change Record", "Filter Mode Retransmission Counter", and >> "Router Filter Mode"; otherwise, it appears as lowercase. Given >> this, should any of the instances in the text below be made >> lowercase? >> >> And is "Source List" referring to a "Source List Change Record" or a >> "source list" (general)? >> >> Also, "Filter Timer" is consistently uppercase, but should all >> instances be made lowercase to match "source timer" in the >> running text? >> >> Current: >> This Multicast Address Listener state consists of a Filter Mode, a >> Filter Timer, and a Source List, with a timer associated to each >> source from the list. The Filter Mode is used to summarize the total >> listening state of a multicast address to a minimum set, such that >> all nodes' listening states are respected. The Filter Mode may >> change in response to the reception of particular types of report >> messages or when certain timer conditions occur. >> --> >> >> >> 16) <!-- [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. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> >> --> >> >> Note that we will update this document accordingly per your answer regarding >> s/hear*/receiv* that was sent as part of RFC-to-be 9776. >> >> Thank you. >> >> RFC Editor >> >> >> >> On Mar 10, 2025, at 11:05 PM, rfc-edi...@rfc-editor.org wrote: >> >> *****IMPORTANT***** >> >> Updated 2025/03/10 >> >> 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/rfc9777.xml >> https://www.rfc-editor.org/authors/rfc9777.html >> https://www.rfc-editor.org/authors/rfc9777.pdf >> https://www.rfc-editor.org/authors/rfc9777.txt >> >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9777-diff.html >> https://www.rfc-editor.org/authors/rfc9777-rfcdiff.html (side by side) >> >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc9777-xmldiff1.html >> >> >> Tracking progress >> ----------------- >> >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9777 >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC 9777 (draft-ietf-pim-3810bis-12) >> >> Title : Multicast Listener Discovery Version 2 (MLDv2) for IPv6 >> Author(s) : B. Haberman >> WG Chair(s) : Stig Venaas, Mike McBride >> >> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde >> >> > > -- > auth48archive mailing list -- auth48archive@rfc-editor.org > To unsubscribe send an email to auth48archive-le...@rfc-editor.org -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
