Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in GitHub issues (see https://github.com/rfc-editor/AUTH48-rfc9945/issues).
1) <!-- [rfced] FYI - This document has been assigned a new BCP number as requested. Please note that we will obsolete RFC 3683, and BCP 83 will be retired (BCPs are not obsoleted). --> 2) <!-- [rfced] FYI - We will do the following when we convert the file to RFCXML: - Capitalize "bcp:" in the document header. - Move the Acknowledgments section to appear before the Authors' Addresses section. --> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 4) <!-- [rfced] We suggest updating the text below to clarify that the team will be working with the chairs and administrators to implement the procedures. Please review. Original: That team will develop a set of moderation procedures and facilitate their consistent implementation with chairs and administrators. Perhaps: That team will develop a set of moderation procedures and work with the chairs and administrators to facilitate their consistent implementation. --> 5) <!-- [rfced] Please review "moderator team replaces the IETF discussion list moderation team" and let us know if any updates would be helpful for clarity. Original: * Obsoletes Section 3 of [RFC9245] and the second paragraph of Section 4 of [RFC9245], as the moderator team replaces the IETF discussion list moderation team. Perhaps: * Obsoletes Section 3 of [RFC9245] and the second paragraph of Section 4 of [RFC9245], as the IETF moderator team defined in this document replaces the IETF discussion list moderator team. --> 6) <!-- [rfced] We updated this bullet item for parallelism with the rest of the list (i.e., each starts with a verb). Would you like to further update to the suggestion listed under "Perhaps" below? Original (surrounding text provided for context): The moderation policy goals are as follows: * Apply consistent, fair, and timely moderation of communication across all public online IETF participation channels and participation fora without regard to a participant's role in the IETF or previous technical contributions; * Appeals are available to address disagreements about moderation actions; Updated: * Ensure appeals are available to address disagreements about moderation actions; Perhaps: * Ensure an appeals path is available to address disagreements about moderation actions; --> 7) <!-- [rfced] For readability, we suggest the following update. Please review. Original: Questions about processes detailed below should be answered through the lens of these aims. Perhaps: Questions about the processes detailed below should be answered with these goals in mind. --> 8) <!-- [rfced] We recommend stating the main point first, as opposed to what it is not, so we suggest the following update. Please review. Original: The goal is explicitly *not* punishment, but to maintain an open, welcoming, non-hostile environment in which all may participate on an equal footing, regardless of their role in the IETF or past technical contributions. Perhaps: The objective is to maintain an open, welcoming, non-hostile environment in which all may participate on an equal footing, regardless of their role in the IETF or past technical contributions; it is explicitly *not* intended as a punishment. --> 9) <!-- [rfced] Should "LLC Board" and "LLC staff and contractors" be updated to "IETF LLC Board" and "IETF LLC staff and contractors" (i.e., include "IETF")? Original: Individuals serving on other bodies to which the NomCom appoints members, such as the IETF Trust or the LLC Board, as well as LLC staff and contractors shall also be excluded from serving on the moderator team. Perhaps: Individuals serving on other bodies to which the NomCom appoints members, such as the IETF Trust or the IETF LLC Board, as well as IETF LLC staff and contractors shall also be excluded from serving on the moderator team. --> 10) <!-- [rfced] Should this sentence mention those experiencing disruptive behavior (not just those observing it)? Also, would updating "is also important to ensure" to "also improves the likelihood" (or similar) improve this sentence? Original: Team diversity is also important to ensure any participant observing disruptive behavior can identify a moderator they feel comfortable contacting. Perhaps: Team diversity also improves the likelihood that any participant experiencing or observing disruptive behavior can identify a moderator they feel comfortable contacting. --> 11) <!-- [rfced] May we update this sentence as follows to improve clarity? Original: Only moderation actions suspending participation privileges for longer than fourteen (14) days must be reported to the forum to which such an action applies, or in any event, at the request of the suspended person. Perhaps: At the request of the suspended individual, moderation actions that suspend participation privileges are to be reported to the forum to which such an action applies. Otherwise, only suspensions longer than fourteen (14) days must be reported to the relevant forum. --> 12) <!-- [rfced] What does "operation" refer to? [OT] does not mention "operation". Perhaps this refers to "operating practices" or "operational procedures" as used in RFC 7776? Original: Administrators and moderators shall complement the efforts of the IETF ombudsteam [OT], whose focus on anti-harassment and operation shall remain unchanged. Perhaps A: Administrators and moderators shall complement the efforts of the IETF Ombudsteam [OT], whose focus on anti-harassment and operations remain unchanged. Perhaps B: Administrators and moderators shall complement the efforts of the IETF Ombudsteam [OT], whose focus on anti-harassment and operational processes remain unchanged. --> 13) <!-- [rfced] May we update "with a spectrum from" as follows to improve this sentence? Original: The IETF historically mainly practiced reactive moderation, with a spectrum from gentle reminders on- and off-list, all the way to suspension of posting rights and other ways of participating or communicating. Perhaps: Historically, the IETF has mainly practiced reactive moderation, employing actions ranging from gentle reminders on- and off-list all the way to suspension of posting rights and other ways of participating or communicating. --> 14) <!-- [rfced] Please consider updating this text as follows to improve readability: - revising the first sentence (it is difficult to follow because a "not only" phrase is usually paired with "but also"). - adding "However" and "e.g." to the second sentence. - updating "How disruptive behavior is moderated" the third sentence as shown below. Original: * The IETF offers participation not only through in-person meetings and mailing lists, which are the two channels of participation for which moderation processes are currently defined. IETF business also happens in chat groups, remote meeting participation systems, virtual meetings, wikis, GitHub repositories, and more. How disruptive behavior is moderated in these fora is currently undefined. Perhaps: * Moderation processes have been defined for only two channels of participation in the IETF: in-person meetings and mailing lists. However, IETF business now happens in a number of fora (e.g., chat groups, remote meeting participation systems, virtual meetings, wikis, and GitHub repositories). Procedures for moderating disruptive behavior in these fora are currently undefined. --> 15) <!-- [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. --> Thank you. Sandy Ginoza and Rebecca VanRheenen RFC Production Center On Feb 24, 2026, at 3:14 PM, [email protected] wrote: *****IMPORTANT***** Updated 2026/02/24 RFC Author(s): -------------- Your document has now entered AUTH48. The document was edited in kramdown-rfc as part of the RPC pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). AUTH48 is being handled in GitHub as part of the GitHub pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test). Your document is available for review at:\\ https://github.com/rfc-editor/AUTH48-rfc9920 Please see the README for details on the AUTH48 process:\\ https://github.com/rfc-editor/AUTH48-rfc9920/blob/Approved/README.md Once the content of the .md file is stable, we will convert it to .xml and provide the .html, .pdf, .txt, and .xml files for review. You and your coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Once the document has been reviewed and approved by all of the authors, 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/). Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
