[IPsec] Adam Roach's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT)

[Adam Roach <[e-mail]>]

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"