Adam Roach has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: Yes
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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. It seems a very useful extension to IKEv2. I have a handful of minor and editorial comments that you may want to consider addressing. --------------------------------------------------------------------------- Please expand "IKEv2" in the title and abstract. See https://www.rfc-editor.org/materials/abbrev.expansion.txt for details. --------------------------------------------------------------------------- §2.1: > To indicate support for Split DNS, an initiator includes one more > INTERNAL_DNS_DOMAIN attributes as defined in Section 3 as part of the > CFG_REQUEST payload. I can't parse this. Is it mean to say "...one or more..."? Or is "attributes" supposed to be "attribute"? --------------------------------------------------------------------------- §2.1: > includes an INTERNAL_DNSSEC_TA attribute, but does not inclue an Nit: "include" --------------------------------------------------------------------------- §2.1: > An initiator MAY convey its current DNSSEC trust anchors for the > domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does > not wish to convey this information, it MUST use a length of 0. As an implementor, I would have no idea whether this was something I wanted to include. If it is configurable, then I would have no idea as an operator whether how to set such configuration. Could we add some guidance here about when implementations and/or operators might want to send this, and when they might not? --------------------------------------------------------------------------- §2.4.1: > The responder replies with two DNS server addresses, and two internal > domains, "example.com" and "city.other.com". The domain "other.com" appears to be in active use by an organization known as "Other Entertainment." Please consider using an example domain as described in RFC 2606 section 2 or 3. --------------------------------------------------------------------------- §2.4.2: > In this example, the initiator has no existing DNSSEC trust anchors > would the requested domain. the "example.com" dommain has DNSSEC Nit: "...domain. The..." --------------------------------------------------------------------------- §4: > For example, if the INTERNAL_DNS_DOMAIN attribute > specifies "example.com", then "example.com", "www.example.com" and > "mail.eng.example.com" MUST be resolved using the internal DNS > resolver(s), but "anotherexample.com" and "ample.com" SHOULD NOT be > resolved using the internal resolver and SHOULD use the system's > external DNS resolver(s). The domain "anotherexample.com" is in use by a personal web site. The domain "ample.com" is registered anonymously through Amazon.com. For this example that needs to show a domain whose name is a subset of the indicated domain, please consider using an example domain as described in RFC 2602 section 2. --------------------------------------------------------------------------- §5: > DNS records can be used to publish specific records containing trust > anchors for applications. The most common record type is the TLSA > record specified in [RFC6698]. This DNS record type publishes which > CA certificate or EE certificate to expect for a certain host name. Please expand "CA" and "EE". --------------------------------------------------------------------------- §5: > In most deployment scenario's, the IKE client has an expectation that Nit: "scenarios" _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
