Hi Ben, On 10 May 2021, at 12:56, Ben Schwartz <bem...@google.com> wrote:
> I don't support breaking the SvcParams into separate RRs across the RRSet. > This would be an extremely inefficient encoding in wire format, I think that assertion may well be worth challenging, and... > and would conflict with the usual understanding of resource records as > independently meaningful alternatives. ... I think we disagree about how we usually interpret the use of RRSets with more than one member RR. > It would also require a dramatic rewrite of a specification that is now > widely deployed. However, this seems clear (see my earlier horse/sailed comment). Given that the draft semantics of SVCB have already seen some implementation, any new semantics would need a new RRType (SVCC? :-) I admit I have a certain aesthetic bias here since I find the entire concept of embedding a list of parameters inside a single RR to be very un-DNS-like. However, I found Mr Wouter's concerns (paraphrasing, "perhaps we should pre-allocate a set of CVE numbers for this") worth considering, and would hope that if there is a reason to burn the current RRType on security grounds (or any grounds more compelling than aesthetic) that we would do so. Joe
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
