> On Jun 17, 2020, at 5:10 AM, libor.peltan <libor.pel...@nic.cz> wrote: > > Hi all, > > i'm a developer of Knot DNS authoritative server. I have some comments on the > SVCB draft and some suggestions for improvements. Just consider my thoughts > and then do whatever is best. > > (1) The format of SVCB (and HTTPS) RR is too complicated, especially for > parsing presentation format to wireformat and back, including consistency > checks. Perhaps instead of > > www 3600 IN HTTPS 1 . alpn=h2 port=8443 > > It could be > > www 3600 IN HTTPS 1 . alpn h2 > 1 . port 8443 > > Which gives slightly bigger RRSet wireformat, but not by much.
I find this format suggestion to be far more confusing to read, since these really are key-value pairs, and the SvcDomainName and the SvcDomainPriority fields are shared across the different key-value pairs. What specifically is too hard to parse in the draft’s format? Is that something that more clarifying examples can help with instead? Tommy > > (2) Paragraph 2.2 explicitly requires that SvcDomainName must not be > compressed. Is there a reason? Especially when the response packets are large > (and I expect that for SVCB they will), any compression helps. > > (3) Paragraph 2.5 contradicts itself: "SvcDomainName MUST be the name of a > domain that has SVCB, AAAA, or A records" versus "SvcDomainName MAY be the > owner of a CNAME record". What is the meaning here? > > (4) Let's assume that CNAME is allowed under SvcDomainName. Paragraph 4.1 is > too vague and I don't see what an authoritative (not recursive!) server shall > answer in situation SVCB->CNAME->A (all in-bailiwick). Shall the CNAME and A > be added to additional section? For comparison, in situation MX->CNAME->A we > don't bother since this situation is forbidden (see RFC 2181). > > (5) Wouldn't one octet for priority field be enough? > > (6) There are not enough examples in the document. There are many variants of > SVCB records, the formal ABNF description is difficult to read, and it would > also illustrate what kind of services those records are designed to handle. > > Best regards and thanks for your effort, > > Libor Peltan > CZ.NIC > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
