Hi Ben, On 11 May 2021, at 12:08, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> wrote:
> OK, I've proposed text documenting the reasoning here: > https://github.com/MikeBishop/dns-alt-svc/pull/323/files > <https://github.com/MikeBishop/dns-alt-svc/pull/323/files>. I definitely appreciate the effort, since I think I agree that documenting the design decisions are a good idea. However, I think perhaps the reasoning needs more work (see below). > The proposed text is: > > Storing a key-value map within a single RR, rather than placing each key-value > pair in a separate RR, provides the following advantages: > > * It enables a familiar key=value zone file syntax that matches zone authors' > experience with command-line arguments and other typical key-value mappings. Since zone files generally don't include any key value pairs of the kind SVCB currently specifies, I don't understand this point. Surely the unfamiliarity with how to parse this kind of syntax illustrates that this is not familiar? > * It avoids requiring zone file authors to manage inter-pair binding IDs. I think you will have to expand that point, since I'm not convinced I understand what you mean. > * It makes each record independently meaningful, consistent with the usual > convention for DNS records (c.f. SRV, MX, AAAA, etc.). If you think of the DNS itself as a key-value store, with keys of the form (QCLASS, QTYPE, QNAME) then the corresponding value is an RRSet, not an individual resource record. Individual RRs are not returned in responses; RRSets are (understanding that the results are not functionally different in the case of an RRSet with a single member). Your examples of SRV, MX and AAAA, somewhat ironically, are all prime examples of why the whole RRSet matters and you can't rely on a single RR from a set in a respose. > * It saves at least 11 bytes of overhead per parameter by avoiding repetition > of > the name, type, class, TTL, and inter-pair binding ID. ... but it inflates response volume in the case where a separate SvcParams RRSet is able to be cached significantly longer than the SVCB RRSet. > * It provides a wire format whose structural nesting matches the logical scope > of each key=value pair, and avoids requiring cross-RR reconstruction of > bindings by the client. This seems like it is documenting a design choice rather than explaining it. The decision to include a list of key-value pairs in the SVCB RDATA is good because it avoids having to do something different? Joe
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
