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
