Summary
=======

This document fixes a gap between OHTTP servers and clients that was previously
only addressed by out-of-band configuration. Apart from one security note
(that's more on the how-do-we-get-it-implemented-well side and not on the
there-is-a-flaw side), I think this is in very good shape.

Typical ART Area Issues
=======================

* The document does not provide individual extension points, but that is OK:
  Both OHTTP's evolution mechanism (media types) and SVCB records' mechansisms
  (adding new protocol names such as h2/h3) are availble.

Security
========

* Key configuration fetching: This introduces a direct HTTP request from the
  client to the Gateway, which with my limited overview of OHTTP is a new leg,
  and reveals to the gateway an IP address from which it will be accessed (even
  though the rules in section 5 on of not telling the relay where
  .well-known/ohttp-gateway redirected will make sure that request can't be
  correlated with the later OHTTP requests trivially). It does hint at using a
  proxy (with later remarks in sec-cons pointing to a possible solution), but I
  think it'd make sense to explore that option more thoroughly.

  It's hard for this document to mandate that those requests be proxied through
  the relay (which doesn't generally do HTTP style proxying, and could be
  limited to allow-listed requests such as GET /.well-known/ohttp-gateway
  accepting application/http-keys), but unless that has been gone through in
  previous discussions (in which case I'd appreciate a pointer), I think it'd
  make sense to make that a default operation, falling back to direct GETs only
  if the relay happens to not support that operation.

  If this is just done to avoid a normative reference to the comparatively
  young CONSISTENCY document, maybe it'd be worth the wait. I haven't gone
  through that complete document, it seems to offer several approaches. It may
  not be possible to pick one that's good for all purposes, but if any of them
  need collaboration from the relay, it'd be helpful if implementers took good
  note that more is expected and needed of relays now.

Editorial remarks
=================

* "an Oblivious Gateway Resource (gateway), which gates access to the target.":
  I'd read that as limiting who may access the target, which to my
  understanding is not the case. Maybe "which offers Oblivious HTTP accesst to
  the target"?

* 'he "ohttp" SvcParamKey (Section 8) is used': I think that the forward
  reference into IANA considerations is more confusing than helpful. This key
  is defined here, IANA considerations just contain instructions to make it
  happen in the registries. A reference back up (from table 8.1, s/This
  document/This document (Section 4)/) would make more sense.