Hi Brian, Thank you for providing the updated XML files. We are working on the updates for all of the documents in this cluster and will get back to you shortly.
Best regards, RFC Editor/kc > On Mar 12, 2025, at 7:56 AM, Brian Haberman via auth48archive > <auth48archive@rfc-editor.org> wrote: > > Hey all, > I have made some edits to the XMLs to deal with the below comments. Thank > you for such a close read between documents. I hope I captured all the > necessary changes. My general rules of thumb were: > > 1. Specific Timer, Report, Record, Message names are capitalized, > 2. Variables listed in section 8 of 9776 and section 9 of 9777 are referenced > in the text enclosed within brackets, > 3. Changed some terms to ensure consistency across the two documents. > > Please let me know if you see additional inconsistencies. I’m sure I missed > something. ;) > > Regards, > Brian > > <rfc9777-bkh.xml><rfc9776-bkh.xml> > >> On Mar 11, 2025, at 6:16 PM, rfc-edi...@rfc-editor.org wrote: >> >> Hi Brian, >> >> Thanks for your QUICK replies! We have some additional questions about >> terms that impact more than one of the three documents making up Cluster >> 518. Please consider whether updates are needed. >> >> 1) We note that the word "new" was used 26 times in >> RFC 9776 and 34 times in RFC 9777; please consider if any instances are >> not new and should be removed. For example, the following text >> was used in RFCs 3376 and 3810 - is the service interface and its >> features still considered "new"? Please review. >> >> Some examples - see the text for more. >> >> Current >> Section 2: >> The equivalent operations in the new service interface follow: >> >> Section 3.2: >> Filtering of packets based upon a socket's multicast reception >> state is a new feature of this service interface. >> >> >> 2) Throughout the text in RFCs 9776, 9777, and 9778, the following >> terminology appears to be used inconsistently. Please review these >> occurrences and let us know if/how they may be made consistent. >> >> Hyphenation: >> Current-State Record (15) (9776) vs. >> Current-State Group Record (1) (9776) vs. >> Current State Record (15) (9777) >> >> Filter-Mode-Change Record (9776) vs. Filter Mode Change Record (9777) >> >> >> Capitalization: >> General Query (9776 and 9777) vs. General query (9776) vs. >> general query (9776 and 9777) >> >> Query Message (9778) vs. Query message (9776 and 9777) vs. >> query message (9776 and 9777) >> >> interface timer (9776) vs. Interface Timer (9777) >> >> retransmission timer (9776) vs. Retransmission Timer (9777) >> >> Source Timer vs. source timer - this term is largely lowercase in the >> running text but is uppercase in the tables (see Table 10 in RFC 9776 and >> Table 9 in 9777). >> >> Older Version Host Present Timer (9777) vs. >> Older Version Host Present timer (9776 and 9777)) >> Note: Please consider if these terms should also have the same case: >> Older Host Present Timer >> Older Host Present Interval >> IGMPv1 Host Present timer >> >> Older Version Querier Present Timer (9776) vs. >> Older Version Querier Present timer (9776 and 9777) >> [Note: Also consider "Older Version Querier Present Timeout”.] >> >> >> Hyphenation and capitalization: >> router filter-mode (9776) vs. Router Filter Mode (9777) >> Service Interface (9776) vs. service interface (9777) >> source-change report (9776) vs. Source Change Report (9777) >> Source-List-Change Record (9776) vs. Source List Change Record (9777) >> State-Change Report (9776) vs. State-Change report (9776) vs. State Change >> Report >> (9777) >> >> >> 3) Other terms only have the first occurrence enclosed in quote marks. Should >> these terms follow that pattern, or should all occurrences be enclosed >> in quote marks? >> leave latency vs. "leave latency" >> fast leave vs. "fast leave” >> >> >> 4) Should "record type" be uppercase in any of the following >> instances for consistency, or is lowercase correct per the context? >> >> Record Type vs. record type >> >> Current (9777 and 9776): >> An SSM-aware host >> SHOULD NOT send a MODE_IS_EXCLUDE record type for multicast >> addresses that fall within the SSM address range as they will >> be ignored by SSM-aware routers [RFC4604]. >> >> An SSM-aware SSM-aware >> host SHOULD NOT send a CHANGE_TO_EXCLUDE_MODE record type for >> multicast addresses that fall within the SSM address range. >> >> SSM-aware routers SHOULD ignore records that contain multicast >> addresses in the SSM address range if the record type is >> MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE. >> >> Thank you, >> RFC Editor > > -- > 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
