This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review.

This document is Almost Ready. (I propose we add a TSV ART review result between "Almost Ready" and "Ready" called "Close Enough".)

I did not find any issues of particular interest to the Transport Area in the draft: while providing a tunnel of sorts for clients to interact with servers via a proxy, the mechanism described here appears to use three (application-layer) HTTP hops (client->relay, relay->gateway, gateway->server) for every OHTTP request (client->server) and the reflection of those three hops for the corresponding reply, all without introducing any novel transport interactions and without any multiplicative increase in payload size.

Suggestions:

- Section 4 refers to gateways as "servers", presumably copying from existing HPKE text, which is confusing in the context of the rest of this document. While a gateway may be co-located on the target server in the typical case, conceptually it is a separate entity. My recommendation for reader clarity is to alpha-substitute terminology related to entities in this section to match the OHTTP model from figure 1.

- The document might also benefit from explicitly introducing "relay", "gateway", and "server" as shorthand for "Oblivious Relay Resource", "Oblivious Gateway Resource", and "Target Resource", respectively, but not if the given verbosity is customary for work in the HTTP ecosystem.

- §5 states:

    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

  I don't think "before removing encapsulation of the request" is quite right. The gateway must respond without encapsulation under two conditions: when decapsulation of the request fails for whatever reason, or when a gateway-generated response is directed at the relay rather than at the client. The combination of the two may be what you meant by "before", but I would phrase this in a way that doesn't refer to the relative timing of gateway actions that could be implemented in an order unanticipated by the draft authors and yet still comply with the normative language of the draft.

- §6.3 states "Nonsecure requests...SHOULD NOT be used if the Oblivious Gateway and Target Resources are operated by different entities". Unless "entity" has some specific term-of-art meaning in this context, I think this needs to be strengthened. My company, for example, is an entity that operates servers globally, but we should still not use plaintext HTTP between gateways and servers separated by the public internet.

Nits:

- I see at least one instance of the phrase "is comprised of", which should be rephrased as either "comprises" or "consists of". "Comprise" is used properly elsewhere, which I like to see as an English nerd.

- §4.4: s/secret secret/secret/