jiebi/CodeConvo huggingface dataset:
Change:
update my organization association & email id
NAME NAME pls review and merge this PR. We can publish the draft-02 after that.
looks like this one was merged already.

Discussion:
2.7. If the "Idempotency-Key" request header is missing for a documented <del> idempotent operation requiring this header, the resource server MUST reply with an HTTP "400" status code with body containing a link pointing to relevant documentation.  Alternately, using the HTTP </del> <ins> idempotent operation requiring this header, the resource server SHOULD reply with an HTTP "400" status code with body containing a link pointing to relevant documentation.  Alternately, using the HTTP </ins> header "Link", the client can be informed about the error as shown below. If there is an attempt to reuse an idempotency key with a different <del> request payload, the resource server MUST reply with a HTTP "422" </del> <ins> request payload, the resource server SHOULD reply with a HTTP "422" </ins> status code with body containing a link pointing to relevant documentation.  The status code "422" is defined in Section 11.2 of RFC4918.  The server can also inform the client by using the HTTP header "Link" as shown below. If the request is retried, while the original request is still being <del> processed, the resource server MUST reply with an HTTP "409" status </del> <ins> processed, the resource server SHOULD reply with an HTTP "409" status </ins> code with body containing a link or the HTTP header "Link" pointing to the relevant documentation. Error scenarios above describe the status of failed idempotent <del> requests, after the resource server prcocesses them.  Clients MUST correct the requests before performing a retry operation, or the the resource server MUST fail the request and return one of the above errors. </del> <ins> requests after the resource server prcocesses them.  Clients MUST correct the requests (with the execption of 409 where no correction is required) before performing a retry operation, or the the resource server MUST fail the request and return one of the above errors. </ins> For other 4xx/5xx errors, such as 401, 403, 500, 502, 503, 504, 429, or any other HTTP error code that is not listed here, the client
Change:
NAME let me know if this fixes the issue
You'll want to link or close it, but yes, this is good.
This is a problem for our format. Please try to keep examples to 69 columns (or 72 in a pinch). These examples are free-form strings in JSON, so they can probably just be wrapped.
NAME take a look at PR URL and let me know if ok now.

Discussion:
Error scenarios above describe the status of failed idempotent requests after the resource server prcocesses them.  Clients MUST <del> correct the requests (with the execption of 409 where no correction </del> <ins> correct the requests (with the exception of 409 where no correction </ins> is required) before performing a retry operation, or the the resource server MUST fail the request and return one of the above errors.
Change:
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"

Discussion:
A YANG Data Model for Layer 0 Types - Revision 2 <del> draft-ietf-ccamp-layer0-types-ext-00 </del> <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- <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> <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
Change:
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

Discussion:
Framework and Data Model for OTN Network Slicing <del> draft-ietf-ccamp-yang-otn-slicing-00 </del> <ins> draft-ietf-ccamp-yang-otn-slicing-01 </ins> Abstract
Change:
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

Discussion:
1. <del> 2. </del> <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> <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> <ins> 2. </ins> <del> This document then uses the following terms: </del> <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. <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.
Change:
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).

Discussion:
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> <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-
Change:
this is not complete and does not pass xml2rfc yet. Please add/fix your name/email. Or remove your email. Or foo at example dot com it.

Discussion:
15. <ins> Thomas Hardjono created older versions of the terminology section in collaboration with Ned Smith.  Eric Voit provided the conceptual separation between Attestation Provision Flows and Attestation Evidence Flows.  Monty Wisemen created the content structure of the first three architecture drafts.  Carsten Bormann provided many of the motivational building blocks with respect to the Internet Threat Model. 16. </ins> The table below defines a number of relevant events, with an ID that is used in subsequent diagrams.  The times of said events might be defined in terms of an absolute clock time such as Coordinated

How and if clocks are synchronized depends upon the model. <del> 15.1. </del> <ins> 16.1. </ins> The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized

However, if the Attestation Result contains an expiry time time(RX_v) then it could explicitly check "time(OP_r) < time(RX_v)". <del> 15.2. </del> <ins> 16.2. </ins> The following example illustrates a hypothetical Passport Model solution that uses nonces and thus does not require that any clocks

Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)". <del> 15.3. </del> <ins> 16.3. </ins> Handles are a third option to establish time-keeping next to nonces or timestamps.  Handles are opaque data intended to be available to

