jiebi/TextFlow huggingface dataset:
Original text:
2.1.1. To request a single access token, the client instance sends an <del> "acccess_token" object composed of the following fields. </del>  The values of the "flags" field defined by this specification are as follows: 13.22. During the interaction process, the client instance usually hands <del> control of the user experience over to another component, beit the </del>  system browser, another application, or some action the resource owner is instructed to take on another device.  By using an interaction finish method, the client instance can be securely a number of protocol elements that it needs to manage, including nonces, references, keys, access tokens, and other elements.  During the interaction process, the client instance usually hands control of <del> the user experience over to another component, beit the system </del>  browser, another application, or some action the resource owner is instructed to take on another device.  In order for the client instance to make its continuation call, it will need to recall all of

Reviewer comments:
type, - beit -> be it,
To edit notification comments on pull requests, go to your .
"beit" isn't a word, it should be "be it".
As I was reading through the latest version of the draft, I spotted a typo within section 2.1.1. It should says accesstoken object, not acccess_token object.

Revised text:
2.1.1. To request a single access token, the client instance sends an  <ins> "access_token" object composed of the following fields. </ins> The values of the "flags" field defined by this specification are as follows: 13.22. During the interaction process, the client instance usually hands  <ins> control of the user experience over to another component, be it the </ins> system browser, another application, or some action the resource owner is instructed to take on another device.  By using an interaction finish method, the client instance can be securely a number of protocol elements that it needs to manage, including nonces, references, keys, access tokens, and other elements.  During the interaction process, the client instance usually hands control of  <ins> the user experience over to another component, be it the system </ins> browser, another application, or some action the resource owner is instructed to take on another device.  In order for the client instance to make its continuation call, it will need to recall all of
Original text:
each time a new TLS connection is established, both the client and the server (or the server only when using mtls) have to validate the other party's identity.  Such a verification can be achieved via <del> methods described in I-D.ietf-uta-6125bis), but these are not enough to establish the identity of the client instance in many cases. </del>  To counter this, GNAP defines a set of key binding methods in binding-keys that allow authentication and proof of possession by the

Reviewer comments:
Built To edit notification comments on pull requests, go to your .
[I-D.ietf-uta-6125bis] " BROKEN REFERENCE ".

Revised text:
each time a new TLS connection is established, both the client and the server (or the server only when using mtls) have to validate the other party's identity.  Such a verification can be achieved via  <ins> methods described in I-D.ietf-uta-rfc6125bis, but these are not enough to establish the identity of the client instance in many cases. </ins> To counter this, GNAP defines a set of key binding methods in binding-keys that allow authentication and proof of possession by the
Original text:
Grant Negotiation and Authorization Protocol Resource Server Connections <del> draft-ietf-gnap-resource-servers-latest </del>  Abstract BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  2. When the AS issues an access token for use at an RS, the RS needs to A GNAP AS offering RS-facing services can publish its features on a well-known discovery document using the URL ".well-known/gnap-as-rs". <del> This endpoint contains a JSON document consisting of a single JSON object with any combination of the following optional fields: </del>  The URL of the endpoint offering introspection.

Reviewer comments:
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit 24fa4dc27f079697512f5eb15ca85b15f1c7ec62 https://deploy-preview-1--gnap-resource-servers-editors-URL

Revised text:
Grant Negotiation and Authorization Protocol Resource Server Connections  <ins> draft-ietf-gnap-resource-servers-00 </ins> Abstract BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and other elements.  Some examples use a single trailing backslash '' to indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value. </ins> 2. When the AS issues an access token for use at an RS, the RS needs to A GNAP AS offering RS-facing services can publish its features on a well-known discovery document using the URL ".well-known/gnap-as-rs".  <ins> This endpoint contains a JSON document RFC8259 consisting of a single JSON object with any combination of the following optional fields: </ins> The URL of the endpoint offering introspection.
Original text:
However, it is often desirable to have the RS and AS communicate at runtime for a variety of purposes, including allowing the RS to validate and understand the rights and privileges associated with a <del> grant of access represented by an access token issued by (AS), or </del>  negotiating the capabilities of either party.  These types of connections are particularly useful for connecting an AS and RS from different vendors, allowing interoperable distributed deployments of the request with its own key (not the client instance's key or the token's key). <del> The AS validates the access token value and the client instance's </del>  request and returns the introspection response for the token. The RS fulfills the request from the client instance. at the secondary RS.  This internal secondary token is issued in the context of the incoming access token. <del> While it is possible to use a [token format]{#structure} that allows for the RS to generate its own secondary token, the AS can allow the RS to request this secondary access token using the same process used by the original client instance to request the primary access token. Since the RS is acting as its own client instance from the perspective of GNAP, this process uses the same grant endpoint, request structure, and response structure as a client instance's request. </del>  The client instance calls RS1 with an access token.

