anchor.diff:  be configurable in SAPI through the variable `KBMAPI_RECOVERY_TOKEN_DURATION`.
   By default, this value will be set to 1 day.
   
  -When the `POST` request is received for an existing pivtoken, KBMAPI will
  +When the `POST` request is received for an existing PIV token, KBMAPI will
   verify the antiquity of the newest member of `recovery_tokens` and in case it
   exceeds the aforementioned `KBMAPI_RECOVERY_TOKEN_DURATION` value, it will
   generate a new `recovery_token`.
   
   On all of these cases, the status code will be `200 Ok` instead of the
  -`201 Created` used for the initial pivtoken creation.
  +`201 Created` used for the initial PIV token creation.
   
   
   ### UpdatePivtoken (PUT /pivtokens/:guid)
   
  -Update the current fields of a pivtoken.  Currently, the only field that can be
  +Update the current fields of a PIV token.  Currently, the only field that can be
   altered is the `cn_uuid` field (e.g. during a chassis swap).  If the new
  -`cn_uuid` field is already associated with an assigned pivtoken, or if any of
  +`cn_uuid` field is already associated with an assigned PIV token, or if any of
   the remaining fields differ, the update fails.
   
  -This request is authenticated by signing the Date header with the pivtoken's 9e
  +This request is authenticated by signing the Date header with the PIV token's 9e
   key (same as CreatePivtoken).  This however does not return the recovery token
   in it's response.
   
  
positive.code: 
  If the `guid` or `cn_uuid` fields contain a value already in use in the
  `tokens` bucket, a new entry is _not_ created.  Instead, the `9e` public key
  from the request is compared to the `9e` key in the stored pivtoken data.  If
  the keys match, and the signature check succeeds, then the `recovery_token`
  value of the existing entry is returned and a 200 response is returned. This
  allows the CN to retry a request in the event the response was lost.
  
negative.code: token in the `tokens` bucket, but either (or both) the `guid` or `cn_uuid`
  fields match an existing entry, a 409 Conflict + NotAuthorized error
  is returned.  In such an instance, an operator must manually verify if the
  information in the PIV token bucket is out of date and manually delete it before
  the PIV token provisioning can proceed.
  
  If an operator has hardware with duplicate UUIDs, they must contact
  their hardware vendor to resolve the situation prior to attempting to provision
  