jiebi/TextFlow huggingface dataset:
Original text:
A YANG Data Model for Layer 0 Types - Revision 2 <del> draft-ietf-ccamp-layer0-types-ext-00 </del>  Abstract in the YANG data modeling language, which are used in several YANG modules for wavelength Division multiplexing (WDM) transport networks.  The YANG module ietf-layer0-types-ext updates ietf- <del> layer0-types defined in draft-ietf-ccamp-layer0-types, which has been reduced in scope prior to publication to only cover spectrum management related aspects required for the YANG module ietf-wson- topology defined in draft-ietf-ccamp-wson-yang. </del>  To be completed

Reviewer comments:
draft-ietf-ccamp-layer0-types-URL for IETF 112 submission --> draft-ietf-ccamp-layer0-types-ext-URL This revision of the I-D includes the latest YANG model update - see
Submission checks passed (URL):
Thanks!Minor editorial OLD  NEW file "EMAIL"

Revised text:
A YANG Data Model for Layer 0 Types - Revision 2  <ins> draft-ietf-ccamp-layer0-types-ext-01 </ins> Abstract in the YANG data modeling language, which are used in several YANG modules for wavelength Division multiplexing (WDM) transport networks.  The YANG module ietf-layer0-types-ext updates ietf-  <ins> layer0-types defined in RFC9093, which has been reduced in scope prior to publication to only cover spectrum management related aspects required for the YANG module ietf-wson-topology defined in RFC9094. </ins> To be completed
Original text:
Framework and Data Model for OTN Network Slicing <del> draft-ietf-ccamp-yang-otn-slicing-00 </del>  Abstract

