Overall, I believe this draft is clear and well-written. It also does a
great job of motivating why it should be published, and I agree with that
motivation.
I read the document closely, and I have found one solvable issue and a few
nits.
Here is the issue. s4.1 states:
The "targethost" and "targetpath" variables are used to construct the
request to forward to the Target. The Proxy is expected to send the
Client's request using the URI constructed as "https://targethost/
targetpath".
This is incorrect: you'd end up with two slashes in the path sent to the
target, because targetpath starts with a leading slash.
More importantly, targethost and targetpath are not clearly defined: the
definition of the URI template should be made in normative text, not in an
example nor as "The Proxy is expected to". Also, how are these encoded?
For example how do I encode the targethost when the target host is an IPv6
literal with a port?
Luckily these rules are already spelled out in existing IETF standards, we
just need some normative text and references, so I expect this to be easily
solvable.
Here's a set of nits that I'd prefer to see fixed but that shouldn't block
publication:
nit in s4.1: define what a correctly encoded request is before saying
"Proxies MUST check"
nit in s4.3: "This is similar to how DoH handles HTTP request codes" should
this be "this is equal..."
nit in s5: replace "[I-D.irtf-cfrg-hpke] Section 7" with "Section 7
of [I-D.irtf-cfrg-hpke]" to avoid broken link more general nit: using
short names for references would make the document easier to read (e.g.
[HPKE])
nit in s10: "This document describes an experimental extension to the DoH."
I'd suggest "to DoH" or "to the DoH protocol"
meta nit: framing this as an extension to DoH is strange, in the sense that
it has very little to do with the DoH protocol. This is technically a way
of exchanging DNS messages over HTTPS, but it's somewhat far removed from
the encoding used by DoH. I'd personally call it a new mechanism inspired
by DoH. Not a blocker though, just my $.02.
nit in s12.1: "as defined in this Section 6.1." - remove the word this.
From @DavidSchinazi:
Overall, I believe this draft is clear and well-written. It also does a great job of motivating why it should be published, and I agree with that motivation.
I read the document closely, and I have found one solvable issue and a few nits.
Here is the issue. s4.1 states: The "targethost" and "targetpath" variables are used to construct the request to forward to the Target. The Proxy is expected to send the Client's request using the URI constructed as "https://targethost/ targetpath".
This is incorrect: you'd end up with two slashes in the path sent to the target, because targetpath starts with a leading slash.
More importantly, targethost and targetpath are not clearly defined: the definition of the URI template should be made in normative text, not in an example nor as "The Proxy is expected to". Also, how are these encoded? For example how do I encode the targethost when the target host is an IPv6 literal with a port?
Luckily these rules are already spelled out in existing IETF standards, we just need some normative text and references, so I expect this to be easily solvable.
Here's a set of nits that I'd prefer to see fixed but that shouldn't block publication:
nit in s4.1: define what a correctly encoded request is before saying "Proxies MUST check"
nit in s4.3: "This is similar to how DoH handles HTTP request codes" should this be "this is equal..."
nit in s5: replace "[I-D.irtf-cfrg-hpke] Section 7" with "Section 7 of [I-D.irtf-cfrg-hpke]" to avoid broken link more general nit: using short names for references would make the document easier to read (e.g. [HPKE])
nit in s10: "This document describes an experimental extension to the DoH." I'd suggest "to DoH" or "to the DoH protocol"
meta nit: framing this as an extension to DoH is strange, in the sense that it has very little to do with the DoH protocol. This is technically a way of exchanging DNS messages over HTTPS, but it's somewhat far removed from the encoding used by DoH. I'd personally call it a new mechanism inspired by DoH. Not a blocker though, just my $.02.
nit in s12.1: "as defined in this Section 6.1." - remove the word this.