Hello WG, On 3/18/21 9:53 PM, Tim Wicinski wrote: > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, please > speak out with your reasons.
I re-read the draft-03 last week and just had a look at the diff to -04. There are two things I find unclear about the current draft, and that is the handling of automatic mandatory keys. Especially the rules on how to verify the record is consistent (section 7). The draft mentions The SvcParamKey "mandatory" is used to indicate any mandatory keys for this RR, in addition to any automatically mandatory keys that are present. and This SvcParamKey is always automatically mandatory, and MUST NOT appear in its own value-list. Other automatically mandatory keys SHOULD NOT appear in the list either. (Including them wastes space and otherwise has no effect.) This means an HTTPS record MUST have a port and a no-default-alpn SVCParam in both the presentation and wire format, without the keys being present in the mandatory key? It would be good to add an example or some clarification here. The second question arises for the "default set" of ALPNs. Section 6.1 says Each scheme that uses this SvcParamKey defines a "default set" of supported ALPNs, which SHOULD NOT be empty. To determine the set of protocol suites supported by an endpoint (the "SVCB ALPN set"), the client adds the default set to the list of "alpn-id"s unless the "no- default-alpn" SvcParamKey is present. The presence of an ALPN protocol in the SVCB ALPN set indicates that this service endpoint, described by TargetName and the other parameters (e.g. "port") offers service with the protocol suite associated with this ALPN protocol. The HTTPS record mentions that no-default-alpn is automatically mandatory, but also that alpn has a default value. Which would mean that that the default alpn is never used? Or is mandatory a hint to the end-client that it MUST understand the keys mentioned in order to use the RR? If that is the case, a few words to that effect would be good. I hope the rambling above makes the question clear. Cheers, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
