Incorporated @turt2live suggestions.

Used **Note** to describe notes around the authorisation rules. Otherwise restored the original state for the consequences from the auth rules.
Moved the clarification regarding default power levels up above the auth rules. Removed third sentence. And followed @turt2live's example, but opted for "for users in that room" because the default user power level is applied to all users.

specification/rooms/v1.rst

@@ -109,6 +109,8 @@ The types of state events that affect authorization are:
 - ``m.room.power_levels``
 - ``m.room.third_party_invite``
 
+**Note:** Power levels are inferred from defaults when not explicitly supplied. For example, mentions of the ``sender``'s power level can also refer to the default power level for users in the room.
+
 The rules are as follows:
 
 1. If type is ``m.room.create``:
@@ -282,9 +284,9 @@ The rules are as follows:
 
 #. Otherwise, allow.
 
-.. NOTE::
 
-   * Some consequences of these rules:
+
+  **Note:** Some consequences of these rules:
 
   * Unless you are a member of the room, the only permitted operations (apart
     from the initial create/join) are: joining a public room; accepting or
@@ -294,10 +296,6 @@ The rules are as follows:
     the kick *and* ban levels, *and* greater than the target user's power
     level.
 
-   * Power levels may also be inferred from defaults. So, mentions of, for example,
-     the ``sender``'s power level might also refer to a default power level that is
-     applied. The same holds true for events.
-
 Event format
 ~~~~~~~~~~~~