Fix editorial issues with DID Recovery section.

index.html

@@ -4810,54 +4810,64 @@ <h2>Verification Method Revocation</h2>
       <h2>DID Recovery</h2>
 
       <p>
-        Recovery is a reactive security measure, whereby a controller is able
-        to regain the ability to perform DID operations.
+Recovery is a reactive security measure whereby a <a>controller</a> that has
+lost the ability to perform DID operations, such as through the loss of a
+device, is able to regain the ability to perform DID operations.
       </p>
 
-      <p class="advisement">
-        Recovery is advised when a controller or services trusted to act on
-        their behalf no longer have the exclusive ability to perform DID
-        operations as described in <a href="#method-operations"></a>.
+      <p>
+The following considerations might be of use when contemplating the use of
+<a>DID</a> recovery:
       </p>
 
-      <p class="advisement">
-        It is considered a best practice to never reuse a verification method
-        or key material associated with recovery for any other purposes.
-      </p>
+      <ul>
 
-      <p>
-        Recovery is commonly performed in conjunction with
-        <a href="#verification-method-rotation">verification method rotation</a>
-        and <a href="#verification-method-revocation">verification method revocation</a>.
-      </p>
+        <li>
+Performing recovery proactively on an infrequent but regular basis, can help to
+ensure that control has not been lost.
+        </li>
 
-      <p>
-        There are no common recovery mechanisms that apply to all DID Methods.
-      </p>
+        <li>
+It is considered a best practice to never reuse cryptographic material
+associated with recovery for any other purposes.
+        </li>
 
-      <p>
-        <a>DID method</a> specifications might choose to enable support for a
-        quorum of trusted parties to facilitate recovery. Some of the
-        facilities to do so are suggested in Section
-        <a href="#did-controller"></a>.
-      </p>
+        <li>
+Recovery is commonly performed in conjunction with <a
+href="#verification-method-rotation">verification method rotation</a> and <a
+href="#verification-method-revocation">verification method revocation</a>.
+        </li>
 
-      <p>
-        Not all <a>DID method</a> specifications will recognize control from
-        <a>DIDs</a> registered using other <a>DID methods</a> and they might
-        restrict third-party control to <a>DIDs</a> that use the same method.
-      </p>
+        <li>
+Recovery is advised when a <a>controller</a> or services trusted to act on their
+behalf no longer have the exclusive ability to perform DID operations as
+described in <a href="#method-operations"></a>.
+        </li>
 
-      <p>
-        Access control and recovery in a <a>DID method</a>
-        specification can also include a time lock feature to protect against
-        key compromise by maintaining a second track of control for recovery.
-      </p>
+        <li>
+<a>DID method</a> specifications might choose to enable support for a quorum of
+trusted parties to facilitate recovery. Some of the facilities to do so are
+suggested in <a href="#did-controller"></a>.
+        </li>
+
+        <li>
+Not all <a>DID method</a> specifications will recognize control from <a>DIDs</a>
+registered using other <a>DID methods</a> and they might restrict third-party
+control to <a>DIDs</a> that use the same method.
+        </li>
+
+        <li>
+Access control and recovery in a <a>DID method</a> specification can also
+include a time lock feature to protect against key compromise by maintaining a
+second track of control for recovery.
+        </li>
+
+        <li>
+There are currently no common recovery mechanisms that apply to all
+<a>DID methods</a>.
+        </li>
+      </ul>
 
-      <p class="note">
-        Performing recovery proactively on an infrequent but regular basis,
-        can help to ensure that control has not been lost.
-      </p>
     </section>
 
     <section>