On 11 May 2021, at 12:32, Ben Schwartz <bem...@google.com> wrote: > On Tue, May 11, 2021 at 9:20 AM Joe Abley <jab...@hopcount.ca> wrote: >> 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.
Yes, that's what I tried to sketch out before. The SvcParams in an SVCB RR becomes a pointer to a second RRSet with a different RRType. So the SvcParams information is spread across multiple records in a a different RRSet from the SVCB RRRSet. If it's still not clear what I mean, I can try again. Note that I'm not proposing a change to the spec, just illustrating that different design choices were possible that avoid the need for delimiters or escaping. While we're on the topic of RRSets and multiple RRTypes, the way that AliasMode and ServiceMode are distinguished is also a bit clunky; what are the implications of needing to remove all ServiceMode RRs in an RRSet in the event that one of them is found to be in AliasMode if we imagine that some consumers of these responses will get it wrong? Was there any thought given to an RR schema that prevented such ambiguities from being published? > That is not just a variation on SVCB, but an entirely different proposal. I'm not sure how you think of those two things as different. Isn't every variation of something a new something? >>> * 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. What are the concrete syntactical structure and the abstract conceptual structures? If those are terms of art I apologise; I'm not familiar with them. What are you comparing the client implementation to in your final comment? What other design option was found to be more complex to implement on the client side? I'm sure it feels frustrating to get all these questions at the last minute, and I apologise (as I think I said before) that I did not follow this work more closely, earlier. Joe
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