Reviewer comments:
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit 122ea374f78cfa417b0d1d80101e64990c448665 https://deploy-preview-11--gnap-resource-servers-editors-URL

Revised text:
However, it is often desirable to have the RS and AS communicate at runtime for a variety of purposes, including allowing the RS to validate and understand the rights and privileges associated with a  <ins> grant of access represented by an access token issued by the AS, or </ins> negotiating the capabilities of either party.  These types of connections are particularly useful for connecting an AS and RS from different vendors, allowing interoperable distributed deployments of the request with its own key (not the client instance's key or the token's key).  <ins> The AS validates the access token value and the Resource Server's </ins> request and returns the introspection response for the token. The RS fulfills the request from the client instance. at the secondary RS.  This internal secondary token is issued in the context of the incoming access token.  <ins> While it is possible to use a structure that allows for the RS to generate its own secondary token, the AS can allow the RS to request this secondary access token using the same process used by the original client instance to request the primary access token.  Since the RS is acting as its own client instance from the perspective of GNAP, this process uses the same grant endpoint, request structure, and response structure as a client instance's request. </ins> The client instance calls RS1 with an access token.
Original text:
character and leading spaces on wrapped lines are not part of the value.  2. When the AS issues an access token for use at an RS, the RS needs to

Reviewer comments:
closing
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! Built :hammer: Explore the source changes: 35665c3208b87850c24d51a1083919c030a1978d :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Added the list of terms
Include a reference to the Terminology section of the Core doc.
I think we should list out the terminology in question here as well as the general reference.

