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 "IGMPv3 Revision" to "IGMPv3" to match the document title? Original: IGMPv3 Revision Perhaps: IGMPv3 --> 2) <!-- [rfced] IGMP is being published as an Internet Standard. We have marked this as STD 100 (new STD), as we do not see any existing STDs related to IGMP. Please review and let us know if changes are needed. See https://www.rfc-editor.org/search/rfc_search_detail.php?sortkey=Number&sorting=DESC&page=All&pubstatus%5B%5D=Standards%20Track&std_trk=Internet%20Standard --> 3) <!-- [rfced] Note that, because draft-ietf-pim-3228bis will be published alongside this document, we have replaced the reference to 3228 with 9778. Please review and let us know if any corrections are needed. --> 4) <!-- [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. --> 5) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 6) <!--[rfced] Is "IP Precedence of Internetwork Control" referring to "IP Time-to-Live of 1"? If so, could "which is an" be added for easier readability as shown below? Original: Every IGMP message described in this document is sent with an IP Time-to-Live of 1, IP Precedence of Internetwork Control (e.g., Type of Service 0xc0), and carries an IP Router Alert option [RFC2113] in its IP header. Perhaps: Every IGMP message described in this document is sent with an IP Time-to-Live of 1, which is an IP Precedence of Internetwork Control (e.g., Type of Service 0xc0), and carries an IP Router Alert option [RFC2113] in its IP header. --> 7) <!-- [rfced] We see the following discrepancies with the IGMP Type Numbers registry <https://www.iana.org/assignments/igmp-type-numbers>. Please review and let us know if we may update the names to match what appears in the IANA registry. In addition, please consider whether uses of "version X" should be updated for consistency as well. >From the IANA registry: 0x22 IGMPv3 Membership Report Type 0x22 - IGMPv3 Membership Report Table 1: 0x22 Version 3 Membership Report >From the IANA registry: 0x12 IGMPv1 Membership Report 0x16 IGMPv2 Membership Report 0x17 IGMPv2 Leave Group Table 2: 0x12 Version 1 Membership Report 0x16 Version 2 Membership Report 0x17 Version 2 Leave Group --> 8) <!--[rfced] Is "Section 4.1.9" the correct section reference in the sentence below, or is "Section 4.1.11", which explains the Query message variants, perhaps intended? Please review. Original: The Group Address field is set to zero when sending a General Query, and set to the IP multicast address being queried when sending a Group-Specific Query or Group-and-Source-Specific Query (see Section 4.1.9, below). --> 9) <!--[rfced] We note that Tables 3-15 do not have titles (Tables 1 and 2 do). Would you like to add titles? If so, please provide the desired text. --> 10) <!--[rfced] For consistency, should "Filter-Mode-Change record" be plural in the first sentence (option A), or should "Source-List-Change records" be singular in the second sentence (option B)? Original: If the report should contain a Filter-Mode-Change record, then if the current filter-mode of the interface is INCLUDE, a TO_IN record is included in the report, otherwise a TO_EX record is included. If instead the report should contain Source-List-Change records, an ALLOW and a BLOCK record are included. Perhaps A: If the report should contain Filter-Mode-Change Records, and if the current filter-mode of the interface is INCLUDE, a TO_IN record is included in the report; otherwise, a TO_EX record is included. If instead the report should contain Source-List-Change Records, an ALLOW and a BLOCK record are included. or Perhaps B: If the report should contain a Filter-Mode-Change Record, and if the current filter-mode of the interface is INCLUDE, a TO_IN record is included in the report; otherwise, a TO_EX record is included. If instead the report should contain a Source-List-Change Record, an ALLOW and a BLOCK record are included. --> 11) <!-- [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). --> 12) <!-- [rfced] We see "Send Q(G,X-A)" not "Send Q(G,X)" in Table 9. Is this variance okay or is an update needed? Original: When a table action "Send Q(G,X)" is encountered by a querier in the table in Section 6.4.2, the following actions must be performed for each of the sources in X of group G, with source timer larger than LMQT: Perhaps: When a table action "Send Q(G,X-A)" is encountered by a querier in Table 9 (Section 6.4.2), the following actions must be performed for each of the sources in X of group G, with the source timer larger than LMQT: --> 13) <!--[rfced] What does "these" refer to in this sentence? Can the text be rephrased for clarity as shown below? Original: 8. List of Timers, Counters and Their Default Values Most of these timers are configurable. Perhaps: 8. List of Timers, Counters, and Their Default Values Most timers and counters are configurable. --> 14) <!--[rfced] We updated this text to be a complete sentence. Please let us know if it is not correct. Original: 8.3. Query Response Interval The Max Response Time used to calculate the Max Resp Code inserted into the periodic General Queries. Current: 8.3. Query Response Interval The Query Response Interval uses the Max Response Time to calculate the Max Resp Code that is inserted into the periodic General Queries. --> 15) <!-- [rfced] As RFC 9778 will be published with this document, please consider whether the reference should be to [BCP57] or [RFC9778]. --> 16) <!-- [rfced] Please review each artwork element in the xml file. Specifically, should any artwork element be tagged as sourcecode or another element, e.g., the artwork element in Section 6.4.1? If sourcecode is correct for any of these, please let us know if the "type" attribute of each sourcecode element. 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. --> 17) <!-- [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. Group-and-Source-Specific Query vs. Group-and-Source Specific Query vs. group and source specific query Group-and-Source-Specific Queries vs. Group-and-Source-Specific queries vs. Group-and-Source Specific Queries Group-Specific Query vs. Group Specific Query [Note: Table 15 uses "Source-and-Group-Specific Query" and "Group-Specific Query".] Group Record vs. group record Group Timer (2) vs. group timer (24) [Note: See two uppercase instances in Sections 6.4.1 and 6.6.1 (Table 10).] Max Response Time vs. Max Resp Time [Note: Are these terms different or the same?] Membership Report vs. membership report Some examples: Membership Reports that are sent in response... Membership reports that are sent in response... Queries vs. queries Ex: number of Queries response to Queries If while scheduling new queries pending queries general queries Querier election vs. querier election [Note: Also see Querier vs. querier below.] b) We updated the text to reflect the forms on the right. Please let us know if further changes are desired. backwards compatible -> backward compatible Filter-Mode-Change record -> Filter-Mode-Change Record (3 instances) Host Compatibility mode -> Host Compatibility Mode (3) Group Compatibility mode -> Group Compatibility Mode (3) Leave Messages -> Leave messages (1) Other-Querier Present and Other-Querier-Present -> Other Querier Present (2) Router-Alert -> Router Alert (not hyphenated in attributive position) Router Filter-Mode -> router filter-mode (1) IP Service Interface -> IP service interface (1) Source-List-Change record -> Source-List-Change Record (1) c) Is it correct that 2 instances of "Sources" appear as uppercase in Section 6.4.1, or should they be lowercase? Original: A = set of source records whose source timers > 0 (Sources that at least one host has requested to be forwarded) B = set of source records whose source timers = 0 (Sources that IGMP will suggest to the routing protocol not to forward) d) Querier vs. querier. We note that uppercase "Querier" seems to be used when it is part of a term; otherwise, it appears as lowercase. Should "Querier" be made lowercase in any of the sentences below, as we see instances in the text such as "used by the querier", "sent by the querier", etc.? Current: The Query Interval is the interval between General Queries sent by the Querier. The Startup Query Interval is the interval between General Queries sent by a Querier on startup. A forged Query message from a machine with a lower IP address than the current Querier will cause Querier duties to be assigned to the forger. If the forger then sends no more Query messages, other routers' Other Querier Present timer will time out and one will resume the role of Querier. A forged State-Change Report message will cause the Querier to send out Group-Specific or Source-and-Group-Specific Queries for the group in question. The Querier includes its Robustness Variable and Query Interval in Query packets to allow synchronization of these variables on non- Queriers. --> 18) <!-- [rfced] Abbreviations a) FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Authentication Header (AH) Denial of Service (DoS) --> 19) <!-- [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, but please consider whether the following could be updated with alternate wording: hear (2) heard (7) hearing (1) Could "receive", "received", and "receiving" be used instead? For example, does the S flag perform an action upon "hearing" a Query and are General Queries "heard" on the interface, or could "receiving" and "received", respectively, be used as shown below? (3376bis and 3810bis) Original: When set to one, the S Flag indicates to any receiving multicast routers that they are to suppress the normal timer updates they perform upon hearing a Query. Perhaps: When set to one, the S (Suppress Router-Side Processing) flag indicates to any receiving multicast routers that they are to suppress the normal timer updates they perform upon receiving a Query. (3376bis) Original: This variable is kept per interface and is dependent on the version of General Queries heard on that interface as well as the Older Version Querier Present timers for the interface. Perhaps: This variable is kept per interface and is dependent on the version of General Queries received on that interface as well as the Older Version Querier Present timers for the interface. --> Thank you. RFC Editor On Mar 10, 2025, at 11:04 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/rfc9776.xml https://www.rfc-editor.org/authors/rfc9776.html https://www.rfc-editor.org/authors/rfc9776.pdf https://www.rfc-editor.org/authors/rfc9776.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9776-diff.html https://www.rfc-editor.org/authors/rfc9776-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9776-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9776 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC 9776 (draft-ietf-pim-3376bis-12) Title : Internet Group Management Protocol, Version 3 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
