Last Call Review of draft-ietf-ohai-ohttp-05
review-ietf-ohai-ohttp-05-tsvart-lc-rose-2022-12-08-00

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/