On May 10, 2021, at 9:56 AM, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> wrote: > > I don't support breaking the SvcParams into separate RRs across the RRSet. > This would be an extremely inefficient encoding in wire format, and would > conflict with the usual understanding of resource records as independently > meaningful alternatives.
Fully agree. It is a large change in the DNS protocol for a receiver to have to internally group multiple RRs based on matching (priorty | target) tuples and make security decisions based on the group, not on the record. > It would also require a dramatic rewrite of a specification that is now > widely deployed. Er, screw that. The fact that some developers deployed this even though it hadn't even completed WG last call, much less had a wider IETF review, is a problem for those developers to solve. > As for the question of commas, I continue to believe that the current text is > preferable. I believe that the behavior Dick is advocating for is in fact > the one that was present in the draft until -02 [1], changed here [2]. We > changed this text after receiving complaints from WG members that the > algorithm as specified was too complicated, along with my own experiences > attempting to implement it in multiple codebases that apply char-string > decoding during or before tokenization. This is central to the problem of SVCB: it is more complex than traditional DNS RRtypes, and different developers have different views of what would make it simpler for them to implement and/or simpler for zone operators to type into zone files. I hope Dick's proposed simple addition is useful. I'm not a developer, and I don't write into zones very often, but I suspect that "it's all in one record that has an addition to the parsing" will be easier and safer to implement than "the receiver has to handle groups of records in a new way". --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
