jiebi/TextFlow huggingface dataset:
Original text:
itself with its own key in the "client" field and sign the request just as any client instance would. <del> [[ See issue #116 [3] ]] </del>  The AS responds with a token for the downstream RS2 as described in I-D.ietf-gnap-core-protocol.  The downstream RS2 could repeat this

Reviewer comments:
Expands the definition of the resource set registration protocol, used by an RS to declare a resource set to an AS at runtime and receive a reference identifier for that resource set to hand to a client.
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: f9aac0b2af163c0f9a58ba17e93db7e8956140bf :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Registering a Resource Handle: Editor's note: It's not an exact match here because the "resource_handle" returned now represents a collection of objects instead of a single one. Perhaps we should let this return a list of strings instead? Or use a different syntax than the resource request? Also, this borrows heavily from UMA 2's "distributed authorization" model and, like UMA, might be better suited to an extension than the core protocol

Revised text:
itself with its own key in the "client" field and sign the request just as any client instance would.  <ins> [[ See issue #116 [2] ]] </ins> The AS responds with a token for the downstream RS2 as described in I-D.ietf-gnap-core-protocol.  The downstream RS2 could repeat this
Original text:
[1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115 <del> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/117 [3] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </del> 

Reviewer comments:
Expands the definition of the resource set registration protocol, used by an RS to declare a resource set to an AS at runtime and receive a reference identifier for that resource set to hand to a client.
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: f9aac0b2af163c0f9a58ba17e93db7e8956140bf :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Registering a Resource Handle: Editor's note: It's not an exact match here because the "resource_handle" returned now represents a collection of objects instead of a single one. Perhaps we should let this return a list of strings instead? Or use a different syntax than the resource request? Also, this borrows heavily from UMA 2's "distributed authorization" model and, like UMA, might be better suited to an extension than the core protocol

Revised text:
[1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115  <ins> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </ins>
Original text:
6. <del> Encoding notifications for the HTTPS notifications is the same as the encoding notifications as defined in RFC8040 Section 6.4, with the following changes.  Instead of saying that for JSON-encoding purposes, the module name for "notification" element will be "ietf- restconf, it will say that for JSON-encoding purposes, the module name for "notification" element will be "ietf-https-notif". With those changes, the SSE event notification encoded JSON example that would be sent over the HTTPS notif transport would appear as follows: </del>  7.

Reviewer comments:
This adds an XML example. The only question is whether we need a prefix for ietf-https-notif in the example.

Revised text:
6.  <ins> Notifications are encoded as defined in RFC8040 Section 6.4.  The examples in that section apply for sending notifications over the "https-notif" based transport. An example of YANG-Push in JSON would look something like this: An example of YANG-Push in XML would look something like this: </ins> 7.
Original text:
If the "Idempotency-Key" request header is missing for a documented idempotent operation requiring this header, the resource server SHOULD reply with an HTTP "400" status code with body containing a <del> link pointing to relevant documentation.  Alternately, using the HTTP header "Link", the client can be informed about the error as shown below. </del>  If there is an attempt to reuse an idempotency key with a different request payload, the resource server SHOULD reply with a HTTP "422" status code with body containing a link pointing to relevant documentation.  The status code "422" is defined in Section 11.2 of <del> RFC4918.  The server can also inform the client by using the HTTP header "Link" as shown below. </del>  If the request is retried, while the original request is still being processed, the resource server SHOULD reply with an HTTP "409" status <del> code with body containing a link or the HTTP header "Link" pointing to the relevant documentation. </del>  Error scenarios above describe the status of failed idempotent requests after the resource server prcocesses them.  Clients MUST

Reviewer comments:
Issue
NAME NAME pl review re issue
Looks good
the examples of errors use a pattern of using a link in a header, and then (supposedly) using a human-readable error message. what about using RFC 7807 instead and using examples that use problem reports to indicate failure semantics in addition to the status code?
I agree. coming up in the next draft.
NAME should we close this issue if it is resolved?
NAME closing this issue. Let me know if not addressed with my latest PR.

Revised text:
If the "Idempotency-Key" request header is missing for a documented idempotent operation requiring this header, the resource server SHOULD reply with an HTTP "400" status code with body containing a  <ins> link pointing to relevant documentation.  Following examples shows an error response describing the problem using RFC7807. Alternately, using the HTTP header "Link", the client can be informed about the error as shown below. </ins> If there is an attempt to reuse an idempotency key with a different request payload, the resource server SHOULD reply with a HTTP "422" status code with body containing a link pointing to relevant documentation.  The status code "422" is defined in Section 11.2 of  <ins> RFC4918. The server can also inform the client by using the HTTP header "Link" as shown below. </ins> If the request is retried, while the original request is still being processed, the resource server SHOULD reply with an HTTP "409" status  <ins> code with body containing problem description. Or, alternately using the HTTP header "Link" pointing to the relevant documentation </ins> Error scenarios above describe the status of failed idempotent requests after the resource server prcocesses them.  Clients MUST
Original text:
An Attester creates Evidence that is conveyed to a Verifier. The Verifier uses the Evidence, and any Endorsements from Endorsers, <del> by applying an Evidence Appraisal Policy to assess the </del>  trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might be obtained from an Endorser along with the Endorsements, or might be

Reviewer comments:
Change "Evidence Appraisal Policy" -> "Appraisal Policy for Evidence" Fixes editorial nit reported to me by Tolga Acar Signed-off-by: Dave Thaler
looks good.

Revised text:
An Attester creates Evidence that is conveyed to a Verifier. The Verifier uses the Evidence, and any Endorsements from Endorsers,  <ins> by applying an Appraisal Policy for Evidence to assess the </ins> trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might be obtained from an Endorser along with the Endorsements, or might be
Original text:
by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might <del> be obtained from an Endorser along with the Endorsements, or might be obtained via some other mechanism such as being configured in the Verifier by an administrator. </del>  The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Appraisal Policy for Attestation <del> Results might, for example, be configured in the Relying Party by an administrator. </del>  4.1.

Reviewer comments:
Also, my assumption is that all messages, configs and such go over one of the arrows in the figure. There are no back channels for things that are vital to or a major part of attestation. Seems like it would be a poor document if the major parts of attestation are not explicitly carried in the flows depicted.

Revised text:
by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might  <ins> be obtained from an Endorser along with the Endorsements, and/or might be obtained via some other mechanism such as being configured in the Verifier by the Verifier Owner. </ins> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Appraisal Policy for Attestation  <ins> Results is configured in the Relying Party by the Relying Party Owner, and/or is programmed into the Relying Party. </ins> 4.1.
Original text:
12.  Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia, and Nancy Cam-Winget.

Reviewer comments:
Merged from draft-thaler-rats-URL Signed-off-by: Dave Thaler
PR and PR merged text that I had, and continue to have, problems with. A summary of the problems follows: 1) It includes events (CC, RP) that are not used in any checks in the text. I had pointed this out before when the PR was generated, but the PR was merged without addressing this comment. 2) The section about using timestamps with synchronized clocks was removed and replaced with a section that talks about a different mechanism (handles) that is not in any RFC or WG document. I believe that such replacement is inappropriate. If the WG adopts a document that talks about a handle distribution mechanism, then a section can be added. Or if there is a standard from another org that can be referenced then it's fine to add one in that case too. But I think it should not replace the section discussing the well known technique of synchronized clocks (e.g., using secure NTP, or PTP (IEEE 1588-2002) or whatever other standard mechanism). 3) time(HD) is problematic as phrased since all the other events are times as seen by a single entity, whereas time(HD) does not clearly say whose perspective (i.e., whose clock) it is from... is it the distributor's? Text is unclear. 4) It talks about nonces in a timestamp section, which I think causes confusion since there's already a separately section about nonces and this section is labeled to be scoped to timestamps. Addressing might address this naturally, if it uses a different section title. 5) There are some editorial typos, such as capital "The" in the middle of a sentence, etc. 6) I have no idea what "delta(time(HD),time(EG))distribution-interval" is supposed to mean. Normally I would expect an equality for any condition to be evaluated, but I have no idea what this check is. 7) time(HD) and time(EG) are according to different clocks (if my guess about point 3 above is right) and so the delta is not directly comparable. I'm not sure how point 6 accounts for this. 8) The phrase "A nonce not predictable to an Attester (recentness & uniqueness) is sent to an Attester" has "(recentness & uniqueness)" which doesn't read well (sounds like bad grammar) to me, and is not explained.
Hopefully PR now addresses this issue.
PR reverts the text, leaving the work in progress in PR
fixed by .

Revised text:
12. <ins> This document does not require any actions by IANA. 13. </ins> Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia, and Nancy Cam-Winget.
Original text:
An Attester creates Evidence that is conveyed to a Verifier. <del> The Verifier uses the Evidence, and any Endorsements from Endorsers, by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might be obtained from an Endorser along with the Endorsements, and/or might be obtained via some other mechanism such as being configured in the Verifier by the Verifier Owner. </del>  The Relying Party uses Attestation Results by applying its own appraisal policy to make application-specific decisions such as

Reviewer comments:
adding the Reference Values to fix issue 185
` And the Verifier uses the Reference Values
I agree that Reference Values should be mentioned here.

Revised text:
An Attester creates Evidence that is conveyed to a Verifier.  <ins> The Verifier uses the Evidence, any Reference Values from Reference Value Providers, and any Endorsements from Endorsers, by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might be obtained from an Endorser along with the Endorsements, and/or might be obtained via some other mechanism such as being configured in the Verifier by the Verifier Owner. </ins> The Relying Party uses Attestation Results by applying its own appraisal policy to make application-specific decisions such as
Original text:
It is also worth pointing out that the choice of model is generally up to the Relying Party.  The same device may need to create Evidence for different Relying Parties and/or different use cases.  For <del> instance, it would provide Evidence to a network infrastructure device to gain access to the network, and to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </del>  combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an

Reviewer comments:
update the "Combinations" section to fix issue .
How does this show that both models are required in this example? I suggest changing this sentence in this way. Because I think the combinations have several possibilities and there is no need to detail all possibilities. Any other thoughts?

Revised text:
It is also worth pointing out that the choice of model is generally up to the Relying Party.  The same device may need to create Evidence for different Relying Parties and/or different use cases.  For  <ins> instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </ins> combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an
Original text:
As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles.  As a wide-area network connected entity, it may implement an <del> Attester role.  The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. </del>  In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this

Reviewer comments:
Signed-off-by: Dave Thaler
` Isolate? From what? “Isolation” seems to be used several times in this and later sections without saying who’s isolating what from whom.
I don't understand that sentence either. Propose removing it. Another sentence: Propose removing "isolation and" Other uses of isolation I think are fine, where it means that an Attesting Environment cannot be modified by a Target Environment it measures. Any way of protecting that might be called "isolating" the two environments from each other in some way.

Revised text:
As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles.  As a wide-area network connected entity, it may implement an  <ins> Attester role. </ins> In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this
Original text:
12.1. <del> Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning the Attestation key material.  If either of these are compromised, the remote attestation becomes worthless because the attacker can forge Evidence. </del>  Remote attestation applies to use cases with a range of security requirements, so the protections discussed here range from low to

Reviewer comments:
Signed-off-by: Dave Thaler
` Isolate? From what? “Isolation” seems to be used several times in this and later sections without saying who’s isolating what from whom.
I don't understand that sentence either. Propose removing it. Another sentence: Propose removing "isolation and" Other uses of isolation I think are fine, where it means that an Attesting Environment cannot be modified by a Target Environment it measures. Any way of protecting that might be called "isolating" the two environments from each other in some way.

Revised text:
12.1.  <ins> Implementers need to pay close attention to the protection of the Attester and the factory processes for provisioning the Attestation key material.  If either of these are compromised, the remote attestation becomes worthless because an attacker can forge Evidence or manipulate the Attesting Environment.  For example, a Target Environment should not be able to tamper with the Attesting Environment that measures it, by isolating the two environments from each other in some way. </ins> Remote attestation applies to use cases with a range of security requirements, so the protections discussed here range from low to
Original text:
vouched for via Endorsements because no Evidence is generated about them are referred to as roots of trust. <del> The manufacturer of the Attester arranges for its Attesting Environment to be provisioned with key material.  The key material is typically in the form of an asymmetric key pair (e.g., an RSA or ECDSA private key and a manufacturer-signed IDevID certificate) secured in the Attester. The Verifier is provided with an appropriate trust anchor, or provided with a database of public keys (rather than certificates), or even carefully secured lists of symmetric keys.  The nature of how the Verifier manages to validate the signatures produced by the Attester is critical to the secure operation of an Attestation system, but is not the subject of standardization within this architecture. </del>  A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the

Reviewer comments:
` 1) Is this a normative statement? 2) I think the next paragraph says that maybe it’s not an asymmetric key, and anyways, keys are out of scope for RATS Arch
In a layered device architecture the previous layer "provisions" the next layer. Hence, it isn't possible for the 'manufacturer' entity to do that. I don't know why a section on "Verifier" is going into so much detail about the Attester.