Revised text:
character and leading spaces on wrapped lines are not part of the value. <ins> Terminology specific to GNAP is defined in the terminology section of the core specification I-D.ietf-gnap-core-protocol, and provides definitions for the protocol roles: Authorization Server (AS), Client, Resource Server (RS), Resource Owner (RO), End-user; as well as the protocol elements: Attribute, Access Token, Grant, Privilege, Protected Resource, Right, Subject, Subject Information.  The same definitions are used in this document. </ins> 2. When the AS issues an access token for use at an RS, the RS needs to
Original text:
3.2. <del> Unless otherwise specified, the RS protects its calls to the AS using any of the signature methods defined by GNAP.  This signing method MUST cover all of the appropriate portions of the HTTP request </del>  message, including any body elements, tokens, or headers required for functionality. <del> The AS MAY require an RS to pre-register its keys or could alternatively allow calls from arbitrary keys, in a trust-on-first- use model.  The RS MAY present its keys by reference or by value in the same fashion as a client instance calling the AS in the core protocol of GNAP I-D.ietf-gnap-core-protocol. </del>  3.3. Since the RS is acting as a client instance, the RS MUST identify itself with its own key in the "client" field and sign the request <del> just as any client instance would. [[ See issue #116 [2] ]] </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 8.1.  URIs [1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115 <del> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </del>

Reviewer comments:
Expands discussion of RS authentication, with examples. Re-uses structures from client instance auth used in core. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 71b0e6f2bdaa5a34903865e3130160be29eefc4b :mag: Inspect the deploy log: :sunglasses: Browse the preview:

Revised text:
3.2.  <ins> Unless otherwise specified, the RS MUST protect its calls to the AS using any of the signature methods defined by GNAP.  This signing method MUST cover all of the appropriate portions of the HTTP request </ins> message, including any body elements, tokens, or headers required for functionality.  <ins> The RS MAY present its keys by reference or by value in a similar fashion to a client instance calling the AS in the core protocol of GNAP, described in I-D.ietf-gnap-core-protocol.  In the protocols defined here, this takes the form of the resource server identifying itself using a "key" field or by passing an instance identifier directly. or by reference: The AS MAY require an RS to pre-register its keys or could allow calls from arbitrary keys in a trust-on-first-use model. </ins> 3.3. Since the RS is acting as a client instance, the RS MUST identify itself with its own key in the "client" field and sign the request  <ins> just as any client instance would, as described in authentication. </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 8.1.  URIs [1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115
Original text:
different vendors, allowing interoperable distributed deployments of GNAP-protected systems. <del> This specification defines several means for a RS and AS to </del>  communicate these aspects with each other, including structured access tokens and RS-facing APIs.  This specification also discusses methods for an RS to derive a downstream token for calling another When the AS issues an access token for use at an RS, the RS needs to have some means of understanding what the access token is for in order to determine how to respond to the request.  The core GNAP <del> protocol makes no assumptions or demands on the format or contents of the access token, and in fact the token format and contents are opaque to the client instance.  However, such token formats can be the topic of agreements between the AS and RS. </del>  Self-contained structured token formats allow for the conveyance of information between the AS and RS without requiring the RS to call

Reviewer comments:
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! Built :hammer: Explore the source changes: ee6b3fc9832467191449ff86c6651ebf548d33ea :mag: Inspect the deploy log: :sunglasses: Browse the preview:
A couple of other minor things it sounds to me like an optional step for the RS to validate the signature if the key object is presented in the introspection response. That should be MUST, right? The third step in section "Token Introspection" states that I think that the AS should validate the RS's request and only after that the AT's value.
The RS always has to validate the signature, but sometimes it can't fully validate it until after it looks up the token's data using introspection. We should look at what OAuth MTLS and DPoP say in terms of RS validation steps. The intent of the language for the AS validation was not to imply an order in either direction, so we can look to tweak this to make that more clear.

Revised text:
different vendors, allowing interoperable distributed deployments of GNAP-protected systems.  <ins> This specification defines several means for an RS and AS to </ins> communicate these aspects with each other, including structured access tokens and RS-facing APIs.  This specification also discusses methods for an RS to derive a downstream token for calling another When the AS issues an access token for use at an RS, the RS needs to have some means of understanding what the access token is for in order to determine how to respond to the request.  The core GNAP  <ins> protocol makes neither assumptions nor demands on the format or contents of the access token, and in fact, the token format and contents are opaque to the client instance.  However, such token formats can be the topic of agreements between the AS and RS. </ins> Self-contained structured token formats allow for the conveyance of information between the AS and RS without requiring the RS to call
Original text:
<del> An HTTPS-based Transport for Configured Subscriptions </del>  draft-ietf-netconf-https-notif-latest Abstract

Reviewer comments:
Updates based on reviewing comments from Martin and Jan.
I was expecting more changes. What about the Title?
good enough but, FYI, there's no need to set the "abbrev" attribute if it's the same value as the title...
Looks like the "abbrev" text is too long. How about "HTTPS YANG Notifications"?
Or maybe "HTTPS Notif Transport" ??? Either way is fine by me.

Revised text:
 <ins> An HTTPS-based Transport for YANG Notifications </ins> draft-ietf-netconf-https-notif-latest Abstract
Original text:
2.1. <del> The "Idempotency-Key" request header field describes </del>  Clients MUST NOT include more than one "Idempotency-Key" header field in the same request.

Reviewer comments:
NAME pls review
While not a mandatory requirement for new fields, using SF has a number of benefits: Well-defined parsing and serialisation algorithms Corresponding reduction of interop and security issues Existing implementation support Possibility of more efficient serialisation support (i.e., binary HTTP headers) URL
Closing this, PR is merged after NAME comment is addressed.

Revised text:
2.1.  <ins> "Idempotency-Key" is an Item Structured Header RFC8941.  Its value MUST be a String.  Refer to Section 3.3.3 of RFC8941 for ABNF of "sf- string": </ins> Clients MUST NOT include more than one "Idempotency-Key" header field in the same request.
Original text:
The Idempotency-Key HTTP Header Field <del> draft-ietf-httpapi-idempotency-key-header-01 </del>  Abstract The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here, and without quotes. </del>  This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 and includes, by reference, the IMF-fixdate rule idempotency related requirements as published by the server and use appropriate algorithm to generate idempotency keys. <del> For each request, client SHOULD </del>  Send a unique idempotency key in the HTTP "Idempotency-Key" request header field. Server is responsible for managing the lifecycle of the idempotency key. <del> For each request, server SHOULD </del>  Identify idempotency key from the HTTP "Idempotency-Key" request header field. 3.1. <del> The "Idempotency-Key" request header should be added to the permanent registry of message header fields (see RFC3864), taking into account the guidelines given by HTTP/1.1 RFC7231. </del>  4.

Reviewer comments:
This: Gets the editors' draft generated by the template using GitHub actions (was never set up) Fixes up some document metadata Updates the IANA considerations section to fit current practice
looks like this one didn't work as expected, NAME URL
Fixed.

Revised text:
The Idempotency-Key HTTP Header Field  <ins> draft-ietf-httpapi-idempotency-key-header-latest </ins> Abstract The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 and includes, by reference, the IMF-fixdate rule idempotency related requirements as published by the server and use appropriate algorithm to generate idempotency keys.  <ins> For each request, client </ins> Send a unique idempotency key in the HTTP "Idempotency-Key" request header field. Server is responsible for managing the lifecycle of the idempotency key.  <ins> For each request, server </ins> Identify idempotency key from the HTTP "Idempotency-Key" request header field. 3.1.  <ins> The Idempotency-Key field name should be added to the "Hypertext Transfer Protocol (HTTP) Field Name Registry". </ins> 4.
Original text:
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>  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>  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>  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>  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

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

Revised text:
2.7. If the "Idempotency-Key" request header is missing for a documented  <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  <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  <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  <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
Original text:
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>  is required) before performing a retry operation, or the the resource server MUST fail the request and return one of the above errors.

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

Revised text:
Error scenarios above describe the status of failed idempotent requests after the resource server prcocesses them.  Clients MUST  <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.