[dns-privacy] Erik Kline's No Objection on draft-ietf-dprive-unilateral-probing-12: (with COMMENT)

[Erik Kline via Datatracker <[e-mail]>]

Erik Kline has entered the following ballot position for
draft-ietf-dprive-unilateral-probing-12: 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-dprive-unilateral-probing/



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

# Internet AD comments for draft-ietf-dprive-unilateral-probing-12
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3.1

* A 3rd option for a pool operator is to use a load-balancer that forwards
  queries/connections on encrypted transports to only those members of the
  pool known (e.g. via monitoring) to support the given encrypted transport.

### S4.2

* There is no "port closed" ICMP message.  There is a Port Unreachable code
  under the Destination Unreachable type category.

* The IP addresses given are not "two A records" but rather the values that
  might appear in an A Resource Resource and AAAA Resource Record.

### S4.4

* The use of lowercase "must" for the ALPN strings seems a bit odd.

  Should this section say that the ALPN is a "MUST"?  It could perhaps be
  reworded to say something like "... and if an APLN is included it MUST be
  <the_thing>".

### S4.6.3 or S8

* I think a very important caveat here is when a node running its own
  recursive resolver has just joined a network and not yet completed any
  captive portal probes.  Initiating encrypted transport connections prior
  to satisfying the captive portal testing stage could have negative
  consequences (especially given the MUST in S4.6.3.4).

  Whether the state of the captive portal check(s) can be known by the
  recursive resolver function or not is an implementation-specific matter.

  Yes, this really only applies to recursive resolvers running on mobile
  devices, but some devices can actually do this.