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
