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. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
