At Mon, 24 Oct 2016 21:58:42 +0800 (GMT+08:00), "Jiankang Yao" <ya...@cnnic.cn> wrote:
> We have updated it to the new version, simplying the mechanism. > pls kindly help to review it. any comments are welcome. > If Seoul DNSOP meeting has some time slot for it, I will appreciate it. A few comments on a quick read: - Does it assume to be used for exchanges between stub and recursive resolvers? If it's also intended to be used between recursive and authoritative, how does it handle a delegation answer? - Should we assume SOA('s) in the authority section for negative answers? - What if AQ-TYPE is ANY? I suspect the answer can be ambiguous in that case (even though it may not be a big issue in practice). For example, if the first AQ-TYPE is ANY and the second is AAAA, and the answer section only contains one AAAA (in addition to the answer to the main question), it's ambiguous for which AQ the AAAA answer is. - Likewise, what if the result is a CNAME chain? For example, if the answer to the first AQ is a CNAME and the name for the second AQ is the CNAME's target, it can be ambiguous for which AQ the subsequent answer (that follows the CNAME answer) is. - I wonder whether there are other cases where the results can be ambiguous and whether some of them can be more troublesome than the above examples. - Maybe I missed something obvious, but the purpose of the AQ bit, and Count and Seq fields is not clear to me. Some more explanations might help. - Regarding the definition of "Prefix" in Section 3: o Prefix field is a substring between the main domain name of the main quesiton and the accompanying domain name of the accompanying question. what "substring" means is vague to me. It's not even clear whether this is an ascii string or it's a complete wire-format domain name. Likewise, the notation of "S-S1" is quite informal. Since this is part of a formal definition, I'd suggest making it more formal and precise, eliminating any ambiguity depending on the interpretation. - This part of Section 4 seems to assume a responder implementation generally echos back unrecognized EDNS options: [...] An AQ unaware responder is expected to ignore the AQ OPT of the query, and may echo the received OPT back into additional section of the response message. and the following part of Section 5 seems to rely on that assumption: If the initial value of the AQ-RCODE is unchanged in the response, it indicates that the responder is AQ unaware. But, as far as I know actual implementations tend to NOT echo back unrecognized options. - Section 6: there's a missing period after 'example.com': Answer | example.com IN A 192.168.0.1 | -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop