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

From: Erik Kline via Datatracker <[email-masked]>
Date: Tue, 04 May 2021 21:30:32 -0700

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:
https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/

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

[[ 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
  section).

  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//

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 6 May 2021 11:33:35 +0100

> On 5 May 2021, at 05:30, Erik Kline via Datatracker <[email-masked]> wrote:
> 

Hi Erik, 

You’ll probably have seen the suggestion to Ben/Martin relating to adding the use of the ALPN? 

I agree that the reference to RFC7858 in the IANA section is incorrect. To the best of my knowledge that registration came as the result of a private request by Jon Reed in late 2019. And to my knowledge there is very little use of it in stub to recursive DoT today. 

Since those registrations are subject to Expert Review I’m not 100% sure of the precise way to get that entry updated but I would certainly like to see that happen. 

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

Thanks for catching this. I think the section 12 language pre-dates the current 8.4 requirements (early versions had SHOULDs there) so I agree: s/should/MUST/ in section 12. 

> 
> 
> [[ nits ]]
> 
> [ section 4 ]
> 
> * "The proposed mechanisms does not" -> "do not", or just "mechanism”?

just ‘mechanism’ 

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

Thanks!

Sara.

---

From: Erik Kline <[email-masked]>
Date: Thu, 6 May 2021 22:39:30 -0700

Sara,

Thanks very much!

(After listening to Allison's talk at DNS OARC 35 tonight, I wonder if
there should be an appendix section with the pronunciation guideline that
"XoT" is pronounced "zot".  ;-) )