jiebi/TextFlow huggingface dataset:
Original text:
In addition, for each PDAParam instance, leaders are required to: <del> Ensure that, for each report, all aggregator shares are either included or not in a given batch; </del> Implement and store state for the form of inter- and intra-batch replay mitigation in anti-replay; and

Reviewer comments:
I also deleted a bunch of the (outdated) system design text. I'm sure this can be simplified, but I think this captures the basic assumptions (at least in my mental model).
Indeed, the text doesn't require any specific mitigation, and I don't see why it should. Aggregators could do the thing described in the appendix, or they could keep a huge list of all reports seen thus far. There could even be some simpler variant in the future I don't think we lose anything by eliding the implementation details here.

Revised text:
In addition, for each PDAParam instance, leaders are required to:  Implement and store state for the form of inter- and intra-batch replay mitigation in anti-replay; and
Original text:
This document recognizes three general categories of Attesters. HSM-based: A Hardware Security Module (HSM) based cryptoprocessor <del> which continually hashes security measurements in a way which prevents an Attester from lying about measurements which have been extended into the Attesting Environment (e.g., TPM2.0.) </del>  Process-based: An individual process which has its runtime memory encrypted by an Attesting Environment in a way that no other 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, <del> based on the changing of certain Evidence as described in I- D.birkholz-rats-network-device-subscription. </del>  When a Relying Party is to receive information about the Attester's trustworthiness, the Attesting Environment assembles the minimal set

Reviewer comments:
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. Eric
WFM. 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?

Revised text:
This document recognizes three general categories of Attesters. HSM-based: A Hardware Security Module (HSM) based cryptoprocessor  <ins> 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. </ins> Process-based: An individual process which has its runtime memory encrypted by an Attesting Environment in a way that no other 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,  <ins> based on the changing of certain Evidence as described in I-D.ietf- rats-network-device-subscription. </ins> When a Relying Party is to receive information about the Attester's trustworthiness, the Attesting Environment assembles the minimal set
Original text:
Trustworthiness Claims being relied upon from the Verifier considered the chain of trust for the Attesting Environment. <del> There are two categorizations Verifier identities defined in this document. </del>  verifier build: a unique instance of a software build running as a Verifier.

Reviewer comments:
"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

Revised text:
Trustworthiness Claims being relied upon from the Verifier considered the chain of trust for the Attesting Environment.  <ins> There are two categorizations of Verifier identities defined in this document: </ins> verifier build: a unique instance of a software build running as a Verifier.
Original text:
any distinction between a Trustworthiness Claim with enumeration '0', and no Trustworthiness Claim being provided. <del> 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. </del>  Value -1: A verifier malfunction occurred during the Verifier's appraisal processing. No assertion <del> Verifer cannot parse unexpected Evidence. </del>  Verifier malfunction

Reviewer comments:
Include changes from Sergei's semantic musings.
a little late, but this is an easy oneLGTM, I have inlined an editorial suggestion.

Revised text:
any distinction between a Trustworthiness Claim with enumeration '0', and no Trustworthiness Claim being provided.  <ins> 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. </ins> Value -1: A verifier malfunction occurred during the Verifier's appraisal processing. No assertion  <ins> Evidence contains unknown elements which inhibit Verifer evaluation. </ins> Verifier malfunction
Original text:
an Attester, which enables Relying Parties, for example, to assess an Attester's trustworthiness.  7.2. Uni-Directional Remote Attestation procedures can be initiated both

Reviewer comments:
NAME : Please let me know, your views as to how is the information flow and anything else, we need to add?

