Stewart, thanks for your reviews. Paul, thanks for your responses. I have entered a Yes ballot.
Alissa > On Aug 4, 2018, at 4:53 AM, Stewart Bryant <[email protected]> wrote: > > Reviewer: Stewart Bryant > Review result: On the Right Track > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-doh-dns-over-https-12 > Reviewer: Stewart Bryant > Review Date: 2018-08-04 > IETF LC End Date: 2018-08-08 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > ID-Nits picks up a downref, but the appropriate warning was included in the > IETF LC email. > > Major issues: > > 4. Selection of DoH Server > > SB> I am surprised that there is no discussion of the need to specify > SB> the raw IP address of the sever as part of the URI, and that there > SB> is no discussion of the server address IP address family in the document. > SB> I would have thought that there should at least be a reference to > SB> "happy eyeballs" and and discussion of an optimization strategy of > SB> what to do if there was a response on Ipv4 and not IPv6 etc etc. > > ========== > > The same DNS query for www.example.com, using the POST method would > be: > > :method = POST > :scheme = https > :authority = dnsserver.example.net > :path = /dns-query > accept = application/dns-message > content-type = application/dns-message > content-length = 33 > > <33 bytes represented by the following hex encoding> > 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 > 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 > 01 > > SB> At this point in the text am at a loss to understand the 33 bytes. > SB> Having read to the end of the text, I assume that this is a binary encoded > SB> DNS query in "one the wire format" but this point needs to be made clear, > SB> as does the explicit encoding. It would be really useful if there was an > SB> example of both formats side by side. > > ========= > The DNS query is 94 bytes represented by the following hex encoding > SB> Again in what format? > > ========= > :method = GET > :scheme = https > :authority = dnsserver.example.net > :path = /dns-query? (no space or CR) > dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR) > bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR) > dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ > accept = application/dns-message > > SB> I am not a DNS or HTTP specialist, so please help me understand > SB> what the string starting "dns=" is. > > ========== > > 5.2.2. HTTP Response Example > > SB> Nits says: > > -- The document has examples using IPv4 documentation addresses according > to RFC6890, but does not use any IPv6 documentation addresses. Maybe > there should be IPv6 examples, too? > > SB> I am not sure if there are any IPv4 vs IPv6 issues but it would be > helpful to > SB> clarify the point. > > ========= > > <64 bytes represented by the following hex encoding> > 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 > 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 > 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f > 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 > > SB> At this point in the text I am still wondering what this encoding means, > I assume that > SB> it is a hex representation of the payload received > SB> back from a normal DNS query. > > ========= > > 7. Definition of the application/dns-message media type > > The data payload for the application/dns-message media type is a > single message of the DNS on-the-wire format defined in Section 4.2.1 > of [RFC1035]. > > SB> That would have been useful to have known earlier > SB> However 4.2.1 just talks about UDP and not the message syntax. > SB> Also presumably we are talking about the payload of the UDP > SB> message excluding the UDP header. > > SB> "on-the-wire" is a potentially confusing term, since it gets us > SB> into network byte order etc. > SB> I think the whole thing would be clearer is you said that your > SB> message was identical to the payload of the UDP payload of an > SB> RFC1035 as seen by a server (and then add some specification > SB> about the payload to hex method you are using) > SB> It would also be helpful to the reader to note whether > SB> any of the 25 updates to RFC1035 impact any of the specification > SB> described in this memo. > > ======= > > The format was originally for DNS over UDP. Although > [RFC1035] says "Messages carried by UDP are restricted to 512 bytes", > that was later updated by [RFC6891]. This media type restricts the > maximum size of the DNS message to 65535 bytes. Note that the wire > format used in this media type is different than the wire format used > in [RFC7858] (which uses the format defined in Section 4.2.2 of > [RFC1035]). > > SB> 4.2.2 does not seem to describe a format, unless you are implicitly > SB> saying that 4.2.1 does not have a length 4.2.2 does and you > SB> are encoding the length another way and hence use 4.2.1 format. > SB> Either way neither of these sections of RFC1035 really specify the > SB> format, that is provided earlier in the RFC. > > =========== > > Encoding considerations: This is a binary format. The contents are a > DNS message as defined in RFC 1035. The format used here is for DNS > over UDP, which is the format defined in the diagrams in RFC 1035. > > SB> With or without the UDP header? > > ========== > > Minor issues: > > Abstract > > This document describes how to make DNS queries over HTTPS. > > SB> This is the shortest abstract I have seen in a long while, if > SB> not forever. It would be helpful to the undecided reader if > SB> a little more context from the Introduction was included in the > SB> abstract. > > ========= > > Nits/editorial comments: > > These caches may exist beteen the > SB> s/beteen/between/ > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
