jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-ohai-ohttp

Commentary: We were n't always capitalizing " Encapsulated Request " . This does more , in direct opposition to the changes in . If we do n't take that ( it seems we at an impasse there ) , then we should at least be consistent . 
 I resolved conflicts , but please double check the intro paragraph that had  's proposed changes .
The identity of an that will accept relay requests carrying an
encapsulated request as its content and forward the content in
these requests to a single . See proxy-state for more information
about the mapping between .
The identity of an that will accept relay requests carrying an as
its content and forward the content in these requests to a single
. See proxy-state for more information about the mapping between .
Errors detected by the after successfully removing encapsulation and
errors detected by the MUST be sent in an .  This might be because
the request is malformed or the does not produce a response.  In
either case the can generate a response with an appropriate error
status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see
HTTP and HTTP, respectively).  This response is encapsulated in the
same way as a successful response.
Errors detected by the after successfully removing encapsulation and
errors detected by the MUST be sent in an .  This might be because
the is malformed or the does not produce a response.  In either case
the can generate a response with an appropriate error status code
(such as 400 (Bad Request) or 504 (Gateway Timeout); see HTTP and
HTTP, respectively).  This response is encapsulated in the same way
as a successful response.
Connections between the , Oblvious Relay Resource, and MUST use HTTPS
in order to provide unlinkability in the presence of a network
observer.  The scheme of the encapsulated request determines what is
used between the Oblivious Gateway and Target Resources, though using
HTTPS is RECOMMENDED; see server-responsibilities.
Connections between the , Oblvious Relay Resource, and MUST use HTTPS
in order to provide unlinkability in the presence of a network
observer.  The scheme of the determines what is used between the
Oblivious Gateway and Target Resources, though using HTTPS is
RECOMMENDED; see server-responsibilities.
Draft: draft-ietf-ohai-ohttp

Commentary: As observes in his review , " same entity " is more or less meaningless when it comes to ensuring that forwarding does n't happen in the clear . This narrows the recommendation to a concrete " same origin " , but notes that even that is not sufficient in all cases .
Nonsecure requests - such as those with the "http" scheme as opposed
to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway
and Target Resources are operated by different entities as that would
expose both requests and response to modification or inspection by a
network attacker.
Nonsecure requests - such as those with the "http" scheme as opposed
to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway
and Target Resources are not on the same origin.  If messages are
forwarded between these resources without the protections afforded by
HTTPS, they could be inspected or modified by a network attacker.
Note that two resources that share an origin do not guarantee that
requests are not forwarded without protection.
Draft: draft-ietf-ohai-ohttp