Revised text:
an Attester, which enables Relying Parties, for example, to assess an Attester's trustworthiness. <ins> 7.1.1. According to the RATS Architecture, two reference models for Challenge/Response Attestation have been proposed.  This section highlights the information flows bewteen the Attester, Verifier and Relying Party undergoing Remote Attestation Procedure, using these models. Passport Model The passport model is so named because of its resemblance to how nations issue passports to their citizens.  In this Model, the attestation sequence is a two step procedure.  In the first step, an Attester conveys Evidence to a Verifier which compares the Evidence against its appraisal policy.  The Verifier then gives back an Attestation Result to the Attester, which simply caches it.  In the second step, the Attester presents the Attestation Result (and possibly additional Claims/evidence) to a Relying Party, which then compares this information against its own appraisal policy to establish the trustworthiness of the attestor. BackGround Check Model The background-check model is so named because of the resemblance of how employers and volunteer organizations perform background checks. In this model, the attestation sequence is initiated by a Relying Party.  The Attester conveys Evidence to the Relying Party, which does not process its payload, but realys the message and optionally check its signature against a policed trust anchor store.  Upon receiving the evidence the Relying Party initiates a session with the Verifier.  Once session is established, it forwards the received Evidence to the Verfier.  The Verifier, appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party.  The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. </ins> 7.2. Uni-Directional Remote Attestation procedures can be initiated both
Original text:
(for example, to keep the implementation complexity to a minimum) and has a secure channel, such as a local IPC, to interact with a lead Attester (see Composite Device, I-D.ietf-rats-architecture).  The <del> sub-Attester produces a UCCS with the required set of claims and </del>  sends the UCCS through the secure channel to the lead Attester.  The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example, Environment based on the cryptographic mechanisms used when a privacy preserving secure channel is employed. <del> In the case of a Remote Attestation, the attester must consider </del>  whether any UCCS it returns over a privacy preserving secure channel compromises the privacy in unacceptable ways.  As an example, the use of the EAT UEID I-D.ietf-rats-eat Claim in UCCS over a privacy

