On Tue, May 11, 2021 at 9:20 AM Joe Abley <jab...@hopcount.ca> wrote:
> Hi Ben, > > On 11 May 2021, at 12:08, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> > wrote: > .. > * 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 sounds like you're proposing a design in which the information in one SVCB record is not just spread across multiple records in an RRSet, but actually across multiple RRSets. That is not just a variation on SVCB, but an entirely different proposal. > * 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? > To restate this sentence, it is good because the concrete syntactical structure matches the abstract conceptual structure, and (relatedly) because it simplifies client implementation.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