Commentary: This is based on the observation from that we 're presuming a specific processing order at the gateway , which is unnecessary .
An acts as a gateway for requests to the (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.
An acts as a gateway for requests to the (see HTTP).  The one
exception is that any information it might forward in a response MUST
be encapsulated, unless it is responding to errors that do not relate
to processing the contents of the encapsulated request; see errors.
Draft: draft-ietf-ohai-ohttp

Commentary: Based on feedback from and his TSV directorate review .
Parses "enc_request" into "key_id", "kem_id", "kdf_id", "aead_id",
"enc", and "ct" (indicated using the function "parse()" in
pseudocode).  The server is then able to find the HPKE private
key, "skR", corresponding to "key_id".
a.  If "key_id" does not identify a key matching the type of
"kem_id", the server returns an error.
b.  If "kdf_id" and "aead_id" identify a combination of KDF and
AEAD that the server is unwilling to use with "skR", the server
returns an error.
Parses "enc_request" into "key_id", "kem_id", "kdf_id", "aead_id",
"enc", and "ct" (indicated using the function "parse()" in
pseudocode).  The is then able to find the HPKE private key,
"skR", corresponding to "key_id".
a.  If "key_id" does not identify a key matching the type of
"kem_id", the returns an error.
b.  If "kdf_id" and "aead_id" identify a combination of KDF and
AEAD that the is unwilling to use with "skR", the returns an
error.
Decrypt "ct" by invoking the "Open()" method on "rctxt" (HPKE),
with an empty associated data "aad", yielding "request" or an
error on failure.  If decryption fails, the server returns an
error.
Decrypt "ct" by invoking the "Open()" method on "rctxt" (HPKE),
with an empty associated data "aad", yielding "request" or an
error on failure.  If decryption fails, the returns an error.
Draft: draft-ietf-ohai-ohttp

Commentary: Sean 's question makes this worth noting .
A or MUST NOT automatically attempt to retry a failed request unless
it receives a positive signal indicating that the request was not
processed or forwarded.  The HTTP/2 REFUSED_STREAM error code
(HTTP2), the HTTP/3 H3_REQUEST_REJECTED error code (HTTP3), or a
GOAWAY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred.
Connection failures or interruptions are not sufficient signals that
no processing occurred.
A or MUST NOT automatically attempt to retry a failed request unless
it receives a positive signal indicating that the request was not
processed or forwarded.  The HTTP/2 REFUSED_STREAM error code
(HTTP2), the HTTP/3 H3_REQUEST_REJECTED error code (HTTP3), or a
GOAWAY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred.
HTTP/1.1 HTTP11 provides no equivalent signal.  Connection failures
or interruptions are not sufficient signals that no processing
occurred.
Draft: draft-ietf-ohai-ohttp

Commentary: Suggestion to fix my ARTART review nits . 
 Thanks Sean , very helpful .
Use the same "Expand" function to extract a nonce "nonce" of
length "Nn" - the length of the nonce used by the AEAD.
Generating "aead_nonce" uses a label of "nonce".
Extract a pseudorandom key "prk" using the "Extract" function
provided by the KDF algorithm associated with "context".  The
"ikm" input to this function is "secret"; the "salt" input is the
concatenation of "enc" (from "enc_request") and "response_nonce".
Use the same "Expand" function to extract a nonce, "nonce", of
length "Nn" - the length of the nonce used by the AEAD.
Generating "aead_nonce" uses a label of "nonce".
The role in this protocol acts as an HTTP client both with respect to
the and the .  For the request the makes to the , this diverges from
typical HTTP assumptions about the use of a connection (see HTTP) in
that the request and response are encrypted rather than sent over a
connection.  The and the also act as HTTP clients toward the and
respectively.
The role in this protocol acts as an HTTP client both with respect to
the and the .  For the request, the makes to the , this diverges from
typical HTTP assumptions about the use of a connection (see HTTP) in
that the request and response are encrypted rather than sent over a
connection.  The and the also act as HTTP clients toward the and
respectively.
Firstly, a generic implementation will forward unknown fields.  For
Oblivious HTTP, a SHOULD NOT forward unknown fields.  Though are not
expected to include fields that might contain identifying
information, removing unknown fields removes this privacy risk.
Firstly, a generic implementation will forward unknown fields.  For
Oblivious HTTP, an SHOULD NOT forward unknown fields.  Though are not
expected to include fields that might contain identifying
information, removing unknown fields removes this privacy risk.
Finally, a relay can also generate responses, though it assumed to
not be able to examine the content of a request (other than to
observe the choice of key identifier, KDF, and AEAD), so it is also
assumed that it cannot generate an .
Finally, a relay can also generate responses, though it is assumed to
not be able to examine the content of a request (other than to
observe the choice of key identifier, KDF, and AEAD), so it is also
assumed that it cannot generate an .
Nonsecure requests - such those with the "http" scheme as opposed to
the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and
Target Resources are operated by different entities as that would
expose both requests and response to modification or inspection by a
network attacker.
Nonsecure requests - such as those with the "http" scheme as opposed
to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway
and Target Resources are operated by different entities as that would
expose both requests and response to modification or inspection by a
network attacker.
Draft: draft-ietf-ohai-ohttp

Commentary: From First and only time KeyConfig appear in the text . Section 6.7 : Missing " to " after " used " Section 6.7 : Remove the first " affected " Section 7 : Missing " to " before prevent , remove " of "
A only needs to retain keying material that might be used compromise
the confidentiality and integrity of a response until that response
is consumed, so there is negligible risk associated with a
compromise.
A only needs to retain keying material that might be used to
compromise the confidentiality and integrity of a response until that
response is consumed, so there is negligible risk associated with a
compromise.
The total number of affected messages affected by server key
compromise can be limited by regular rotation of server keys.
The total number of messages affected by server key compromise can be
limited by regular rotation of server keys.
One goal of this design is that independent requests are only
linkable by their content.  However, the choice of configuration
might be used to correlate requests.  A configuration includes the
URI, the Oblivious Gateway (KeyConfig), and URI.  A configuration is
active if can successfully use it for interacting with with a target.
One goal of this design is that independent requests are only
linkable by their content.  However, the choice of configuration
might be used to correlate requests.  A configuration includes the
URI, the Oblivious Gateway , and URI.  A configuration is active if
can successfully use it for interacting with with a target.
privacy depends on having each configuration used by many other .  It
is critical prevent the use of unique configurations, which might be
used to track of individual , but it is also important to avoid
creating small groupings of that might weaken privacy protections.
privacy depends on having each configuration used by many other .  It
is critical to prevent the use of unique configurations, which might
be used to track of individual , but it is also important to avoid
creating small groupings of that might weaken privacy protections.
Draft: draft-ietf-ohai-ohttp

Commentary: This really just needs a good explanation of what might happen . 
 From I understand the goal of the sentence above , but I am not sure the SHOULD is appropriate here - in particular if I think about the above as an interoperability requirement , I do n't think it gives enough information to the implementer of what is recommended here . If this was to give for example a default time window , it would be a different story . Can we rephrase ? ( You can also leave as is , but I think it will come up again in IESG review with no change )
SHOULD allow for the time it takes requests to arrive from the , with
a time window that is large enough to allow for differences in
clocks.
might need to allow for the time it takes requests to arrive from the
, with a time window that is large enough to allow for differences in
clocks.  Insufficient tolerance of time differences could result in
valid requests being unnecessarily rejected.
Draft: draft-ietf-ohai-ohttp

Commentary: Remove a " MUST " in this sentence and lean more heavily on the requirement later . 
 From It seems to me these two sentences contraddict each other : MUST only contain these fields , and MAY include additional fields . Do I read this wrong ? ( and same for the response later in the section )
A interacts with the by constructing an .  This is included as the
content of a POST request to the .  This request MUST only contain
those fields necessary to carry the : a method of POST, a target URI
of the , a header field containing the content type (see (iana-req),
and the as the request content.  In the request to the , MAY include
additional fields.  However, those fields MUST be independent of the
and MUST be fields that the will remove before forwarding the towards
the target, such as the Connection or Proxy-Authorization header
fields HTTP.
A interacts with the by constructing an .  This is included as the
content of a POST request to the .  This request only needs those
fields necessary to carry the : a method of POST, a target URI of the
, a header field containing the content type (see (iana-req), and the
as the request content.  In the request to the , MAY include
additional fields.  However, additional fields MUST be independent of
the and MUST be fields that the will remove before forwarding the
towards the target, such as the Connection or Proxy-Authorization
header fields HTTP.
Draft: draft-ietf-ohai-ohttp

Commentary: From Interesting that this is the first time OHTTP appear in the text , excluding pseudocode and mediatype - please expand ( or define somewhere else , for example in terminology ) .
The encrypted payload of an OHTTP request and response is a binary
HTTP message BINARY.  The and agree on this encrypted payload type by
specifying the media type "message/bhttp" in the HPKE info string and
HPKE export context string for request and response encryption,
respectively.
The encrypted payload of an Oblivious HTTP request and response is a
binary HTTP message BINARY.  The and agree on this encrypted payload
type by specifying the media type "message/bhttp" in the HPKE info
string and HPKE export context string for request and response
encryption, respectively.
Draft: draft-ietf-ohai-ohttp

Commentary: From Please add a reference to section 5.3 of [ HPKE ] ; it could be confusing at a first glance to have both the context from the exporter function in 5.3 of [ HPKE ] and the HPKE context here named " context " .
Export a secret "secret" from "context", using the string
"message/bhttp response" as context.  The length of this secret is
"max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and
nonce associated with "context".  Note: repurposing discusses how
alternative message formats might use a different "context" value.
Export a secret, "secret", from "context", using the string
"message/bhttp response" as the "exporter_context" parameter to
"context.Export"; see HPKE.  The length of this secret is "max(Nn,
Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce
associated with "context".  Note: repurposing discusses how
alternative message formats might use a different "context" value.
Draft: draft-ietf-ohai-ohttp

Commentary: Might as well say that . 
 From Section 5.3 : Should there be any indication that such errors in processing should be considered as bad requests ( and hence return an appropriate error status code ) or is this obvious ?
Errors in the encapsulation of requests mean that responses cannot be
encapsulated.  This includes cases where the is incorrect or
outdated.  The can generate and send a response with an error status
to the .  This response MAY be forwarded to the or treated by the as
a failure.  If a receives a response that is not an , this could
indicate that the client configuration used to construct the request
is incorrect or out of date.
Errors in the encapsulation of requests mean that responses cannot be
encapsulated.  This includes cases where the is incorrect or
outdated.  The can generate and send a response with a 4xx status
code to the .  This response MAY be forwarded to the or treated by
the as a failure.  If a receives a response that is not an , this
could indicate that the client configuration used to construct the
request is incorrect or out of date.
Draft: draft-ietf-ohai-ohttp

Commentary: From 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 .
The Nenc parameter corresponding to the KEM used in HPKE can be found
in HPKE.  Nenc refers to the size of the encapsulated KEM shared
secret, in bytes.
The Nenc parameter corresponding to the KEM used in HPKE can be found
in HPKE or the HPKE KEM IANA registry [1].  Nenc refers to the size
of the encapsulated KEM shared secret, in bytes.
The Nn and Nk values correspond to parameters of the AEAD used in
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).
The Nn and Nk values correspond to parameters of the AEAD used in
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).
Please update the "Media Types" registry at
https://iana.org/assignments/media-types [1] for the media types
"application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req),
and "message/ohttp-res" (iana-res).
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).
Please update the "Media Types" registry at
https://iana.org/assignments/media-types [3] for the media types
"application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req),
and "message/ohttp-res" (iana-res).
Please update the "HTTP Problem Types" registry at
https://iana.org/assignments/http-problem-types [4] for the types
"date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key).
Draft: draft-ietf-ohai-ohttp