Model solution that uses handles and requires a trustworthy time source available to the Handle Distributor role. <del> 15.4. </del> <ins> 16.4. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized

The time considerations in this example are equivalent to those discussed under Example 1 above. <del> 15.5. </del> <ins> 16.5. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any
Change:
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.

Discussion:
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> <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
Change:
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

Discussion:
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,
Change:
Incorporating text from draft-birkholz-rats-architecture and from my reading of the "bike shed" mailing list thread Signed-off-by: Dave Thaler

Discussion:
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> <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.
Change:
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.

Discussion:
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> <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
Change:
Per design team meeting today Signed-off-by: Dave Thaler
I think it should be root of trust because it is not a defined term like Attester or Verifier.
Lower case is fine, I think. Any objections?

Discussion:
or compromised devices from getting access to the network and potentially harming others. <del> Typically, solutions start with a specific component (called a "Root of Trust") that provides device identity and protected storage for </del> <ins> Typically, solutions start with a specific component (called a "root of trust") that provides device identity and protected storage for </ins> measurements.  The system components perform a series of measurements <del> that may be signed by the Root of Trust, considered as Evidence about </del> <ins> that may be signed by the root of trust, considered as Evidence about </ins> the hardware, firmware, BIOS, software, etc. that is running. A device desiring access to a network

By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding complexity to the architectural structure.  The unifying component is <del> the Root of Trust and the nested, staged, or chained attestation </del> <ins> the root of trust and the nested, staged, or chained attestation </ins> Evidence produced.  The nested or chained structure includes Claims, collected by the Attester to aid in the assurance or believability of the attestation Evidence.

security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering.  The component that is implicitly trusted is <del> often referred to as a Root of Trust. </del> <ins> often referred to as a root of trust. </ins> A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the

by the Attesting Environment that has the key material that protects the conveyance channel <del> The Root of Trust protects both the conveyance channel key </del> <ins> The root of trust protects both the conveyance channel key </ins> material and the Attesting Environment with equivalent strength protections.

architecture to protect against replay attacks. To assess the security provided by a particular Appraisal Policy, it <del> is important to understand the strength of the Root of Trust, e.g., </del> <ins> is important to understand the strength of the root of trust, e.g., </ins> whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM.
Change:
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.

Discussion:
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> <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 <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> <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
Change:
Based on discussion at IETF about including a very high level summary, and text in the arch docs, draft-birkholz-rats-reference-interaction-model, and draft-birkholz-rats-tuda. Signed-off-by: Dave Thaler
A quick review of the strawman, using the strawman to highlight a few points for discussion.

Discussion:
9. <ins> It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct. To do so, some mechanism of ensuring that the Evidence and Attestation Result are fresh, meaning that there is some degree of assurance that they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence.  There is, however, always a race condition possible in that the state of the Attester, and the Appraisal Policy for Evidence, may change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow the time window to something the Verifier (for Evidence) or Relying Party (for an Attestation Result) is willing to accept. There are two common approaches to providing some assurance of freshness.  The first approach is that a nonce is generated by a remote entity (e.g., the Verifier for Evidence, or the Relying Party for an Attestation Result), and the nonce is then signed and included along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed after the nonce was generated. A second approach is to rely on synchronized clocks, and include a signed timestamp (e.g., using I.D.draft-birkholz-rats-tuda) along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed at that time, as long as it has some assurance that the timestamp is correct.  This typically requires additional claims about the signer's time synchronization mechanism in order to provide such assurance. In either approach, it is important to note that the actual values in claims might have been generated long before the claims are signed. If so, it is the signer's responsibility to ensure that the values are still correct when they are signed.  For example, values might have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. </ins> 10. The conveyance of Evidence and the resulting Attestation Results

also needs to support additional security protections.  For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many <del> use cases. </del> <ins> use cases.  freshness discusses ways in which freshness can be used in this architecture to protect against replay attacks. </ins> To evaluate the security provided by a particular Appraisal Policy, it is important to understand the strength of the Root of Trust,