jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-rats-ar4si

Commentary: I introduced a typo in an editorial suggestion in :-( 
 alright 
 okay
Value 1: The Evidence received contains unknown elements which the
Verifier is unable to evaluate.  An example might be that the
wrong type of Evidence has been delivered.  Another case is that
of Evidence coming from a composite Attester: a Verifier may only
understand only part of it and leave as "unknown" the
Trustworthiness claims related to features it can't appraise.
Value 1: The Evidence received contains unknown elements which the
Verifier is unable to evaluate.  An example might be that the
wrong type of Evidence has been delivered.  Another case is that
of Evidence coming from a composite Attester: a Verifier may
understand only part of it and leave as "unknown" the
Trustworthiness claims related to features it can't appraise.
Draft: draft-ietf-rats-ar4si

Commentary: Include changes from Sergei 's semantic musings . 
 a little late , but this is an easy oneLGTM , I have inlined an editorial suggestion .
Value 1: The Evidence received contains unexpected elements which
the Verifier is unable to parse.  An example might be that the
wrong type of Evidence has been delivered.
Value 1: The Evidence received contains unknown elements which the
Verifier is unable to evaluate.  An example might be that the
wrong type of Evidence has been delivered.  Another case is that
of Evidence coming from a composite Attester: a Verifier may only
understand only part of it and leave as "unknown" the
Trustworthiness claims related to features it can't appraise.
Draft: draft-ietf-rats-ar4si

Commentary: " There are two categorizations Verifier identities defined in this document " does not read awesomely . I am putting forward a ( maybe even worse ) alternative . Feel free to English - ise it . 
 Looks like an improvement
There are two categorizations Verifier identities defined in this
document.
Draft: draft-ietf-rats-ar4si

Commentary: Based on request from Yogesh for a new Configuration encoded claim . 
 Thanks  ! As you may have guessed , we have an immediate use for this 36 :-)
HSM-based: A Hardware Security Module (HSM) based cryptoprocessor
which hashes one or more streams of security measurements from an
Attester within the Attesting Environment.  Maintenance of this
hash enables detection of an Attester which is lying about the set
of security measurements taken.  An example of a HSM is a TPM2.0
TPM2.0.
HSM-based: A Hardware Security Module (HSM) based cryptoprocessor
which hashes one or more streams of security measurements from an
Attester within the Attesting Environment.  Maintenance of this
hash enables detection of an Attester which is not reporting the
exact set of security measurements (such as log entries) taken
within the Attesting Environment.  An example of a HSM is a TPM2.0
TPM2.0.
Elements of the configuration relevant to security are
unavailable to the Verifier.
Zero Trust Architectures are referenced in US-Executive-Order eleven
times.  However despite this high profile, there is an architectural
gap with Zero Trust.  The credentials used for authentication and
admission control can be manipulated on the endpoint.  Attestation
can fill this gap through the generation of a compound credential
called AR-augmented Evidence.
This compound credential is rooted in the hardware based Attesting
Environment of an endpoint, plus the trustworthiness of a Verifier.
The overall solution is known as "Below Zero Trust" as the compound
credential cannot be manipulated or spoofed by an administrator of an
endpoint with root access.  This solution is not adversely impacted
by the potential drawbacks with pure background-check described
above.
Zero Trust Architectures are referenced in US-Executive-Order eleven
times.  However despite this high profile, there is an architectural
gap with Zero Trust.  The credentials used for authentication and
admission control can be manipulated on the endpoint.  Attestation
can fill this gap through the generation of a compound credential
called AR-augmented Evidence.  This compound credential is rooted in
the hardware based Attesting Environment of an endpoint, plus the
trustworthiness of a Verifier.  The overall solution is known as
"Below Zero Trust" as the compound credential cannot be manipulated
or spoofed by an administrator of an endpoint with root access.  This
solution is not adversely impacted by the potential drawbacks with
pure background-check described above.
Draft: draft-ietf-rats-ar4si

Commentary: I want to wait until we have the new definitions being worked in the CCC nailed down . ( They look like they are getting close . ) Then we can just reference or copy these .    . I have raised to track this . 
 LGTM , I 've left a note unrelated to the change , but close enough to maybe deserve being addressed in the same PR ?
HSM-based: A Hardware Security Module (HSM) based cryptoprocessor
which hashes one or more streams of security measurements from an
Attester within the Attesting Environment.  Maintenance of this
hash enables detection of an Attester which is lying about the set
of security measurements taken.  An example of a HSM is a TPM2.0
TPM2.0.
To kick-off the "Below Zero Trust" compound credential creation
sequence, a Verifier evaluates an Attester and returns signed
Attestation Results back to this original Attester no less frequently
than a well-known interval.  This interval may also be asynchronous,
based on the changing of certain Evidence as described in I-
D.birkholz-rats-network-device-subscription.
To kick-off the "Below Zero Trust" compound credential creation
sequence, a Verifier evaluates an Attester and returns signed
Attestation Results back to this original Attester no less frequently
than a well-known interval.  This interval may also be asynchronous,
based on the changing of certain Evidence as described in I-D.ietf-
rats-network-device-subscription.
Draft: draft-ietf-rats-ar4si

Commentary: Misnamed the Issue number . It is actually issue
Prune any Trustworthiness Claims not used in the Appraisal
Policy for Attestation Results.
Allow the information exchange from the Attester into a Relying
Party context where the Verifier B appraised Trustworthiness
Vector includes all the mandatory Trustworthiness Claims of
value "1", and none of the disqualifying Trustworthiness Claims
containing values that are not "0" or "1".
Prune any Trustworthiness Claims from the Trustworthiness
Vector not used in the Appraisal Policy for Attestation
Results.
Allow the information exchange from the Attester into a Relying
Party context in the Appraisal Policy for Attestation Results
where the Verifier B appraised Trustworthiness Vector includes
all the mandatory Trustworthiness Claims are in the "Affirming"
value range, and none of the disqualifying Trustworthiness
Claims are in the "Contraindicated" value range.