diff --git a/changelogs/client_server/newsfragments/2107.clarification b/changelogs/client_server/newsfragments/2107.clarification
new file mode 100644
index 00000000..0474010e
--- /dev/null
+++ b/changelogs/client_server/newsfragments/2107.clarification
@@ -0,0 +1 @@
+"Public" rooms have no specific meaning with respect to moderation policy lists.
diff --git a/content/client-server-api/modules/moderation_policies.md b/content/client-server-api/modules/moderation_policies.md
index 2912d164..15a3a377 100644
--- a/content/client-server-api/modules/moderation_policies.md
+++ b/content/client-server-api/modules/moderation_policies.md
@@ -18,8 +18,9 @@ the entity making the decisions on filtering is best positioned to
 interpret the rules how it sees fit.
 
 Moderation policy lists are stored as room state events. There are no
-restrictions on how the rooms can be configured (they could be public,
-private, encrypted, etc).
+restrictions on how the rooms can be configured in terms of
+[join rules](#mroomjoin_rules), [history visibility](#room-history-visibility),
+encryption, etc.
 
 There are currently 3 kinds of entities which can be affected by rules:
 `user`, `server`, and `room`. All 3 are described with