Original text:
The SCITT version header MUST be included and its value match the "version" field of the Receipt stucture. <del> The DID of issuer header (like in Signed Claims) MUST be included and its value match the "ts_identifier" field of the Receipt structure. </del>  TS MAY include the Registration policy info header to indicate to verifiers what policies have been applied at the registration of <del> this claim. </del>  Since I-D.draft-steele-cose-merkle-tree-proofs uses optional headers, the "crit" header (id: 2) MUST be included and all SCITT-

Reviewer comments:
and
Payload and Statement seem to be used intermixed in the text. I tried to disambiguate the via "Statement payload". If that does not work, please provide a counter proposal. The term Claim sometimes seem to have meant Signed Statement and sometimes Transparent Statement. Using our interim terminology, that became a selection process for me. Please check, if I made the correct choice in all occurrences (sometimes I had to guess the intent). Consistent Capitalization was a mess. I hope I fixed most of that. Please check. There is still no consistent use of "Registry" vs. "log" vs. "ledger" vs. "Transparency Service", I think. Please check. Please check every use of the term "Evidence" and if an alternative expression could be used. Please check every occurrence of the term "guarantee" or "proof" and if an alternative expression could be used. Privacy Considerations and Security Considerations texts require significant improvement.
Here is my opinion: Registry refers to the facilities used to store and retrieve "Authenticated Statement Data" that has been submitted to a "Transparency Service" "operator". A Registry contains specific "Statements" which the Transparency service supports, as documented in their registration policies document. A Registry may employ different technologies needed to carry out its function to store and retrieve "Statements" that are permitted in the Registry, per the registration policies defined by the Transparency Service operator. The operator of a Transparency Service serves the role of Gatekeeper to ensure the integrity of the Registry data and services provided to access the Registry data. A Statement is contained in a message "Payload" exchanged between a Transparency Service API function and other parties, i.e. consumer inquiries and Notary submissions.
It would help to be able to read the document given the changes proposed here. But due to the make errors documented in I haven't yet succeeded in doing so. Does the build infrastructure automatically build documents for other branches? Or can someone else build and publish the document based on this branch?
Editor's version build via github actions for is located here: https://ietf-wg-URL
LGTM, thanks for finishing this off

Revised text:
The SCITT version header MUST be included and its value match the "version" field of the Receipt stucture.  <ins> The DID of issuer header (like in Signed Statements) MUST be included and its value match the "ts_identifier" field of the Receipt structure. </ins> TS MAY include the Registration policy info header to indicate to verifiers what policies have been applied at the registration of  <ins> this Statement. </ins> Since I-D.draft-steele-cose-merkle-tree-proofs uses optional headers, the "crit" header (id: 2) MUST be included and all SCITT-