On Tue, Sep 24, 2019 at 3:19 PM Erik Nygren wrote: > Following discussions around the "HTTPSSVC" record proposal in Montreal with > the DNSOP, HTTP and TLS WGs, we've updated what was previously > "draft-nygren-httpbis-httpssvc-03". The new version is > "draft-nygren-dnsop-svcb-httpssvc-00". This incorporates much of the > feedback from the WG discussions, as well as feedback from discussions with > the TLS WG (as we'd like to see this replace the need for a separate ESNI > record).
I support adoption of the draft by this working group. I generally like the content. I think the HTTPSSVC specifics leak into the generic SVCB specification a little but that could be polished later and I haven't noticed any outstanding issues. One thing I'm concerned about is the SvcParamKey wire format (and registry). You propose that each parameter would have a code point and a value encoded in a form specific to the parameter type. On one hand it will lead to compact encoding but on the other hand an introduction of new parameter type may become complex for the implementers. Have you considered encoding the parameters in a free form? Maybe as a string, similarly how SPF configuration is stored in the TXT record. It could look like this: example.com. 7200 IN HTTPSSVC 0 svc.example.net. "" svc.example.net. 7200 IN HTTPSSVC 2 svc3.example.net. "alpn=h3 port=8003 esnikeys=\"ABC...\"" Jan _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
