Merge pull request #2491 from WadeBarnes/doc/update-revreg-create

Update steps for Manually Creating Revocation Registries

docs/GettingStartedAriesDev/CredentialRevocation.md

@@ -246,7 +246,7 @@ thread ID and comment is emitted to registered webhook urls.
 
 ## Manually Creating Revocation Registries
 
-> NOTE: This capability is deprecated and will likely be removed entirely in an upcoming release of ACA-Py. 
+> NOTE: This capability is deprecated and will likely be removed entirely in an upcoming release of ACA-Py.
 
 The process for creating revocation registries is completely automated - when you create a Credential Definition with revocation enabled, a revocation registry is automatically created (in fact 2 registries are created), and when a registry fills up, a new one is automatically created.
 
@@ -276,14 +276,16 @@ There are several endpoints that must be called, and they must be called in this
 
    - the tails server will check that the registry definition is already written to the ledger
 
-## Revocation Registry Rotation
+5. Post the initial accumulator value to the ledger `POST /revocation/registry/{rev_reg_id}/entry`
 
-From time to time an Issuer may want to issue credentials from a new Revocation Registry. That can be done by changing the Credential Definition, but that could impact verifiers. 
-Revocation Registries go through a series of state changes: `init`, `generated`, `posted`, `active`, `full`, `decommissioned`. When issuing revocable credentials, the work is done with the `active` registry record. There are always 2 `active` registry records: one for tracking revocation until it is full, and the second to act as a "hot swap" in case issuance is done when the primary is full and being replaced. This ensures that there is always an `active` registry. When rotating, all registry records (except records in `init` state) are `decommissioned` and a new pair of `active` registry records are created.  
-  
-Issuers can rotate their Credential Definition Revocation Registry records with a simple call: `POST /revocation/active-registry/{cred_def_id}/rotate`
+   - if you are an author (i.e. have a DID with restricted ledger write access) then this transaction may need to go through an endorser
+   - this operation **MUST** be performed on the the new revoc registry def **BEFORE** any revocation operations are performed
 
-It is advised that Issuers ensure the active registry is ready by calling `GET /revocation/active-registry/{cred_def_id}` after rotation and before issuance (if possible).
+## Revocation Registry Rotation
 
+From time to time an Issuer may want to issue credentials from a new Revocation Registry. That can be done by changing the Credential Definition, but that could impact verifiers.
+Revocation Registries go through a series of state changes: `init`, `generated`, `posted`, `active`, `full`, `decommissioned`. When issuing revocable credentials, the work is done with the `active` registry record. There are always 2 `active` registry records: one for tracking revocation until it is full, and the second to act as a "hot swap" in case issuance is done when the primary is full and being replaced. This ensures that there is always an `active` registry. When rotating, all registry records (except records in `init` state) are `decommissioned` and a new pair of `active` registry records are created.
 
+Issuers can rotate their Credential Definition Revocation Registry records with a simple call: `POST /revocation/active-registry/{cred_def_id}/rotate`
 
+It is advised that Issuers ensure the active registry is ready by calling `GET /revocation/active-registry/{cred_def_id}` after rotation and before issuance (if possible).