Reviewer comments:
Updated README: Aligned URLs with the new location of the repository Added information about CCAMP WG weekly calls Changed I-D version to -01 (-00 has been already published) Delete draft-zheng-ccamp-yang-otn-URL no longer needed to be kept in the repository (still available in GitHub commit history

Revised text:
Framework and Data Model for OTN Network Slicing  <ins> draft-ietf-ccamp-yang-otn-slicing-01 </ins> Abstract
Original text:
1. <del> 2. </del>  <del> The document defines the term "Remote Attestation" as follows: A process by which one entity (the "Attester") provides evidence about its identity and state to another remote entity (the "Relying Party"), which then assesses the Attester's trustworthiness for the Relying Party's own purposes. </del>  <del> This document then uses the following terms: </del>  Appraisal Policy for Evidence: A set of rules that direct how a verifier evaluates the validity of information about an Attester. authorized to configure Appraisal Policy for Evidence in a Verifier. <del> [EDITORIAL NOTE] The term Attestation and Remote Attestation are not defined in this document, at this time.  This document will include pointers to industry uses of the terms, in an attempt to gain consensus around the term, and be consistent with the charter text defining this term. </del> 3. 4.

Reviewer comments:
Removed incorrect text that said Remote Attestation was not defined in the doc. Moved Remote Attestation paragraph to the introduction section where I think it will (eventually) make sense in the context of introduction text. Signed-off-by: Dave Thaler
See comments in URL this term gets re-introduced here, without any annotation. The appraisal policy are the rules on how to test the evidence. Here, "Attestation" is the creation of the evidence Often people use the term "Attestation" to refer to the whole process. Suggestion that we should define this term somewhere, but maybe "Remote Attestation"? NAME FIDO has NONE-Attestation-Type, where there is no assessment. TCG would call this Implicit Attestation. URL NAME Let's take this to the WG, and maybe we can not get consensus on this term. NAME Charter says: "Remote attestation procedures (RATS) enable relying parties to establish a level of confidence in the trustworthiness of remote system components through the creation of attestation evidence by remote system components and a processing chain towards the relying party."
PR added a paragraph defining Remote Attestation, and PR does some additional cleanup.
Can we close this issue now that PR and PR are merged?
yes

Revised text:
1.  <ins> Remote Attestation, as used in this document, is a process by which one entity (the "Attester") provides evidence about its identity and state to another remote entity (the "Relying Party"), which then assesses the Attester's trustworthiness for the Relying Party's own purposes. </ins>  <ins> 2. </ins>  <ins> This document uses the following terms: </ins> Appraisal Policy for Evidence: A set of rules that direct how a verifier evaluates the validity of information about an Attester. authorized to configure Appraisal Policy for Evidence in a Verifier.  3. 4.
Original text:
mechanism. A second approach places the onus of timekeeping solely on the <del> appraising entity, e.g., the Verifier (for Evidence), or the Relying </del>  Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronisation is otherwise impaired.  In this approach, a non-

Reviewer comments:
Thomas suggests: The current paragraph looks wrong to me. When it says: [...] solely on the appraising entity, e.g., the Verifier (for Evidence), or the Relying Party (for Attestation Results),` should instead say: [...] solely on the remote attestation protocol initiator, e.g., the Relying Party (for Evidence or Attestation Results) and the Attester (for Attestation Results).

Revised text:
mechanism. A second approach places the onus of timekeeping solely on the  <ins> appraising entity, i.e., the Verifier (for Evidence), or the Relying </ins> Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronisation is otherwise impaired.  In this approach, a non-
Original text:
8.3. <del> Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy.  A result that indicates non-compliance can be used by an Attester (in the passport model) or a Relying Party (in the background-check model) to indicate that the Attester should not be treated as authorized and may be in need of remediation.  In some cases, it may even indicate that the Evidence itself cannot be authenticated as being correct. </del>  An Attestation Result that indicates compliance can be used by a Relying Party to make authorization decisions based on the Relying

Reviewer comments:
Address issue
Attestation Result is far more than compliance/non-compliance for many / most use cases. Attestation Results may contain lots claims that are passed through from the device (e.g., GPS location). I would also expect information from the Endorsement to be passed through, particularly in the case where the Verifier is an aggregator. Implied claims would also show up in the Attestation Result.
Section 7.3 starts out "Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy" implying binary yes/no results. Section 7.3 needs to get rewritten some so results can be very rich with dozens of claims that are input to the RP's risk engine.
The -05 draft with Attestation Results moved to section 8.3 still has too much emphasis on compliance/non-compliance.

Revised text:
8.3.  <ins> Attestation Results are the input used by the Relying Party to decide the extent to which it will trust a particular Attester, and allow it to access some data or perform some operation.  Attestation Results may be a Boolean simply indicating compliance or non-compliance with a Verifier's Appraisal Policy, or a rich set of Claims about the Attester, against which the Relying Party applies its Appraisal Policy for Attestation Results. A result that indicates non-compliance can be used by an Attester (in the passport model) or a Relying Party (in the background-check model) to indicate that the Attester should not be treated as authorized and may be in need of remediation.  In some cases, it may even indicate that the Evidence itself cannot be authenticated as being correct. </ins> An Attestation Result that indicates compliance can be used by a Relying Party to make authorization decisions based on the Relying
Original text:
A remote server that will securely grant the Attester permission to continue operating (i.e., not reboot) for a period of time  4. dataflow depicts the data that flows between different roles,

Reviewer comments:
Address . There are on the order of 1 billion users of biometric authentication
Discussion: everything you can do, RATS can do better :) Aka every authentication/access control use case is an attestation use case. Laurence to take a first shot at adding text into intro above use cases. Details would be in a doc from FIDO or W3C.
FIDO and Android are attestation use cases with billions of users today and are different from all the ones currently listed, so at least one of them should be added.
Ok to merge

Revised text:
A remote server that will securely grant the Attester permission to continue operating (i.e., not reboot) for a period of time <ins> 3.7. In the Fast IDentity Online (FIDO) protocol WebAuthN, CTAP, the device in the user's hand authenticates the human user, whether by biometrics (such as fingerprints), or by PIN and password.  FIDO authentication puts a large amount of trust in the device compared to typical password authentication because it is the device that verifies the biometric, PIN and password inputs from the user, not the server.  For the Relying Party to know that the authentication is trustworthy, the Relying Party needs to know that the Authenticator part of the device is trustworthy.  The FIDO protocol employs remote attestation for this. The FIDO protocol supports several remote attestation protocols and a mechanism by which new ones can be registered and added.  Remote attestation defined by RATS is thus a candidate for use in the FIDO protocol. Other biometric authentication protocols such as the Chinese IFAA standard and WeChat Pay as well as Google Pay make use of attestation in one form or another. Every FIDO Authenticator contains an Attester. Any web site, mobile application back end or service that does biometric authentication. </ins> 4. dataflow depicts the data that flows between different roles,
Original text:
6. <del> An Attester consists of at least one Attesting Environment and Attested Environment.  In some implementations, the Attesting and Attested Environments might be combined.  Other implementations might have multiple Attesting and Attested Environments. </del>  7.

Reviewer comments:
Incorporating text from draft-birkholz-rats-architecture and from my reading of the "bike shed" mailing list thread Signed-off-by: Dave Thaler

Revised text:
6.  <ins> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments.  One example is a set of components in a boot sequence (e.g., ROM, firmware, OS, and application) where a Target Environment is the Attesting Environment for the next environment in the boot sequence. Target Environments are measured.  They provide the raw values and the information to be represented in claims and ultimately expressed as Evidence. Attesting Environments conduct the measuring.  They collect the claims, format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </ins> 7.
Original text:
A piece of asserted information, often in the form of a name/value pair.  (Compare /claim/ in RFC7519) <del> A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability </del>  An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence

Reviewer comments:
Suggested new text for Endorsements definition to make it slightly more broad, but constrained to the operations of an Attesting Environment (which is a subset of an Attester that also might contain Target Environments and other environments) which is focus for why a Verifier cares to get Endorsements.
This now aligns excellently with the overall terminology. Unfortunately, this now uses a term that is well-defined in section 4.2., but not included in the "upfront" terminology section. This is fine text! But it might now impliy the addition of Attesting Environment into this section.

Revised text:
A piece of asserted information, often in the form of a name/value pair.  (Compare /claim/ in RFC7519)  <ins> A secure statement that an Endorser vouches for the integrity of an Attester's various capabilities such as Claims collection and Evidence signing </ins> An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence
Original text:
10. <del> A remote entity (Verifier or Relying Party) may need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced.  This is essential in deciding whether the included Claims and their values can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. </del>  Freshness is assessed based on a policy defined by the consuming entity, Verifier or Relying Party, that compares the estimated epoch mechanism. A second approach places the onus of timekeeping solely on the <del> appraising entity, i.e., the Verifier (for Evidence), or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time </del>  synchronisation is otherwise impaired.  In this approach, a non- predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or

Reviewer comments:
Looked at all uses of "entity" in the doc to be sure it wasn't referring to Verifier or RP which are roles and found a few issues in the Freshness section.

Revised text:
10.  <ins> A Verifier or Relying Party may need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced.  This is essential in deciding whether the included Claims and their values can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. </ins> Freshness is assessed based on a policy defined by the consuming entity, Verifier or Relying Party, that compares the estimated epoch mechanism. A second approach places the onus of timekeeping solely on the  <ins> appraiser, i.e., the Verifier (for Evidence), or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time </ins> synchronisation is otherwise impaired.  In this approach, a non- predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or
Original text:
16.2. The following example illustrates a hypothetical Passport Model <del> solution that uses nonces and thus does not require that any clocks are synchronized. As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps. Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. </del>  In this example solution, the Verifier can check whether the Evidence is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) <

Reviewer comments:
Line had the closing "}" in the wrong place in the diagram. While touching this text, added phrase about disadvantage of the nonce approach, to provide more balanced discussion of timestamps vs nonces vs handles. Signed-off-by: Dave Thaler

Revised text:
16.2. The following example illustrates a hypothetical Passport Model  <ins> solution that uses nonces instead of timestamps.  Compared to the timestamp-based example, it requires an extra round trip to retrieve a nonce, and requires that the Verifier and Relying Party track state to remember the nonce for some period of time. The advantage is that it does not require that any clocks are synchronized.  As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps.  Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. </ins> In this example solution, the Verifier can check whether the Evidence is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) <
Original text:
An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence <del> A set of information about an Attester that is to be appraised by a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences. </del>  An entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known

Reviewer comments:
Signed-off-by: Dave Thaler
` What’s the difference between claim and evidence? Maybe you start with a Claim, then sign it and that makes it into Evidence? Is Evidence a ‘set of claims’? [and what’s the difference between a ‘set of information’ and ‘information’?]
Maybe "A signed set of Claims about an Attester..."? (Want to make sure it's not "just" a set of claims, since the signing is important too.)

Revised text:
An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence  <ins> A set of Claims generated by an Attester to be appraised by a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences. </ins> An entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known
Original text:
4.2. <del> Reference Values used in appraisal might be specified as part of the appraisal policy itself, or might be obtained from a separate source, such as an Endorsement, and then used by the appraisal policy. </del>  The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document

Reviewer comments:
Signed-off-by: Dave Thaler
` Huh? I thought a Reference Value came from a Reference Value Provider

Revised text:
4.2.  <ins> Reference Values used in appraisal come from a Reference Value Provider and are then used by the appraisal policy.  They might be conveyed in any number of ways, including: * as part of the appraisal policy itself, if the Verifier Owner either: acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; * as part of an Endorsement, if the Endorser either acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; or * via separate communication. </ins> The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document
Original text:
Abstract <del> In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about a remote peer to assess the peer's trustworthiness, and a way to appraise such evidence.  The evidence is typically a set of claims about its software and hardware platform.  This document describes an architecture for such remote attestation procedures (RATS). </del>  1.

Reviewer comments:
The last sentence of the abstract is: but "such" remote attestation procedures are not defined earlier.
This abstract literally reads more self-consistent. +1

Revised text:
Abstract  <ins> In network protocol exchanges it is often the case that one entity requires believable evidence about the operational state of a remote peer.  Such evidence is typically conveyed as claims about the peer's software and hardware platform, and is subsequently appraised in order to assess the peer's trustworthiness.  The process of generating and appraising this kind of evidence is known as remote attestation.  This document describes an architecture for remote attestation procedures that generate, convey, and appraise evidence about a peer's operational state. </ins> 1.
Original text:
value generated at that time, and the Verifier decides that it can trust the time(VG_a) value, the Verifier can also determine whether the claim value is recent by checking "time(RG_v) - time(VG_a) < <del> Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </del>  The Relying Party can check whether the Attestation Result is fresh when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v)

Reviewer comments:
Clarify that recentness of Evidence depends primarily on the appraisal policy and that clock skew is only secondary.
Section "16.1. Example 1", third para: I find the reference to clock skew slightly confusing. The Threshold value here is more likely to depend on a verification policy that defines what is an acceptable "age" of the sampled claim rather than on considerations about clocks drifting.

Revised text:
value generated at that time, and the Verifier decides that it can trust the time(VG_a) value, the Verifier can also determine whether the claim value is recent by checking "time(RG_v) - time(VG_a) <  <ins> Threshold". The threshold is decided by the Appraisal Policy for Evidence, and again needs to take into account the maximum permitted clock skew between the Verifier and the Attester. </ins> The Relying Party can check whether the Attestation Result is fresh when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v)