anchor.diff:  etc.), a recovery must be performed.  This allows a new token to replace the
   unavailable token.  When a recovery is required, an operator initiates the
   recovery process on the CN.  This recovery process on the CN will decrypt the
  -`recovery_token` value for the lost token that was created during the lost
  -token's CreateToken request.  The CN then submits a RecoverToken request to
  -replace the unavailable token with a new token.  The `:guid` parameter is the
  -guid of the unavailable token.  The data included in the request is identical
  -to that of a CreateToken request.  The major difference is that instead of
  -using a token's 9e key to sign the date field, the decrypted `recovery_token`
  -value is used as the signing key.
  +current `recovery_token` value for the lost token that was created during the
  +lost token's CreateToken request or a subsequent `CreateRecoveryToken` request.
  +For some TBD amount of time, earlier `recovery_token` values may also be allowed
  +to account for propagation delays when updating recovery configurations using
  +the gossip protocol. KBMAPI may also optionally periodically purge members of
  +a token's `recovery_tokens` array that are sufficiently old to no longer
  +be considered valid (even when accounting for propagation delays).
  +
  +The CN submits a RecoverToken request to replace the unavailable token
  +with a new token.  The `:guid` parameter is the guid of the unavailable token.
  +The data included in the request is identical to that of a CreateToken request.
  +The major difference is that instead of using a token's 9e key to sign the date
  +field, the decrypted `recovery_token` value is used as the signing key.
   
   **QUESTION**: Should we also include an additional header with the date signed
   by the new token's 9e key?  Or is it sufficient to trust the data if signed by
  
positive.code: ----
  
  Note that the location contains the guid of the _new_ token.
  
  #### ListTokens (GET /pivtokens)
  
  
negative.code: 
  #### Interaction: ZFS
  
  After setup has completed kbmd will manage the `rfd77:config` ZFS property on
  the pool itself directly. This will be read during boot and written during
  recovery or rekeying. kbmd itself will also make the libzfs call to provide
  key material to the pool during the unlock process (since it needs to do this
  