jiebi/TextFlow huggingface dataset:
Original text:
information that does not reveal information about the encapsulated response. <del> An Oblivious Gateway Resource acts as a gateway for requests to the Target Resource (see HTTP).  The one exception is that any information it might forward in a response MUST be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </del> In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities.

Reviewer comments:
Section 5 details HTTP usage. It seems it's technically correct but the section closes with a sequence of paragraphs that jump back and forth between statements about how an Oblivious Gateway Resource treats requests or responses. Perhaps these could be consolidated to present requests first consistently. I.e. swap the final two paragraphs around

Revised text:
information that does not reveal information about the encapsulated response.  In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities.
Original text:
indicate that the client configuration used to construct the request is incorrect or out of date.  6. In this design, a wishes to make a request of a server that is

Reviewer comments:
We debated this at some length. This defines an optional-to-use signaling method for the gateway so that it can inform the client when the key configuration is not acceptable. Clients can use this as a prompt to refresh their configuration.
(Originally posted by NAME in URL): Any lifetime information that comes with a key is helpful, but in practice is insufficient for clients to drive key updates. Key rotation may not occur on a fixed schedule and it may not occur synchronously (some gateway instances might not get the key at the right time. This means that clients cannot distinguish between failures due to configuration mismatch or request tampering (or whatever else might cause the gateway to reply without an encapsulated response). If the client can't distinguish then the client's recovery implementation is a lot more complicated. Does it always try to forcibly update its configuration? Does it implement some sort of backoff? Can a relay abuse the client's recovery implementation to somehow put the client into a state where it is stuck with an old configuration? It seems vastly simpler to just be clear that the configuration is wrong as a signal to the client that it's time to update. This was done in ODoH with a 401 response code. proposed a new problem statement, which I think is the right way to deal with this. Yes, there are potential privacy problems based on automated updates, but those depend on the client's consistency story and is therefore not something new a signal would introduce.
This looks great -- thanks!

Revised text:
indicate that the client configuration used to construct the request is incorrect or out of date. <ins> 5.3. The problem type PROBLEM of "https://iana.org/assignments/http- problem-types#ohttp-key" is defined.  An MAY use this problem type in a response to indicate that an used an outdated or incorrect . fig-key-problem shows an example response in HTTP/1.1 format. As this response cannot be encrypted, it might not reach the .  A cannot rely on the using this problem type.  A might also be configured to disregard responses that are not encapsulated on the basis that they might be subject to observation or modification by an .  A might manage the risk of an outdated using a heuristic approach whereby it periodically refreshes its if it receives a response with an error status code that has not been encapsulated. </ins> 6. In this design, a wishes to make a request of a server that is
Original text:
9. Please update the "Media Types" registry at <del> https://www.iana.org/assignments/media-types [1] for the media types </del>  "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res).  9.1. The "application/ohttp-keys" media type identifies a used by

Reviewer comments:
We debated this at some length. This defines an optional-to-use signaling method for the gateway so that it can inform the client when the key configuration is not acceptable. Clients can use this as a prompt to refresh their configuration.
(Originally posted by NAME in URL): Any lifetime information that comes with a key is helpful, but in practice is insufficient for clients to drive key updates. Key rotation may not occur on a fixed schedule and it may not occur synchronously (some gateway instances might not get the key at the right time. This means that clients cannot distinguish between failures due to configuration mismatch or request tampering (or whatever else might cause the gateway to reply without an encapsulated response). If the client can't distinguish then the client's recovery implementation is a lot more complicated. Does it always try to forcibly update its configuration? Does it implement some sort of backoff? Can a relay abuse the client's recovery implementation to somehow put the client into a state where it is stuck with an old configuration? It seems vastly simpler to just be clear that the configuration is wrong as a signal to the client that it's time to update. This was done in ODoH with a 401 response code. proposed a new problem statement, which I think is the right way to deal with this. Yes, there are potential privacy problems based on automated updates, but those depend on the client's consistency story and is therefore not something new a signal would introduce.
This looks great -- thanks!

Revised text:
9. Please update the "Media Types" registry at  <ins> https://iana.org/assignments/media-types [1] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). <ins> Please update the "HTTP Problem Types" registry at https://iana.org/assignments/http-problem-types [2] for the types "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). </ins> 9.1. The "application/ohttp-keys" media type identifies a used by
Original text:
IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM.  10.  References 10.1.  URIs <del> [1] https://www.iana.org/assignments/media-types </del>  Index

Reviewer comments:
We debated this at some length. This defines an optional-to-use signaling method for the gateway so that it can inform the client when the key configuration is not acceptable. Clients can use this as a prompt to refresh their configuration.
(Originally posted by NAME in URL): Any lifetime information that comes with a key is helpful, but in practice is insufficient for clients to drive key updates. Key rotation may not occur on a fixed schedule and it may not occur synchronously (some gateway instances might not get the key at the right time. This means that clients cannot distinguish between failures due to configuration mismatch or request tampering (or whatever else might cause the gateway to reply without an encapsulated response). If the client can't distinguish then the client's recovery implementation is a lot more complicated. Does it always try to forcibly update its configuration? Does it implement some sort of backoff? Can a relay abuse the client's recovery implementation to somehow put the client into a state where it is stuck with an old configuration? It seems vastly simpler to just be clear that the configuration is wrong as a signal to the client that it's time to update. This was done in ODoH with a 401 response code. proposed a new problem statement, which I think is the right way to deal with this. Yes, there are potential privacy problems based on automated updates, but those depend on the client's consistency story and is therefore not something new a signal would introduce.
This looks great -- thanks!

Revised text:
IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. <ins> 9.5. IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. </ins> 10.  References 10.1.  URIs  <ins> [1] https://iana.org/assignments/media-types [2] https://iana.org/assignments/http-problem-types </ins> Index
Original text:
constructing and processing an . The Nenc parameter corresponding to the KEM used in HPKE can be found <del> in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </del>  4.2.

Reviewer comments:
From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.

Revised text:
constructing and processing an . The Nenc parameter corresponding to the KEM used in HPKE can be found  <ins> in HPKE or the HPKE KEM IANA registry [1].  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </ins> 4.2.
Original text:
constructing and processing an . The Nn and Nk values correspond to parameters of the AEAD used in <del> HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </del>  4.3.

Reviewer comments:
From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.

Revised text:
constructing and processing an . The Nn and Nk values correspond to parameters of the AEAD used in  <ins> HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [2]. Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </ins> 4.3.
Original text:
9. Please update the "Media Types" registry at <del> https://iana.org/assignments/media-types [1] for the media types </del>  "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). Please update the "HTTP Problem Types" registry at <del> https://iana.org/assignments/http-problem-types [2] for the types </del>  "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). 9.1.

Reviewer comments:
From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.

Revised text:
9. Please update the "Media Types" registry at  <ins> https://iana.org/assignments/media-types [3] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). Please update the "HTTP Problem Types" registry at  <ins> https://iana.org/assignments/http-problem-types [4] for the types </ins> "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). 9.1.
Original text:
10.1.  URIs <del> [1] https://iana.org/assignments/media-types </del>  <del> [2] https://iana.org/assignments/http-problem-types </del>  Index

Reviewer comments:
From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.

Revised text:
10.1.  URIs  <ins> [1] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids </ins>  <ins> [2] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids [3] https://iana.org/assignments/media-types [4] https://iana.org/assignments/http-problem-types </ins> Index
Original text:
identified by "aead_id". The then constructs an , "enc_request", from a binary encoded HTTP <del> request, "request", as follows: </del>  Construct a message header, "hdr", by concatenating the values of "key_id", "kem_id", "kdf_id", and "aead_id", as one 8-bit integer

Reviewer comments:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Revised text:
identified by "aead_id". The then constructs an , "enc_request", from a binary encoded HTTP  <ins> request BINARY, "request", as follows: </ins> Construct a message header, "hdr", by concatenating the values of "key_id", "kem_id", "kdf_id", and "aead_id", as one 8-bit integer
Original text:
bhttp request", a zero byte, "key_id" as an 8-bit integer, plus "kem_id", "kdf_id", and "aead_id" as three 16-bit integers. <del> Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info".  This produces a context "rctxt". </del>  Decrypt "ct" by invoking the "Open()" method on "rctxt" (HPKE), with an empty associated data "aad", yielding "request" or an

Reviewer comments:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Revised text:
bhttp request", a zero byte, "key_id" as an 8-bit integer, plus "kem_id", "kdf_id", and "aead_id" as three 16-bit integers.  <ins> Create a receiving HPKE context, "rctxt", by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info". </ins> Decrypt "ct" by invoking the "Open()" method on "rctxt" (HPKE), with an empty associated data "aad", yielding "request" or an
Original text:
In pseudocode, this procedure is as follows:  4.4. <del> Given an HPKE context, "context"; a request message, "request"; and a response, "response", generate an , "enc_response", as follows: </del>  Export a secret, "secret", from "context", using the string "message/bhttp response" as the "exporter_context" parameter to

Reviewer comments:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Revised text:
In pseudocode, this procedure is as follows: <ins> The retains the HPKE context, "rctxt", so that it can encapsulate a response. </ins> 4.4.  <ins> generate an , "enc_response", from a binary encoded HTTP response BINARY, "response".  The uses the HPKE receiver context, "rctxt", as the HPKE context, "context", as follows: </ins> Export a secret, "secret", from "context", using the string "message/bhttp response" as the "exporter_context" parameter to
Original text:
In pseudocode, this procedure is as follows: <del> decrypt an by reversing this process.  That is, they first parse </del>  "enc_response" into "response_nonce" and "ct".  They then follow the <del> same process to derive values for "aead_key" and "aead_nonce". </del>  The uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows:

Reviewer comments:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Revised text:
In pseudocode, this procedure is as follows:  <ins> decrypt an by reversing this process.  That is, first parse </ins> "enc_response" into "response_nonce" and "ct".  They then follow the  <ins> same process to derive values for "aead_key" and "aead_nonce", using their sending HPKE context, "sctxt", as the HPKE context, "context". </ins> The uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows:
Original text:
respectively. In order to achieve the privacy and security goals of the protocol a <del> also needs to observe the guidance in client-responsibilities. </del>  The interacts with the as an HTTP client by constructing a request using the same restrictions as the request, except that the target

Reviewer comments:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Revised text:
respectively. In order to achieve the privacy and security goals of the protocol a  <ins> also needs to observe the guidance in sec-client. </ins> The interacts with the as an HTTP client by constructing a request using the same restrictions as the request, except that the target
Original text:
requests over time.  However, this increases the risk that their request is rejected as outside the acceptable window.  7. One goal of this design is that independent requests are only

Reviewer comments:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Revised text:
requests over time.  However, this increases the risk that their request is rejected as outside the acceptable window. <ins> 6.9. The media type defined in ohttp-keys represents keying material.  The content of this media type is not active (see RFC6838), but it governs how a might interact with an .  The security implications of processing it are described in sec-client; privacy implications are described in privacy. The security implications of handling the message media types defined in req-res-media is covered in other parts of this section in more detail.  However, these message media types are also encrypted encapsulations of HTTP requests and responses. HTTP messages contain content, which can use any media type.  In particular, requests are processed by an Oblivious , which - as an HTTP resource - defines how content is processed; see HTTP.  HTTP clients can also use resource identity and response content to determine how content is processed.  Consequently, the security considerations of HTTP also apply to the handling of the content of these media types. </ins> 7. One goal of this design is that independent requests are only
Original text:
Please update the "Media Types" registry at https://iana.org/assignments/media-types [2] for the media types "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), <del> and "message/ohttp-res" (iana-res). </del>  Please update the "HTTP Problem Types" registry at https://iana.org/assignments/http-problem-types [3] for the types

Reviewer comments:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Revised text:
Please update the "Media Types" registry at https://iana.org/assignments/media-types [2] for the media types "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req),  <ins> and "message/ohttp-res" (iana-res), following the procedures of RFC6838. </ins> Please update the "HTTP Problem Types" registry at https://iana.org/assignments/http-problem-types [3] for the types
Original text:
Including a "Date" header field in the response allows the to correct clock errors by retrying the same request using the value of the "Date" field provided by the .  The value of the "Date" field can be <del> copied if the request is fresh, with an adjustment based on the "Age" field otherwise.  When retrying a request, the MUST create a fresh encryption of the modified request, using a new HPKE context. </del>  Intermediaries can sometimes rewrite the "Date" field when forwarding responses.  This might cause problems if the and intermediary clocks

Reviewer comments:
Corrected to mention response freshness, with a new citation Added note about timing of a retry revealing RTT Corrected figure title grammar
Nice addition on RTT timing

Revised text:
Including a "Date" header field in the response allows the to correct clock errors by retrying the same request using the value of the "Date" field provided by the .  The value of the "Date" field can be  <ins> copied if the response is fresh, with an adjustment based on the "Age" field otherwise; see HTTP-CACHING.  When retrying a request, the MUST create a fresh encryption of the modified request, using a new HPKE context. Retrying immediately allows the to measure the round trip time to the . The observed delay might reveal something about the location of the .  could delay retries to add some uncertainty to any observed delay. </ins> Intermediaries can sometimes rewrite the "Date" field when forwarding responses.  This might cause problems if the and intermediary clocks
Original text:
the public key from the configuration, "pkR", and <del> a selected combination of KDF, identified by "kdf_id", and AEAD, identified by "aead_id". </del>  The then constructs an , "enc_request", from a binary encoded HTTP request BINARY, "request", as follows:

Reviewer comments:
Following up from URL It seems like the key configuration lists a set of potential HPKE algorithms that the client can use. The section URL does say "a selected combination of KDF, identified by kdfid, and AEAD, identified by aeadid", but it's easy to miss the selected word and even then its not apparent as to what the selection is from. I think it could be made clearer that the client can choose from a list of HPKE algorithms specified in the Key Configuration.

Revised text:
the public key from the configuration, "pkR", and  <ins> a combination of KDF, identified by "kdf_id", and AEAD, identified by "aead_id", that the selects from those in the . </ins> The then constructs an , "enc_request", from a binary encoded HTTP request BINARY, "request", as follows:
Original text:
The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF, and AEAD respectively.  The definitions for these identifiers and the <del> semantics of the algorithms they identify can be found in HPKE. </del>  4.2.

Reviewer comments:
and . Given (either assuming a fixed key ID, or looking up the KEM based on key ID), I think this is a nice simplification. It also authenticates more, even if redundant. (The kemID is already part of the HPKE key schedule.) I implemented this change and it's straightforward.
Currently, an encapsulated request carries a key ID which maps to a KEM key that determines the size of the encapsulated public key in a request. This means that code parsing a request needs to know the ID -> KEM mapping in order to parse things correctly, which is somewhat annoying. I propose we add KEMID to the request so that this mapping isn't needed to just parse the message. As a bonus, that would also fold in the KEMID explicitly into the AAD alongside the KDFID and AEADID.
We currently length-prefix it, but we don't have to. Think about this a little.
Both the public key and encapsulated secret are fixed length. I think making these fixed length on the wire is good. However, it does require the parsing code to know the corresponding size, which depends on the KEM. This requires there to be a function to map the kem_id to the corresponding size(s). NAME do you have such an API in your implementation? I have one in mine, which would make this pretty straightforward to implement.

Revised text:
The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF, and AEAD respectively.  The definitions for these identifiers and the  <ins> semantics of the algorithms they identify can be found in HPKE.  The Npk parameter corresponding to the HpkeKdfId can be found in HPKE. </ins> 4.2.