[Dots] Benjamin Kaduk's Yes on draft-ietf-dots-server-discovery-13: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dots-server-discovery-13: 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-dots-server-discovery/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Pulling in some follow-up from the directorate review comments...

Section 3

   o  Resolving a DOTS server domain name offered by an upstream transit
      provider provisioned to a DOTS client into IP address(es) requires
      the use of the appropriate DNS resolvers; otherwise, resolving
      those names will fail.  The use of protocols such as DHCP does
      allow associating provisioned DOTS server domain names with a list
      of DNS servers to be used for name resolution.  Furthermore, DHCP
      allows directly provisioning IP addresses therefore avoiding the
      need for extra lookup delays.

I wonder if using "providing" rather than "provisioning" for at least the
last instance would be more clear.

   o  A resolution mechanism based on straightforward Naming Authority
      Pointer (S-NAPTR) resource records in the Domain Name System (DNS)
      (Section 6).

"Straightforward" needs to be capitalized here.

Section 4

   will support a local configuration.  More samples are discussed in
   Section 3:

nit: s/:/./

Section 5

   The list of the IP addresses returned by DHCP servers is typically
   used to feed the DOTS server selection procedure including when DOTS
   agents are provided with primary and backup IP addresses of their
   peer DOTS agents.  An example of DOTS server selection procedure is
   specified in Section 4.3 of [RFC8782].

The referenced section in 8782 is about the "happy eyeballs", i.e.,
picking between TCP/UDP and IPv4/IPv6 -- it doesn't really seem intended
to cover the case where you have to pick betwen different actual nodes.

I'm also not sure how the "primary and backup" is intended to work,
here.  Is the "provided with" referring to "by DHCP" or some out-of-band
configuration?

Section 8.1

   configured name.  If the DOTS agent is instructed to trust subdomains
   of the names in that list as well, a DOTS agent will also accept a
   DHCP-discovered name if the left-most label of the discovered name is
   matching a name in the pre-configured list.

If the agent is configured to trust subdomains of the configured list,
then in the case where that configuration is relevant for the attack,
the left-most label will be the (part of the) subdomain name, which is
explicitly not matching the pre-configured list -- the remaining bits
are what match.