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

Commentary: a partial one . From IETF 114 : I do n't know if it is worth enumerating all of the combinations is viable , but we might consider talking about the exact shape of the consistency requirements here .
One goal of this design is that independent client requests are only
linkable by the chosen key configuration.  The Oblivious Relay and
Gateway resources can link requests using the same key configuration
by matching KeyConfig.key_id, or, if the Target Resource is willing
to use trial decryption, a limited set of key configurations that
share an identifier.  An Oblivious Relay Resource can link requests
using the public key corresponding to KeyConfig.key_id.
Request resources are capable of linking requests depending on how
KeyConfigs are produced by servers and discovered by clients.
Specifically, servers can maliciously construct key configurations to
track individual clients.  A specific method for a client to acquire
key configurations is not included in this specification.  Clients
need to consider these tracking vectors when choosing a discovery
method.  Applications using this design should provide accommodations
to mitigate tracking using key configurations.  CONSISTENCY provides
an analysis of the options for ensuring the key configurations are
consistent between different clients.
One goal of this design is that independent client requests are only
linkable by the chosen key configuration.  The Oblivious Relay and
Gateway resources can link requests using the same key configuration
by matching KeyConfig.key_id, or, if the Target Resource is willing
to use trial decryption, a limited set of key configurations that
share an identifier.  An Oblivious Relay Resource can link requests
using the public key corresponding to KeyConfig.key_id or via the URI
of the Oblivious Gateway Resource.  We refer to this set of
information as the gateway's configuration.
Whether or not targets can link requests depends on how gateway
configuration information is produced and discovered by clients.
Specifically, gateways can maliciously construct configurations to
track individual clients.
Ideally, all clients share a consistent view of the gateway
configuration.  The number of different valid configurations can
exponentially partition the anonymity set of clients.  For example,
if there are two valid configurations, that would yield two anonymity
sets consisting of clients that used one configuration and clients
that used the other configuration.  If the size of each set is large
enough, this may not be a significant loss of privacy in practice.
Ensuring that many clients share a configuration is necessary to
provide privacy for clients.
A specific method for a client to acquire configurations is not
included in this specification.  Applications using this design MUST
provide accommodations to mitigate tracking using gateway
configurations.  CONSISTENCY provides options for ensuring that
configurations are consistent between clients.
Draft: draft-ietf-ohai-ohttp

Commentary: cc 
 Alt - Used sticks out to me . So I looked for whether    is some prerequisite for oblivious HTTP and it does n't seem so . I 'm not sure many folks would be that familiar with Alt - Used , ? Is there some other , more familiar , filed that you could use as an example ?
