Reviewer: Patrick Mevzek Review result: Ready with Nits I have been selected as the DNS Directorate reviewer for this draft. The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the ADs. For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir There are clear and direct references to various DNS RFCs and currently active IDs and this draft is not in any major conflict with the wider DNS space. At the IETF process level, which I don't master, because of last note in §4, shouldn't that document explicitly say it updates RFC8598? I do have the following nits or questions from a client implementor point of view to report, which may be caused by my own very superficial knowledge of IKE, so feel free to ignore as irrelevant: - §3.1 "Length (2 octets, unsigned integer) - Length of the data in octets." It is explained further how it is computed, but just this sentence alone is unclear for someone implementing it as not stating length of which part of the content (as the length field is kind of "in the middle" of the content itself) In §3.2, there is "Length (2 octets, unsigned integer) - Length of the data in octets." as well, with then no explanation on which data to consider for the length. "Authentication Domain Name (variable) - A fully qualified domain name of the encrypted DNS resolver following the syntax defined in [RFC5890]." Maybe specify which part of RFC5890? But I agree not finding myself there a single section clearly for that point, nor is the DNS terminology RFC providing a single definition. - §3.2 "List of Hash Algorithm Identifiers (variable) - Specifies a list of 16-bit hash algorithm identifiers that are supported by the encrypted DNS client." Is order of items in the list relevant or not? "Note that SHA2-256 is mandatory to implement." SHA2-256 is only defined later in the document, at section 5 with: "Implementations MUST support SHA2-256 [RFC6234]." So the reference might need to be moved to its first appearance, from section 5 to 3.2 Also, I don't know if it is customary from elsewhere, but RFC6234 does not talk at all about SHA2-256 only about SHA256 or SHA-256, no "SHA2". So maybe use the same moniker? Same for other lengths, including in all examples at end. I see that https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#hash-algorithms references RFC7427 instead, which does use SHA2-256 terminology, so maybe better to reference RFC7427 instead of RFC6234 above? - §A.1 "For split-tunnel VPN configurations, the endpoint uses the Enterprise-provided encrypted DNS resolver to resolve internal-only domain names." Maybe add that the endpoint knows which domains are internal-only in that case due to the INTERNAL_DNS_DOMAIN attribute? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
