[RFD Update] Clarify RBAC rule application for session joining

rfd/0043-kubeaccess-multiparty.md

@@ -372,6 +372,8 @@ and session types that the role grants privileges to join.
 We will only initially support the modes `moderator` for Kubernetes Access and `peer` for SSH sessions.
 An `observer` mode also exists which only grants access to view but does not terminate an ongoing session.
 
+This RBAC model replaces the existing RBAC model for accessing SSH sessions. The existing model allows you to join all sessions to a node that you have login access to. If this is kept, this new RBAC model becomes inflexible as it is no longer possible to configure observers or moderators that do not themselves have access to start a session. The pratical implication of this is that we no longer perform RBAC authorization at the node level when joining sessions, but instead deferring all authorization duties to the downstream authorizer for the session.
+
 Imagine you have 4 roles:
 - `prod-access`
 - `senior-dev`

rfd/0045-ssh_session-where-condition.md

@@ -12,6 +12,8 @@ Manage access to active sessions (resource kind `ssh_session`) by RBAC
 for session recordings list/read* provides access management for session
 recordings (resource kind `session`).
 
+These deny checks are to be employed on top of the new RBAC rules for listing and joining sessions introduced in [RFD 43](https://github.com/gravitational/teleport/blob/master/rfd/0043-kubeaccess-multiparty.md). This means that the user must pass both the resource checks introduced in this RFD and the RBAC `join_policy` checks from RFD 43 in order to join a session.
+
 ## Why
 
 To be able to restrict access of certain users to only a subset of active