Revised text:
vouched for via Endorsements because no Evidence is generated about them are referred to as roots of trust.  <ins> The manufacturer having arranged for an Attesting Environment to be provisioned with key material with which to sign Evidence, the Verifier is then provided with some way of verifying the signature on the Evidence.  This may be in the form of an appropriate trust anchor, or the Verifier may be provided with a database of public keys (rather than certificates) or even carefully secured lists of symmetric keys. The nature of how the Verifier manages to validate the signatures produced by the Attester is critical to the secure operation of an Attestation system, but is not the subject of standardization within this architecture. </ins> A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the
Original text:
boot, or immutable hardware/ROM. It is also important that the appraisal policy was itself obtained <del> securely.  As such, if appraisal policies for a Relying Party or for a Verifier can be configured via a network protocol, the ability to create Evidence about the integrity of the entity providing the appraisal policy needs to be considered. </del>  The security of conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding

Reviewer comments:
` Does this mean to imply that bogus policy can’t be installed by sneakernet, e.g., on a usb thumb drive??
I don't think the 'via a network protocol' is necessary. The consideration is simply that policies have security considerations that are out of scope of the architecture.

Revised text:
boot, or immutable hardware/ROM. It is also important that the appraisal policy was itself obtained  <ins> securely.  If an attacker can configure appraisal policies for a Relying Party or for a Verifier, then integrity of the process is compromised. </ins> The security of conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding
Original text:
Claims about a root of trust typically are asserted by Endorsers. The device illustrated in layered includes (A) a BIOS stored in read- <del> only memory, (B) an updatable bootloader, and (C) an operating system kernel. </del>  Attesting Environment A, the read-only BIOS in this example, has to ensure the integrity of the bootloader (Target Environment B).  There

Reviewer comments:
` The loader environment only exists for a second or two, and has few resources… how it is supposed to report evidence to a verifier in that window?
Refers to figure 3, in section 3.4, on layered attestation.
It is rare that early layers generate or convey Evidence. In critical system with appropriate protected capabilities that actually happens. I can see that it is not a common case and would not argue strongly against removing 'B' from that conveyance arc.
Perhaps a better example for which the loader environment is not ephemeral would be where B is the OS and C is an application/workload process.

Revised text:
Claims about a root of trust typically are asserted by Endorsers. The device illustrated in layered includes (A) a BIOS stored in read-  <ins> only memory, (B) an operating system kernel, and (C) an application or workload. </ins> Attesting Environment A, the read-only BIOS in this example, has to ensure the integrity of the bootloader (Target Environment B).  There