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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to