Hi Brian, Thank you for your reply. We have updated our files based on your responses, and we have included the terminology updates you made per the cluster-wide questions. We have 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) FYI: In Section 6.2, we moved the artwork (both lines) over a few spaces to the left as the first line was over the 72-character limit. If any further adjustments are needed, please let us know. 3) Sections 6.6.3.1 and 6.6.3.2. Should “1 query retransmissions” be “1 query retransmission”, or is the current text correct? Current: The router must then immediately send a Group Specific Query as well as schedule [Last Member Query Count] - 1 query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time]. 4) In Section 9.2, we updated “Version 1 Report Message” to “v1 Report message” (same for "Version 2 Report Message” in the paragraph that follows) to match Table 14. If that is not correct, please let us know. Original: A forged Version 1 Report Message may put a router into "version 1 members present" state for a particular group, meaning that the router will ignore Leave messages. Current: A forged v1 Report message may put a router into “v1 members present" state for a particular group, meaning that the router will ignore Leave messages. 5) FYI: We updated a few instances of “State-Change reports” to “State-Change Reports” for consistency within this doc and with RFC-to-be 9777. 6) We updated “Max Resp Time” to “Max Response Time”. May we also update “Max Resp Code” to “Max Response Code” for consistency? 7) We note that only three instances of “filter-mode” were updated to “filter mode” (Section 6.2.1). Should the hyphen be removed from any other instances of “filter-mode” in the text for consistency, or is everything as intended? Current (Section 6.2.1): To reduce internal state, IGMPv3 routers keep a filter mode per group per attached network. This filter mode is used to condense the total desired reception state of a group to a minimum set such that all systems' memberships are satisfied. This filter mode may change in response to the reception of particular types of Group Records or when certain timer conditions occur. In the following sections, we use the term Router Filter Mode to refer to the filter-mode of a particular group within a router. 8) We still note the following inconsistencies. Please let us know if/how we can make these consistent. a) RFC-to-be 9776: Query message the query message received Query Message received query message Query messages separate query messages RFC-to-be 9777: Query message(s) query message(s) b) Source-List-Change Record (9776) vs. Source List Change Record (9777) --FILES-- The updated XML file is here: https://www.rfc-editor.org/authors/rfc9776.xml The updated output files are here: https://www.rfc-editor.org/authors/rfc9776.txt https://www.rfc-editor.org/authors/rfc9776.pdf https://www.rfc-editor.org/authors/rfc9776.html These diff files show all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9776-auth48diff.html https://www.rfc-editor.org/authors/rfc9776-auth48rfcdiff.html (side by side) These diff files show all changes made to date: https://www.rfc-editor.org/authors/rfc9776-diff.html https://www.rfc-editor.org/authors/rfc9776-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/rfc9776 Thank you, RFC Editor/kc > On Mar 11, 2025, at 7:34 AM, Brian Haberman via auth48archive > <auth48archive@rfc-editor.org> wrote: > > Hi, > The attached XML has responses to the questions from the RFC Editor > (denoted with “[bkh]” within the rfced tag. Please let me know if you have > any issues with my responses. > > Regards, > Brian<rfc9776-bkh.xml> > >> On Mar 11, 2025, at 2:14 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 "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 -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
