> On May 19, 2021, at 1:34 PM, Brian Dickson <brian.peter.dick...@gmail.com> 
> wrote:
> 
> 
> 
> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly <tpa...@apple.com 
> <mailto:tpa...@apple.com>> wrote:
> I wanted to chime in on this discussion as a client-side implementor who has 
> already widely deployed support for SVCB/HTTPS.
> 
> The current format, where the parameters are structured as a list within a 
> single RR, is certainly simpler and less error prone for processing. Much of 
> the information contained as parameters within the SVCB RR are useful for 
> higher-level “application” logic. Within our deployment, the DNS stub 
> resolver daemon receives the RR and does the parsing, and passes up the 
> parameters bundle as a blob that is more or less opaque, to the layer that 
> handles actual connection processing (doing happy eyeballs, protocol 
> selection).
> 
> Processing the content of SVCB parameters must be handled atomically: the 
> ALPN, ECH config, and any other information must be handled clearly as a unit 
> and not have any chance of being broken up. Lots of code is already based on 
> processing RRs as chunks of data, and requiring anyone looking at the 
> information to stitch the parameter list back together based on multiple RRs 
> that must be in a particular order adds complexity and invites in bugs and 
> errors.
> 
> I’d strongly encourage sticking with the wire image we’ve already been using 
> and deploying.
> 
> Would it be accurate to say that as long as the wire format of both SVCB and 
> HTTPS do not change, your client implementation(s) would not be impacted by 
> any changes to zone file format?
> 
> I.e. you don't implement any server code, so what the zone format is does not 
> affect you, and how the wire format gets produced from the zone format is not 
> relevant to you?

That’s correct. My main concern here is keeping the wire format consistent and 
simple. How the zone format file works is indeed something separate, and not 
something I have strong opinions on. Anything we can do to make the processing 
simple for both sides is great.

> 
> Thank you for the details on how your client uses the wire format and the way 
> those impact the end client systems.

Absolutely! Happy to answer any further questions as well.

Best,
Tommy
> 
> Brian

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

Reply via email to