Hi Richard, all, I foolishly allowed Tim to pay for lunch and therefore have been tricked into doing actual work. There are a couple more of these inbound to the list, one for each of the e-mails containing points that were found not to have been addressed in -04. My goal is to identify some kind of consensus on each this week and the propose some actual text.
With reference to: https://mailarchive.ietf.org/arch/msg/dnsop/_W6ois9hFYlAWUmka21FX91910s > - There is no mechanism for signaling section 4.1/ section 4.3 "partial > response" behavior to clients (e.g., a new OPT record EDNS header flag > bit > > <http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13> > ). Correct. I presume you are suggesting that there should be one. I have not heard anybody else require such a thing, and new EDNS code points are thought by at least some to be thorny things to pass undigested through middleboxes so I think it's a non-trivial suggestion that would require a proposal that itself would need thorough review. That feels out of scope for this document, but perhaps something analogous to extended RCODEs in the sense that it's channel metadata. I think it would be uncontroversial to note explicitly that the mechanism described in this document contains no such signalling, however. Let me know if that seems like a pragmatic solution. > - Insisting that the HINFO OS field SHOULD be empty ("set to the null > string") seems a little too strong; there's room in it for—and value > from—a short explanation (e.g., as can be observed today: > > dns.cloudflare.com > . 3789 IN HINFO "Please stop asking for ANY" "See > draft-ietf-dnsop-refuse-any"). I'd prefer text like "The OS field > of the HINFO > RDATA SHOULD be short to minimize the size of the response, and MAY be > empty or MAY include a summarized description of local policy." I am happy with that text. Unless there are violent objections from the assembled throng, I will make that change. > - "Conventional [ANY] response" is used but not defined. I am not sure why it's ambiguous without a definition. To me that phrase seems pretty straightforward; if your core objection is that the DNS standards are not written down with great accuracy, yeah. The only definition I can think of really is something like "A response to a query that had QTYPE=ANY which follows convention" which just seems longer, not more clear. What did you have in mind? > - "ANY does not mean ALL" is misleading—RFC 1035 > < > https://tools.ietf.org/html/rfc1035#section-3.2.3> > is clear about > QTYPE=255 being "a request for *all* records" (emphasis mine). That > said, the proposed *response* behavior is consistent with that RFC. All records that the server constructing the response knows about? All records that the server can fit into the response given the constraints of the available transport? ALL THE RECORDS IN THE WHOLE WORLD! That was an obscure reference to Blackadder the Second that probably pleases nobody but me. ("Kill Bob!" "Never!") I think to that point we can implicitly acknowledge between ourselves that less ambiguity would be nice, but that on the whole this text as-is at worst does no harm, and at best helps illustrate the philosophy of the approach being described. Let me know how much of that you can live with :-) Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
