Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-svcb-https-08: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Kyle Rose for the security feedback in the TSVART review. ** Section 2.1. Per the ABNF (with the caveat that my manual review of such syntax might be rusty): -- What role does “value = *OCTET” play in the specification of SvcParams? It doesn’t appear to be used or explained. -- Should a top-level ‘SvcParams’ rule be defined (i.e., define the formal syntax of the entire parameter which is a list of SvcParam)? -- (Editorial) To make it clear that “char-string” is defined in Appendix A, it would be helpful to: OLD SvcParamValue = char-string NEW SvcParamValue = char-string ; per Appendix A ** Section 3.1. Recommend explicit saying which connection should be abandoned – s/the client SHOULD abandon the connection attempt/the client SHOULD abandon the connection attempt to the target service/ ** Section 7.4. Unpacking the first paragraph for easier commentary: (a) The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to reach the service. (b) If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints. (c) Otherwise, clients SHOULD perform A and/or AAAA queries for TargetName as in Section 3, and clients SHOULD use the IP address in those responses for future connections. (a) seems to be saying that the value of the SrcParamValue is going to return an IP address associated with a TargetName. (b) seems to be saying that if the client already has an IP address for the TargetName in the cache, then ignore the hints. Per (c), why would A/AAAA queries need to be performed to resolve TargetName? Isn’t the hint the associated IP address? ** Section 9.3. Editorial. s/the the/the/ ** Section 10. Editorial. s/the value of the parameter is an ECHConfigList [ECH]/ the value of the parameter is an ECHConfigList per Section 4 of [ECH] ** Section 10. Editorial. s/ProtocolNameList in Section 7.1/ ProtocolNameList in Section 7.1.2/ ** Section 10.2. s/smaller SvcPriority/lower SvcPriority value/ ** Section A.1 Per the ABNF: -- What role does “item” rule play? It’s not referenced or explained. (see below) -- It would be useful to state somewhere which ABNF rule corresponds to which form of the list. Perhaps something like: OLD For implementations that allow "," and "\" in item values, the following escaping syntax applies: NEW For implementations that allow "," and "\" in item values, the ‘comma-separated’ rule for the escaping syntax applies. For those that do not required escaping, the ‘item’ syntax rule applies. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
