Hi Brian, We have noted your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9776).
Since AUTH48 is now complete, we will move this document forward in the publication process (along with RFCs 9777 and 9778 when approved). I assume you are at the IETF 122 meeting in Bangkok this week; if so, I hope you are having a great time and a productive meeting! Best regards, RFC Editor/kc > On Mar 19, 2025, at 3:22 AM, Brian Haberman <br...@innovationslab.net> wrote: > > Hi Karen, > Approved! > > Thank you for all your efforts!! > > Regards, > Brian > >> On Mar 18, 2025, at 8:40 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: >> >> Hello Brian, >> >> We have updated our files to reflect “source-list”. Please review and let us >> know if any further changes are needed or if you approve the document in its >> current form. >> >> —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 18, 2025, at 7:20 AM, Brian Haberman <br...@innovationslab.net> >>> wrote: >>> >>> 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
