Hi Joe, On 5/10/21 1:42 AM, Joe Abley wrote: > On May 9, 2021, at 19:27, Paul Hoffman <paul.hoff...@icann.org> wrote: > >> If I'm wrong about this being as good as it can be, there must be an item >> delimiter that is better than a comma. I am not thinking creatively enough >> to figure out what might be better than a comma. I'd be happy to hear >> proposals for a better item delimiter. > > I am quite behind on this topic, but I presume there's a reason to put all > these key-value pairs in a list in one RR? > > If we compare the two fictional RRTypes EG1 and EG2 illustrated below: > > example.com. EG1 key1=value1,key2=value2,... > > example.com. EG2 key1 value1 > example.com. EG2 key2 value2 > > It seems to me that EG2 avoids the need for delimiters at all. There's a bit > of overhead resulting from the need for a larger RRSet but it's not obvious > that that's a proble> > If the SvcParams field of the SVCB RR was a domain name rather than an > explicit list this would all look a lot more DNS-like as far as parsing goes. > This would also allow a single set of SvcParams key-value pairs to be > included in different service bindings without having to be sent each time or > to be bound to something provided a service provider (SVB in customer.org > zone that refers to SvcParams.provider.com) giving the provider some ability > to maintain some aspects of the service).
You then invite the following issues: Clients need to match the tuple (ownername + prio + target) and get all data from all matched rrsets, whereas now you get all that data in one piece of rdata. A client also can't figure out (if not doing DNSSEC valdiation themselves) if you have received all the SVC data for a certain name. Cheers, Pieter _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
