Tiny editorial corrections

Small corrections made during my review of the entire document.

draft-ietf-rats-endorsements.md

@@ -85,20 +85,20 @@ manner, i.e., a tree.
 The state of an Attester also encompasses the combination of static and
 dynamic composition (e.g., provisioned and deployed software, firmware, and
 micro-code), static and dynamic configuration, and the resulting operational state
-of its components at a certain point of time. Thus, a Verifier needs to receive
+of its components at a certain point in time. Thus, a Verifier needs to receive
 conceptual messages with information about actual state, and information about desired/undesired
 states, and an appraisal policy that controls how the two are compared.
 
 Each Attester in general has at least one Attesting Environment and one Target
 Environment (e.g., hardware, firmware, Operating System, etc.).  Typically, each
 Attester has multiple Target Environments, each with their own set of claims (sometimes
-called a "claim sets") representing their actual state.  Additionally, the number of
+called "claim sets") representing their actual state.  Additionally, the number of
 Target Environments and Attesting Environments that are components of an Attester are not limited.
 
 "Actual state" is a group of claim sets about the actual state of the Attester at a
 given point in time. Each claim set holds claims about a specific Target Environment
 that is essential to determining trustworthiness.  Generally speaking, each claim
-has a name (typically referred to as label and occasionally referred to as a key, code-point, or some other ID)
+has a name (typically referred to as label, and occasionally referred to as key or code-point)
 and a singleton value, being a value collected from a Target Environment of a specific Attester at a given point
 in time. Some claims may inherently have multiple values, such as a list of
 files in a given location on the device, but in the context of this document such
@@ -191,7 +191,7 @@ state if a condition is met.
 A claim is conditional if
 it only applies if other actual state matches Reference Values, according to some
 matching policy.
-For example an Endorser for a given CPU might provide additional
+For example, an Endorser for a given CPU might provide additional
 information about what the CPU supports based on current firmware configuration
 state, or an Endorser might provide additional information that if the
 serial number is in a given range, then a specific security guarantee is present.
@@ -204,7 +204,7 @@ Verifier policies around matching actual state against
 reference state are normally expressed in Appraisal Policy for Evidence.
 Similarly, reference state is normally expressed in the Reference Values
 conceptual message.  Such policies allow a Verifier and Relying Parties to make
-their decisions about trustworthiness of an Attester.
+their decisions about the trustworthiness of an Attester.
 
 The use of conditionally endorsed values, however, is different in that
 a matching policy is not about trustworthiness (and hence not "appraisal" per se)
@@ -267,7 +267,7 @@ of the Endorsement itself (e.g., using a certificate lifetime) is provided.
 {{Section 8.1 of RFC9334}} discusses timeliness of claims in Evidence.  When
 additional static claims are provided in Endorsements, no additional steps
 are needed for timeliness of those claims since they are static rather than
-dynamically varying by time.  Once timeliness of Evidence is verified,
+dynamically varying over time.  Once timeliness of Evidence is verified,
 any matching conditionally endorsed values can be applied.
 
 If Endorsements ever carry dynamic claims in the future (e.g., whether
@@ -278,7 +278,7 @@ and would be the responsibility of specific protocol documents. See
 
 # Multiple Endorsements {#multiple-endorsements}
 
-Figure {{input}} showed an example with an Endorsement at layer 0, such as
+{{input}} shows an example with an Endorsement at layer 0, such as
 a hardware manufacturer providing claims about the hardware. However, the
 same could be done at other layers in addition.  For example, an OS vendor
 might provide additional static claims about the OS software it provides,
@@ -329,7 +329,7 @@ Attester -------------------------------------------'
 {: #multiple artwork-align="center" title="Multiple Endorsements"}
 
 When Target Environments from different vendors each have their own
-Endorser, it is important that a Verifier be able to distinguish
+Endorser, a Verifier must be able to distinguish
 which Endorser is allowed to provide an Endorsement about which
 Target Environment.  For example, the OS Endorser might be trusted to
 provide additional claims about the OS, but not about the hardware.
@@ -377,11 +377,11 @@ and a very simple (by comparison) Appraisal Policy for Evidence and desired stat
 a required trust anchor that Evidence must be signed with and little else).
 
 Using the same message format for Evidence, Endorsements, and (later) Attestation Results received
-from the later Verifier, can provide a code size savings due to having only a single parser
+from the later Verifier, can provide code size savings due to having only a single parser
 in this limited case.
 
 Similarly, an embedded constrained Verifier can choose to not support conditionally
-endorsed values, in order to avoid complexity introduced by such.
+endorsed values, in order to avoid the complexity introduced by such.
 
 # Security Considerations
 
@@ -391,7 +391,7 @@ storing a trust anchor for the Endorser.  The binding from an Endorsement to
 a given Target Environment is done as discussed in {{endorsing-keys}} of this document.
 
 {{RFC9334}} (especially Section 3.2 and Section 12) also discusses security considerations
-around the attestation of layers, and around sources of appraisal policies.
+around the attestation of layers, and sources of appraisal policies.
 {{endorsing-keys}} of this document covers additional considerations in these areas,
 and {{formats-security}} covers additional considerations around Endorsement formats.