[dns-privacy] Erik Kline's Yes on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

Erik Kline via Datatracker <noreply@ietf.org> Wed, 05 May 2021 04:30 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dns-privacy@ietf.org
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 562B43A07F9; Tue, 4 May 2021 21:30:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Erik Kline via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, tjw.ietf@gmail.com, tjw.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.28.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Erik Kline <ek.ietf@gmail.com>
Message-ID: <162018903197.29167.15668839813774854378@ietfa.amsl.com>
Date: Tue, 04 May 2021 21:30:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/wZduiMJVbNuCOLmzxTiVaCdSyDU>
Subject: [dns-privacy] Erik Kline's Yes on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2021 04:30:32 -0000

Erik Kline has entered the following ballot position for
draft-ietf-dprive-xfr-over-tls-11: 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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


[[ questions ]]

[ general ]

* The appendix discussion of ALPN made me think that some ALPN
  recommendation might be worth mentioning.  The ALPN registry mentions
  "dot" and claims RFC 7858 as the reference.

  However, I wasn't able to find a reference to "dot" in 7858 (certainly
  not in the IANA section), nor in 8310 (which has only an empty IANA

  Now I'm wondering where the "dot" ALPN really came from.  Nevertheless,
  given this state of things, it best to continue to not say anything
  specific about ALPN use on these XoT connections?

  (I'm fully prepared to accept "yes" as an answer, but support others'
   ALPN concerns.)

[[ comments ]]

[ sections 8.4 and 12 ]

* Section 8.4 has MUST for two of three client authorization strategies,
  whereas section 12 has a lowercase "should" where these are listed for
  inclusion in an XoT policy.

  "Should" there be more agreement in use of requirements language?

[[ nits ]]

[ section 4 ]

* "The proposed mechanisms does not" -> "do not", or just "mechanism"?

[ section 6 ]

* "The term is used to encompasses" -> s/es//