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. Yours, Daniel On Fri, Oct 14, 2022 at 5:43 AM R. Gieben via Datatracker <nore...@ietf.org> 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@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