Commentary: Duplicate reference : RFC6265 , mentioned in ' RFC6265 ' , was also mentioned in ' COOKIES ' . Duplicate reference : RFC9110 , mentioned in ' SEMANTICS ' , was also mentioned in ' HTTP ' .
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit
from being able to carry state between requests, such as with cookies
(RFC6265), authentication (HTTP), or even alternative services
(RFC7838).  Oblivious HTTP removes linkage at the transport layer,
which is only useful for an application that does not carry state
between requests.
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit
from being able to carry state between requests, such as with cookies
(COOKIES), authentication (HTTP), or even alternative services
(RFC7838).  Oblivious HTTP removes linkage at the transport layer,
which is only useful for an application that does not carry state
between requests.
A interacts with the by constructing an .  This is included as the
content of a POST request to the .  This request MUST only contain
those fields necessary to carry the : a method of POST, a target URI
of the , a header field containing the content type (see (iana-req),
and the as the request content.  In the request to the , MAY include
additional fields.  However, those fields MUST be independent of the
and MUST be fields that the will remove before forwarding the towards
the target, such as the Connection or Proxy-Authorization header
fields SEMANTICS.
A interacts with the by constructing an .  This is included as the
content of a POST request to the .  This request MUST only contain
those fields necessary to carry the : a method of POST, a target URI
of the , a header field containing the content type (see (iana-req),
and the as the request content.  In the request to the , MAY include
additional fields.  However, those fields MUST be independent of the
and MUST be fields that the will remove before forwarding the towards
the target, such as the Connection or Proxy-Authorization header
fields HTTP.
Draft: draft-ietf-ohai-ohttp

Commentary: Forwarding an empty request will always yield a failure on the gateway , so just do n't do it . 
 A request without a body is basically malformed , and the gateway will treat it that way . I think relays should be encouraged to reject malformed requests ( invalid method , content type , or content body ) so this burden does n't fall on the gateway . 
 This seems a little bit strange to single out . Do we really need to mandate this ? If the relay forwards the request anyway , the gateway will be unable to decrypt it . This creates a shorter and more immediate feedback loop , but it sort of leads to the next question : how much validation do we rely on the relay to do ? What if the content - type is not acceptable ? Enforcing that choice might be sensible , but it can also lead to ossification , where the relay 's view of what is acceptable prevents new options from being deployed . I would have said that it would be better to say something like " A [ relay ] MAY reject requests that are obviously invalid , such as a request with no content . " Obviously , the relay is going to do some amount of denial of service protection on behalf of the gateway , and blocking empty content is a fairly trivial thing to do there , but so is 1 byte of content or a content - type of . We probably do n't need to enumerate all the ways and nor do we need to be so strict about what to do . 
 Your proposed text works for me . 
 OK , I 'll work out how to make that change . I want to submit an update today . 
 already applied the suggestion ! 
 Yeah , this is much better . 
 Perfect , thanks!Seems fine . What was the motivation here ?
The interacts with the as an HTTP client by constructing a request
using the same restrictions as the request, except that the target
URI is the .  The content of this request is copied from the .  The
MUST NOT add information to the request without the being aware of
the type of information that might be added; see relay-
responsibilities for more information on relay responsibilities.
The interacts with the as an HTTP client by constructing a request
using the same restrictions as the request, except that the target
URI is the .  The content of this request is copied from the .  An
MAY reject requests that are obviously invalid, such as a request
with no content.  The MUST NOT add information to the request without
the being aware of the type of information that might be added; see
relay-responsibilities for more information on relay
responsibilities.