Hi,
Thanks for the review. So the reason we do not consider DOH is that DoH 8484 has been defined for communications between a client and a resolver while in our case TLS is used between two authoritative servers.
This document focuses on communication between DNS clients (such as operating system stub resolvers) and recursive resolvers.
I see your point regarding the standard. What we wanted to say is that the standard port is defined by a standard. The standard might be the standard defining the transport protocol - which is the case for DoT, or eventually by the DHCP option. The reason I do not like "standard action" is that in our case DoT there is no action to be taken - the standard is already there. On the other hand I did not like the current proposal either, so I changed to "a standard" and hope this addresses your concerns. Thanks for raising this.
OLD:
It is worth noticing that the Supported Transport field does not enable to specify a port and the used port is defined by standard.
NEW:
It is worth noticing that the Supported Transport field does not enable to specify a port and the used port is defined by a standard.
Daniel
On Fri, Oct 14, 2022 at 5:43 AM R. Gieben via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: R. Gieben
Review result: Ready with Nits
A straight forward document specifying dhcpv6 options, had little trouble
reading it. Got a bit lost with acronyms though, i.e. forgetting what ORO is
when nearing the end of the document.
Any reason why DNS over HTTP (DoH, RFC 8484) isn't standardized in the same
document?
A Nit (maybe): in section 4.2: "... defined by standard." -> "... defined by
standard action" ?
_______________________________________________
homenet mailing list
homenet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/homenet
Daniel Migault
Ericsson
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