A client interacts with the oblivious proxy resource by constructing
an encapsulated request.  This encapsulated request is included as
the content of a POST request to the oblivious proxy resource.  This
request MUST only contain those fields necessary to carry the
encapsulated request: a method of POST, a target URI of the oblivious
proxy resource, a header field containing the content type (see
(media-types), and the encapsulated request as the request content.
Clients MAY include fields that do not reveal information about the
content of the request, such as Alt-Used ALT-SVC, or information that
it trusts the oblivious proxy resource to remove, such as fields that
are listed in the Connection header field.
A client interacts with the oblivious proxy resource by constructing
an encapsulated request.  This encapsulated request is included as
the content of a POST request to the oblivious proxy resource.  This
request MUST only contain those fields necessary to carry the
encapsulated request: a method of POST, a target URI of the oblivious
proxy resource, a header field containing the content type (see
(media-types), and the encapsulated request as the request content.
In the request to the oblivious proxy resource, clients MAY include
additional fields.  However, those fields MUST be independent of the
encapsulated request and MUST be fields that the oblivious proxy
resource will remove before forwarding the encapsulated request
towards the target, such as the Connection or Proxy-Authorization
header fields SEMANTICS.
Draft: draft-ietf-ohai-ohttp

Commentary: It would be wrong to use " user agent " as this could be used for an HTTP request made by any client toward any server ( using the HTTP definitions ) . 
 Why do n't use " Oblivious Client " and the " OC " acronym , like OAuth does with " Authorization Server " ? This would preserve the natural " client " meaning , and could make the document more readable . The same acronym trick could ease readability wrt " Oblivious Request Resource " and " Oblivious Target Resource " ... 
 I know that people like acronyms , but it does n't really solve this problem . The oblivious HTTP client really is an HTTP client in the sense that HTTP knows ; calling it anything else would be more confusing , I think . As it seems like this is a case where more words would help . I 've more words . 
 Since there are so many occurrencies of I think that 's ok :) Probably in the Introduction , " client " means " HTTP client " , but anyway the difference is clear to me now :D 
 since there are various layers , the term " client " can be applicable to both the oblivious proxy / request resource . Maybe the term User agent can be appropriate when we refer to the originating client ? 
 Hi  , Does clarify things ? I think that " client " still makes a lot of sense here , but you are right that this is not an HTTP client in the strictest sense . ( Although , now that I write this , it really is , it 's just that this uses something other than a connection as a medium from getting a request to the server ... ) 
 LGTM
This document uses its own definition of client.  When referring
to the HTTP definition of client (Section 3.3 of HTTP), the term
"HTTP client" is used; see http-usage.
The oblivious proxy resource interacts with the oblivious request
resource by constructing a request using the same restrictions as the
client request, except that the target URI is the oblivious request
resource.  The content of this request is copied from the client.
The oblivious proxy resource MUST NOT add information about the
client to this request.
The client role in this protocol acts as an HTTP client both with
respect to the oblivious proxy resource and the oblivious target
resource.  For the request the clients makes to the oblivious target
resource, this diverges from typical HTTP assumptions about the use
of a connection (see Section 3.3 of HTTP) in that the request and
response are encapsulated rather than sent over a connection.  The
oblivious proxy resource and the oblivious request resource also act
as HTTP clients toward the oblivious request resource and oblivious
target resource respectively.
The oblivious proxy resource interacts with the oblivious request
resource as an HTTP client by constructing a request using the same
restrictions as the client request, except that the target URI is the
oblivious request resource.  The content of this request is copied
from the client.  The oblivious proxy resource MUST NOT add
information about the client to this request.
Draft: draft-ietf-ohai-ohttp

Commentary: Truly , the most interesting forwarding is what occurs at the Oblivious Request Resource , but this is a point of inflexibility that some people struggle with . No point in hiding how we might intend for a generic proxy to operate . The alternatives people invent are likely to be worse if we do n't at least point in the rough direction of a good solution . 
 Resource and the Oblivious Request Resource . This means that any encapsulated request sent to the Oblivious Proxy Resource will always be forwarded to the Oblivious Request Resource . This constraint was imposed to simplify proxy configuration and mitigate against the Oblivious Proxy Resource being used as a generic proxy for unknown Oblivious Request Resources . The proxy will only forward for Oblivious Request Resources that it has explicitly configured and allowed . This seems like it 's pretty inflexible . I wonder if maybe a compromise would be some kind of URL pattern ? 
 I agree that it 's written as very inflexible — I 'd be happy to see this change for wording . I 've personally interpreted this , though , to mean that the mapping could coincide with a URI template , but it 's up to the proxy of what to do . So , one proxy could say : maps to But another could say : maps to Both of these are 1:1 technically . The latter case needs to be careful that it has correct ACLs to not allow arbitrary access , but it 's still a mapped resource . 
 Yes , I think this explanation does a lot to clarify the possible approaches .
It is possible for a server to be configured with multiple Oblivious
Proxy Resources, each for a different Oblivious Request Resource as
needed.
It is possible for a server to be configured with multiple Oblivious
Proxy Resources, each for a different Oblivious Request Resource as
needed.  If the goal is to support a large number of Oblivious
Request Resources, clients might be provided with a URI template
TEMPLATE, from which multiple Oblivious Proxy Resources could be
constructed.
Draft: draft-ietf-ohai-ohttp

Commentary: Arguably , the TLS one is better , but one notation convention is better than two , so here we go . 
 It seems like the glossary would be easier to read if Figure 1 was shown before , thus making the terms clearer . Happier to submit a PR if that would help 
 This document uses both TLS - style and HTTPS binary message . Could we settle on one ? Perhaps the TLS - style because we are sharing PDUs with other HPKE - using stuff . 
 Is n't all of the specification in this document using TLS - style for the structs ? Binary HTTP is just one ( default ) payload content type that can be carried , it 's not really a definition of OHTTP . Can you clarify more what you mean ? 
 I guess this is n't BINARY , but rather the QUIC format . I plead it being early morning 
 Ah got it . Then aligning the styles makes sense , without changing the actual structs themselves .
format-key-config shows a single key configuration, KeyConfig, that
is expressed using the TLS syntax; see Section 3 of TLS.
The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF,
and AEAD respectively.  The definitions for these identifiers and the
semantics of the algorithms they identify can be found in HPKE.  The
Npk parameter corresponding to the HpkeKdfId can be found in HPKE.
format-key-config shows a single key configuration.
The definitions for the identifiers used in HPKE and the semantics of
the algorithms they identify can be found in HPKE.  The "Npk"
parameter is determined by the choice of HPKE KEM, which can also be
found in HPKE.
Draft: draft-ietf-ohai-ohttp

Commentary: Quite true .
An Encapsulated Request is comprised of a length-prefixed key
identifier and a HPKE-protected request message.  HPKE protection
includes an encapsulated KEM shared secret (or "enc"), plus the AEAD-
protected request message.  An Encapsulated Request is shown in fig-
enc-request. request describes the process for constructing and
processing an Encapsulated Request.
An Encapsulated Request is comprised of a key identifier and a HPKE-
protected request message.  HPKE protection includes an encapsulated
KEM shared secret (or "enc"), plus the AEAD-protected request
message.  An Encapsulated Request is shown in fig-enc-request.
request describes the process for constructing and processing an
Encapsulated Request.
Draft: draft-ietf-ohai-ohttp

Commentary: This makes the choice of a 1:1 mapping clear : avoid being used as an open proxy through explicit configuration of your ACLs . cc 
 The proxy has a fixed mapping . It 's resource maps to just one request resource . That 's a deliberate choice that we should probably be much more up front about . 
 Yes , I think this makes sense , but it took me a while to realize it when implementing . Having a section on mapping state on the proxy would be useful . 
  says : This relates in particular to the potential for generic services with open destination ( not a capability in the proposal ) to be used for nefarious purposes ( spamming , bot net command and control , hiding illegal activity , etc ... ) .
The identity of an oblivious proxy resource that will forward
encapsulated requests and responses to the oblivious request
resource.
The identity of an oblivious proxy resource that will forward
encapsulated requests and responses to a single oblivious request
resource.  See proxy-state for more information about the mapping
between oblivious proxy and oblivious request resources.
This section discusses various operational and deployment
considerations.
This protocol assumes a fixed, one-to-one mapping between the
Oblivious Proxy Resource and the Oblivious Request Resource.  This
means that any encapsulated request sent to the Oblivious Proxy
Resource will always be forwarded to the Oblivious Request Resource.
This constraint was imposed to simplify proxy configuration and
mitigate against the Oblivious Proxy Resource being used as a generic
proxy for unknown Oblivious Request Resources.  The proxy will only
forward for Oblivious Request Resources that it has explicitly
configured and allowed.
It is possible for a server to be configured with multiple Oblivious
Proxy Resources, each for a different Oblivious Request Resource as
needed.
Draft: draft-ietf-ohai-ohttp

Commentary: For and 
 I recognize that / some conditions and use cases , but it would help readers like me to have even more . A separate   / readme would be fine too . In the meeting chat today , I heard the suggestion of requesting map tiles as another use case , which makes sense to me : asking for map tiles is itself pretty revealing if connected to the user 's identity ( it might reveal your current location , or a location where you 're going to be ) and can be pretty transactional / stateless . Maybe search queries are similar . Safe browsing lookups was also mentioned . Having more example use cases might help in resolving other questions , like whether to support multiple HTTP requests at a time , or non - HTTP message bodies , etc . Ideally , we could explain the conditions under which adoption of ohttp will be useful -- maybe , a privacy need for reducing linkability of multiple requests or of a single request from user identity , and HTTP requests that are typically stateless or single - shot in some way , and frequent or performant - requiring at a certain level . 
 some more examples . I think we can safely close this now , so I 'm going to go ahead and do that . Please reopen with concrete suggestions if you think the new text is insufficient !
These are examples of requests where there is information in a
request that - if it were connected to the identity of the user -
might allow a server to learn something about that user even if the
identity of the user is pseudonymous.  Other examples include the
submission of anonymous surveys, making search queries, or requesting
location-specific content (such as retrieving tiles of a map
display).
Draft: draft-ietf-ohai-ohttp

Commentary: What do we want to do with this draft ? Should we dispatch it and find it a home ? 
 Good question . I wonder if secdispatch would be a good place to ask . 
 Clients should cache server keys for some time . TTL can be supply in a cache - control header of a ohttp - keys response . Should this be mentioned or is it implied ? 
 The document does n't really define the key configuration acquisition method , so it ca n't really cover details like caching ( or retention ) . Getting into specifics with HTTP Cache - Control is out of scope . There is discussion of retention periods in , which are relevant and might be worth pointing to . That document has uncertain status , but we might still use an informative reference .
Request resources are capable of linking requests depending on how
KeyConfigs are produced by servers and discovered by clients.
Specifically, servers can maliciously construct key configurations to
track individual clients.  A specific method for a client to acquire
key configurations is not included in this specification.  Clients
need to consider these tracking vectors when choosing a discovery
method.  Applications using this design should provide accommodations
to mitigate tracking using key configurations.
Request resources are capable of linking requests depending on how
KeyConfigs are produced by servers and discovered by clients.
Specifically, servers can maliciously construct key configurations to
track individual clients.  A specific method for a client to acquire
key configurations is not included in this specification.  Clients
need to consider these tracking vectors when choosing a discovery
method.  Applications using this design should provide accommodations
to mitigate tracking using key configurations.  CONSISTENCY provides
an analysis of the options for ensuring the key configurations are
consistent between different clients.
Draft: draft-ietf-ohai-ohttp

Commentary: Nk was n't described properly before . This improves that , but puts the citations together .
The Nenc parameter corresponding to the HpkeKdfId can be found in
HPKE.
The size of the Nonce field in an Encapsulated Response corresponds
to the size of an AEAD key for the corresponding HPKE ciphersuite.
The Nenc and Nk parameters corresponding to the HpkeKdfId can be
found in HPKE.  Nenc refers to the size of the encapsulated KEM
shared secret, in bytes; Nk refers to the size of the AEAD key for
the HPKE ciphersuite, in bits.
Draft: draft-ietf-ohai-ohttp

Commentary: This is a breaking change , but I think that it 's worthwhile . " request " is an extraordinary generic string and the risk of it being used in another context is too high . 
 We can address test vectors in a followup PR .
Compute an HPKE context using "pkR", yielding "context" and
encapsulation key "enc".
Compute an HPKE context using "pkR" and a label of "ohttp
request", yielding "context" and encapsulation key "enc".
Compute an HPKE context using "skR" and the encapsulated key
"enc", yielding "context".
Compute an HPKE context using "skR", a label of "ohttp request",
and the encapsulated key "enc", yielding "context".
Export a secret "secret" from "context", using the string
"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".
Export a secret "secret" from "context", using the string "ohttp
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".
A server MUST ensure that the HPKE keys it uses are not valid for any
other protocol that uses HPKE with the "ohttp request" label.
Designers of other protocols, especially new versions of this
protocol, can ensure key diversity by choosing a different label in
their use of HPKE.  The "ohttp response" label was chosen for
symmetry only as it provides key diversity only within the HPKE
context created using the "ohttp request" label.
Draft: draft-ietf-ohai-ohttp

Commentary: See discussion on - list . 
 See also 
 If we 're pinning the contents of the encapsulation to message / bhttp , it seems like we also ought to change the HPKE info strings to match ( " request " -"message / bhttp - request " or whatever ) . When someone tries to reuse this layer of encapsulation , I think they ought to change the info string accordingly to match whatever the underlying type is . And it might not hurt to add guidance to such people in the security considerations . Can we do this in a followup PR ? 
 I agree that we should think about content types a bit more , but that seems appropriate for another PR . 
 With , we 're enforcing a 1:1 mapping between message / ohttp - req and message / bhttp , but we do n't have any cryptographic enforcement of this pairing . If someone were to reuse the encapsulation mechanism in this document with another message type , say , to encapsulate application / dns - message values with a application / oblivious - dns - message wrapper , then we 'd probably want to ensure that targets ca n't get confused between these two types . We could use the HPKE info string to separate these two protocols . ( This is related to . ) 
 The format I 've sketched out for binary messages can be padded with zeros without needing a separate padding field . That 's probably a feature worth mentioning in both drafts . 
 Padding is in the binary HTTP draft now .
A binary-encoded HTTP message; see BINARY.
Padding of arbitrary length which MUST contain all zeroes.
HTTP message encapsulation uses HPKE for request and response
encryption.  An encapsulated HTTP message includes a binary-encoded
HTTP message and no other content; see BINARY.
A proxy can use padding to reduce the effectiveness of traffic
analysis.
A proxy can use padding to reduce the effectiveness of traffic
analysis.  Padding is a capability provided by binary HTTP messages;
see Section 3.8 of BINARY.
Draft: draft-thomson-ohai-ohttp

Commentary: Fixing a nit about AAD length
Construct additional associated data, "aad", from "keyID",
"kdfID", and "aeadID" or as the first five bytes of "enc_request".
Construct additional associated data, "aad", from "keyID",
"kemID", "kdfID", and "aeadID" or as the first seven bytes of
"enc_request".
Draft: draft-thomson-ohai-ohttp

Commentary: The sentence here seemed a little repetitive . This expands it some .
A server retains a secret key that might be used to remove protection
from messages over much longer periods.  A server compromise that
provided access to the oblivious request resource secret key could
allow an attacker to recover the plaintext of all requests sent
toward affected keys and all of the responses that were generated.
Accessing requests and responses also requires access to requests and
responses, which implies either compromise of TLS connections or
collusion with the oblivious proxy resource.
A server retains a secret key that might be used to remove protection
from messages over much longer periods.  A server compromise that
provided access to the oblivious request resource secret key could
allow an attacker to recover the plaintext of all requests sent
toward affected keys and all of the responses that were generated.
Even if server keys are compromised, an adversary cannot access
messages exchanged by the client with the oblivious proxy resource as
messages are protected by TLS.  Use of a compromised key also
requires that the oblivious proxy resource cooperate with the
attacker or that the attacker is able to compromise these TLS
connections.
Draft: draft-thomson-http-binary-message

Commentary: Try again .
Field names and values MUST be constructed and validated according to
the rules of Section 8.2.1 of H2.  A recipient MUST treat a message
that HTTP/2 regards as malformed by these rules as invalid; see
invalid.
Field names and values MUST be constructed and validated according to
the rules of Section 8.2.1 of H2.  A recipient MUST treat a message
that contains field values that would cause an HTTP/2 message to be
malformed (Section 8.1.1 of H2) as invalid; see invalid.