Hi Karen, > On Mar 17, 2025, at 5:53 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > > Hi Brian, > > Thank you for your review and reply. We have made the following changes: > > - updated 2 instances of “1 query retransmissions” to “1 query > retransmission(s)”
Looks good. > > - updated the text to reflect “Query Message(s)” Looks good. > > - updated the title of 4.1.1 from “Max Resp Code” to “Max Response Code”. Per > your explanation, we felt that this would suffice; however, if you would like > to add text to indicate that Max Resp Code is short for Max Response Code in > that section, please provide the text and let us know where you would like to > add it. No additional text needed. > > - updated “filter mode” to “filter-mode” (only lowercase instances) > throughout the text per your explanation. Please review to make sure the > changes are correct and to check if any further updates are needed. Looks good. > > Questions: > 1) Please confirm if all lowercase instances of “filter mode” should be > “filter-mode” in RFC-to-be 9777 for consistency. Yes, all instances of “filter mode” in 9777 should be “filter-mode”. > > 2) Should all instances of “source list” be “source-list” (the parameter) in > this document and RFC-to-be 9777? Please review. Yes. > > We are almost there in terms of sorting out this terminology! Thanks for your > guidance :-). > > —FILES (please refresh)— > 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 only the changes made during the last edit round: > https://www.rfc-editor.org/authors/rfc9776-lastdiff.html > https://www.rfc-editor.org/authors/rfc9776-lastrfcdiff.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) > > Best regards, > RFC Editor/kc > >> On Mar 17, 2025, at 7:26 AM, Brian Haberman <br...@innovationslab.net> wrote: >> >> Hi Karen, >> Responses in-line... >> >>> On Mar 14, 2025, at 6:34 PM, Karen Moore <kmo...@staff.rfc-editor.org> >>> wrote: >>> >>> 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. >>> >> >> No other keywords to add. >> >>> 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. >>> >> >> Ok. >> >>> 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]. >>> >> >> The text is worded as it is since [Last Member Query Interval] could be >> greater than two, resulting in multiple retransmissions. One option could be >> to change “retransmissions” to “retransmission(s)” if that is clearer from >> an editorial perspective. I am fine either way. >> >>> 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. >>> >> >> That change is fine. >> >>> 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. >>> >> >> Good. >> >>> 6) We updated “Max Resp Time” to “Max Response Time”. May we also update >>> “Max Resp Code” to “Max Response Code” for consistency? >>> >> >> We used “Max Resp Code” since that is the field name in Figure 1. One option >> would be to leave the field name in Figure 1 and re-word the text in 4.1.1 >> to indicate that Max Resp Code is short for Max Response Code. >> >>> 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. >> >> I think I am going to reverse my edits on “filter mode” and “filter-mode”. >> The pseudocode in section 2 specifically names one of the parameters >> “filter-mode” and that is what is being referenced throughout the text. The >> same can be said for another parameter in that pseudocode (source-list). The >> prose should use “filter-mode” to be consistent with the pseudocode. >> >>> >>> 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) >> >> For naming consistency, these can all be “Query Message(s)” >> >>> >>> b) Source-List-Change Record (9776) vs. Source List Change Record (9777) >>> >> >> Please use the hyphenated convention across the board. >> >> Regards, >> Brian >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
