Change:
6.3.2. <del> Once a client has created an account with an ACME server, it is possible that the private key for the account will be lost.  The recovery contacts included in the registration allows the client to recover from this situation, as long as it still has access to these contacts. By "recovery", we mean that the information associated with an old account key is bound to a new account key.  When a recovery process succeeds, the server provides the client with a new registration whose contents are the same as base registration object - except for the "key" field, which is set to the new account key.  The server reassigns resources associated with the base registration to the new registration (e.g., authorizations and certificates).  The server SHOULD delete the old registration resource after it has been used as a base for recovery. In addition to the recovery mechanisms defined by ACME, individual client implementations may also offer implementation-specific recovery mechanisms.  For example, if a client creates account keys deterministically from a seed value, then this seed could be used to recover the account key by re-generating it.  Or an implementation could escrow an encrypted copy of the account key with a cloud storage provider, and give the encryption key to the user as a recovery value. The client requests recovery by asking that the server send a message to one of the contact URIs registered for the account.  That message indicates some action that the server requires the client's user to perform, e.g., clicking a link in an email.  If the user successfully completes the server's required actions, then the server will bind the account to the new account key. (Note that this process is almost entirely out of band with respect to ACME.  ACME only allows the client to initiate the process, and the server to indicate the result.) To initiate recovery, the client sends a POST request to the server's recover-registration URI, with a body specifying which registration is to be recovered.  The body of the request MUST be signed by the client's new account key pair. The string "contact" The URI for the registration to be recovered. If the server agrees to attempt recovery, then it creates a new registration resource containing a stub registration object.  The stub registration has the client's new account key and contacts, but no authorizations or certificates associated.  The server returns the stub contact in a 201 (Created) response, along with a Location header field indicating the URI for the new registration resource (which will be the registration URI if the recovery succeeds). After recovery has been initiated, the server follows its chosen recovery process, out-of-band to ACME.  While the recovery process is ongoing, the client may poll the registration resource's URI for status, by sending a POST request with a trivial body ({"resource":"reg"}).  If the recovery process is still pending, the server sends a 202 (Accepted) status code, and a Retry-After header field.  If the recovery process has failed, the server sends an error code (e.g., 404), and SHOULD delete the stub registration resource. If the recovery process has succeeded, then the server will send a 200 (OK) response, containing the full registration object, with any necessary information copied from the old registration).  The client may now use this in the same way as if he had gotten it from a new- registration transaction. 6.3.3. </del> If a client no longer wishes to have an account key registered with the server, it may request that the server delete its account by sending a POST request to the account URI containing the "delete"

Discussion:
This PR is a re-do of . It only removes recovery; it does not add the "account-mgmt" metadata item.
LGTM
We removed recovery in . If we refactor roll-over as proposed in , however, recovery can be done much more simply, at least if you assume the client is provisioned with a MAC key (possibly out of band).
Agreed at IETF 96 that we will not specify recovery. Instead, we will add some guidance for CAs as to how to handle loss of account keys.