Reviewer comments:
(As per Ned Smith's message of November 8, 2022)
Claim Key as specified in RFC8392 are currently called lables in the CDDL in the Appendix. "Claim Key" by itself is only used in the definition of UCCS and never again. Should we decide on a consistent use of Claim Key or highlight that is a synonym to label before the CDDL in appendix?

Revised text:
(for example, to keep the implementation complexity to a minimum) and has a secure channel, such as a local IPC, to interact with a lead Attester (see Composite Device, I-D.ietf-rats-architecture).  The  <ins> sub-Attester produces a UCCS with the required CWT Claims Set and </ins> sends the UCCS through the secure channel to the lead Attester.  The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example, Environment based on the cryptographic mechanisms used when a privacy preserving secure channel is employed.  <ins> In the case of a Remote Attestation, the Attester must consider </ins> whether any UCCS it returns over a privacy preserving secure channel compromises the privacy in unacceptable ways.  As an example, the use of the EAT UEID I-D.ietf-rats-eat Claim in UCCS over a privacy
Original text:
Secure Automation and Continuous Monitoring (SACM) Architecture <del> draft-ietf-sacm-architecture-04 </del>  Abstract

Reviewer comments:
Revise the document to not have a specific version number Fire off travis to get a build running.

Revised text:
Secure Automation and Continuous Monitoring (SACM) Architecture  <ins> draft-ietf-sacm-architecture-latest </ins> Abstract
Original text:
5. <del> This specification defines the following expressions for use in CoSWID and to provide interoperability with schemes used in SWID. Because both the "swid" and "swidpath" schemes are to be interpreted within a local, rather than a global, context, neither of these scheme are URIs as defined in RFC3986 and the swid and swidpath scheme names are not registered as permanent schemes with IANA.  That noted, swid and swidpath expressions conform to all rules for URI </del>  syntax.  All uses of these expressions encountered within a CoSWID are to be interpreted as described in this section. 6.6.  The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification RFC8412 defines a standardized method for collecting an endpoint device's software inventory.  A CoSWID can provide evidence

Reviewer comments:
Added back IANA registrations (as provisional) for swid and swidpath URI schemes. Slight re-wording of the intro paragraph to section 5 (discussing the schemes) to reflect this modification.

Revised text:
5.  <ins> This specification defines the following scheme names for use in CoSWID and to provide interoperability with scheme names used in SWID.  Because both the "swid" and "swidpath" scheme names are to be interpreted within a local (rather than a global) context, neither of these are technically URI scheme names as defined in RFC3986.  For this reason, the swid and swidpath scheme names are registered with IANA as provisional, rather than permanent, scheme names.  However, registering these scheme names as provisional ensures that the scheme names are reserved and that they are properly defined going forward. The swid and swidpath expressions conform to all rules for URI </ins> syntax.  All uses of these expressions encountered within a CoSWID are to be interpreted as described in this section. 6.6. <ins> The ISO 19770-2:2015 SWID specification describes use of the "swid" and "swidpath" URI schemes, which are currently in use in implementations.  This document continues this use for CoSWID.  The following subsections provide registrations for these schemes in to ensure that a registration exists for these schemes that is suitable for use in the SWID and CoSWID specifications.  URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at IANA.uri-schemes. 6.6.1. IANA is requested to register the URI scheme "swid".  This registration request complies with RFC7595. 6.6.2. IANA is requested to register the URI scheme "swidpath".  This registration request complies with RFC7595. 6.7. </ins> The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification RFC8412 defines a standardized method for collecting an endpoint device's software inventory.  A CoSWID can provide evidence
Original text:
Secure Automation and Continuous Monitoring (SACM) Terminology <del> draft-ietf-sacm-terminology-07 </del>  Abstract

Reviewer comments:
A couple of bookkeeping changes: Fix a format error in the readme Make the date be the date it was generated rather than a fixed date Change the document title to be more generic as it does not match the published numbered version on the IETF website.

Revised text:
Secure Automation and Continuous Monitoring (SACM) Terminology  <ins> draft-ietf-sacm-terminology-latest </ins> Abstract
Original text:
information to the timestamp. This document does not address extensions to the format where the <del> semantic result no longer is a fixed timestamp that is referenced to </del>  a (past or future) UTC time.  For instance, it does not address: Future time given as a local time in some specified time zone, Actual keys are registered by supplying the information in record: <del> 'Identifier' contains the key name. </del>  'Description' contains the name and description of the namespace. 4. <del> Define a registry that can contain both namespaces and keys. Namespaces can be recognized by ending with a hyphen/minus.  Actual keys do not.  See registered for the detailed information (to be edited). </del>  The policy is "RFC required", "Specification Required", ??? RFC8126.

Reviewer comments:
Replace "DST" and "daylight savings time" with "daylight saving time" Replace "timezone" with "time zone" Properly capitalize "Unicode Consortium" Improve phrasing
If you don't have time to work further on this very useful PR, I could merge it and fix these three nits.
Please don't add material to this one. We went the opposite direction in the last interim, so I'm about to remove some of this text.
OK, I pushed a commit just before your last comment but will withhold any further changes.
Sorry for the unsmooth handling of this PR. I now cherry-picked from this PR. Can I ask you to rebase to main and see what remaining parts you want to pursue?
My last message was too close to the holidays. Do you want to rebase this PR? Or do you think it is essentially covered by my cherry-picking?
Thanks for the ping, NAME Almost everything was covered by the cherry-picking, but a few things remain. I have rebased the PR to include only those.

Revised text:
information to the timestamp. This document does not address extensions to the format where the  <ins> semantic result is no longer a fixed timestamp that is referenced to </ins> a (past or future) UTC time.  For instance, it does not address: Future time given as a local time in some specified time zone, Actual keys are registered by supplying the information in record:  <ins> 'Identifier' contains the key name.  A key name ending with a hyphen/ minus sign ""-"" is a namespace that covers all timestamp tag keys beginning with that prefix. </ins> 'Description' contains the name and description of the namespace. 4.  <ins> IANA is requested to establish a registry called "Timestamp Suffix Tag Keys".  Each entry in the registry shall consist of the information described in registered.  Initial contents of the registry are specified in namespaced. </ins> The policy is "RFC required", "Specification Required", ??? RFC8126.
Original text:
IXDTF strings such as: <del> are internally inconsistent, as Europe/Paris does not use a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </del>  Similar with:

Reviewer comments:
Minor fix of 3.3, now that we have 3.4. There is still a certain amount of redundancy between the two sections, which might be smoothened out by further editorial action. For now, let's get agreement on Section 2 before further tinkering.

Revised text:
IXDTF strings such as:  <ins> are internally inconsistent (see inconsistent), as Europe/Paris did not use a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </ins> Similar with:
Original text:
political decisions as discussed above, or  errors in the applications producing and consuming such a timestamp.

Reviewer comments:
Minor suggested update to the RFC draft to explain another reason for conflicts: TZDB updates are not applied to all computers at the same time.
LGTM

Revised text:
political decisions as discussed above, or <ins> updates to time zone definitions being applied at different times by timestamp producers and receivers, or </ins> errors in the applications producing and consuming such a timestamp.
Original text:
set of protocols and algorithms that are requested by applications or by a system policy.  2. The following terms are used throughout this document to describe the

Reviewer comments:
Do you think this non-goal is helpful for people who are confused that "important" security protocols are omitted from this survey? (e.g. )
This document is a survey of network security protocols and their interaction with transport and application protocols. It is clearly written and easy to read. I have a minor comment on the contents of this draft. It is not abundantly clear what the criteria was for selecting the subset of security protocols included in this draft. Some notable omissions include SSH, L2TP, and GRE. These seem like interesting omissions given their popularity in a number of deployment scenarios. Not a showstopper in my opinion, but interesting to note.
Proposal: Add a paragraph to non-goals saying that we are not attempting to provide a comprehensive survey of all security protocols, or a survey of all "important" protocols that a TAPS implementation would have to support. Perhaps this also isn't entirely clear in the Introduction, which says our included protocols represent "a superset of features a Transport Services system may need to support". By this, we mean that it may need to implement any protocol that provides these features, and/or it may need to expose an interface to configure these features. We do NOT mean that the Transport Services System has to implement these exact protocols, or that it should limit itself to these protocols. But people might be misunderstanding it this way.
I think this is a fine idea -- thanks for the PR!

Revised text:
set of protocols and algorithms that are requested by applications or by a system policy. <ins> The protocols surveyed in this document represent a superset of functionality and features a Transport Services system may need to support.  It does not list all transport protocols that a Transport Services system may need to implement, nor does it mandate that a Transport Service system implement any particular protocol. A Transport Services system may implement any secure transport protocol that provides the described features.  In doing so, it may need to expose an interface to the application to configure these features. </ins> 2. The following terms are used throughout this document to describe the
Original text:
QUIC <del> ESP IPsec OpenVPN </del> tcpcrypt MinimaLT  WireGuard  5.2. Identity Validation (IV): During a handshake, the security

Reviewer comments:
Read through the Opsdir review we recently got. Not sure we want to add anything to that BGP questions, but there was also a minor editorial nit, which this PR fixes. Now the order of these protocols is the same as in the table.

Revised text:
QUIC  tcpcrypt MinimaLT <ins> IPsec ESP </ins> WireGuard <ins> OpenVPN </ins> 5.2. Identity Validation (IV): During a handshake, the security
Original text:
querying for their presence and support.  Optional features may not be implemented, or may be disabled if their presence impacts transport services or if a necessary transport service or application <del> dependency is unavailable.  In this context, an application dependency is one required from an application in order to function. </del>  5.1. Record or datagram confidentiality and integrity.  Forward-secure key establishment.  Public-key certificate based authentication.  Unilateral responder authentication. <del> Note that most systems provide defailt trust stores used to authenticate peers based on certificates.  In such systems, applications need not provide any trust information.  Applications running on systems without such a feature must necessary depend on applications for this information so as to authenticate peers. </del>  5.2.

Reviewer comments:
As promised at IETF 103, here's a suggested definition of application dependency, to make it clearer what I'm talking about. I have also added dependencies for the mandatory features, so that it's clear for all features whether they have any application dependencies. In addition, I changed the heading of the section because the section does not actually talk about transport dependencies anymore. What do you think?
Yep, I agree. This change looks good. Thank you, NAME good with these changes.

Revised text:
querying for their presence and support.  Optional features may not be implemented, or may be disabled if their presence impacts transport services or if a necessary transport service or application  <ins> dependency is unavailable. In this context, an application dependency is an aspect of the security feature which can be exposed to the application.  An application dependency may be required for the security feature to function, or it may provide additional information and control to the application.  For example, an application may need to provide information such as keying material or authentication credentials, or it may want to restrict which cryptographic algorithms to allow for negotiation. </ins> 5.1. Record or datagram confidentiality and integrity. <ins> Application dependency: None. </ins> Forward-secure key establishment. <ins> Application dependency: None. </ins> Public-key certificate based authentication. <ins> Application dependency: Application providing trust information.  Note that most systems provide default trust stores used to authenticate peers based on certificates.  In such systems, applications need not provide any trust information. </ins> Unilateral responder authentication.  <ins> Application dependency: Application providing trust information, see above. </ins> 5.2.
Original text:
Source Address Validation: The handshake protocol may delegate validation of the remote peer that has sent data to the transport protocol or application.  This involves sending a cookie exchange <del> to avoid DoS attacks.  Protocols: QUIC + TLS, DTLS, WireGuard </del>  DTLS QUIC  WireGuard 5.3.

Reviewer comments:
Addresses
Comment from Ekr's review of -10: S 5.2. IKE has source address validation, no?
Right! I'll change that in my summary table in .

Revised text:
Source Address Validation: The handshake protocol may delegate validation of the remote peer that has sent data to the transport protocol or application.  This involves sending a cookie exchange  <ins> to avoid DoS attacks. </ins> DTLS QUIC <ins> IKEv2 </ins> WireGuard 5.3.