Early Review of draft-ietf-dprive-unilateral-probing-07
review-ietf-dprive-unilateral-probing-07-secdir-early-salz-2023-06-09-00

The term "unilateral" makes me do a double-take. That's probably on me, but I
always think of it in a military context. So I am glad to see a short clear
definition early in the document, in the terminology section.  All of the
comments below are optional.

I am curious why Joey's affiliation is in the author's area but not the title
page.

Sec 2.1  I think before this there should be an intro sentence, like "There
were two main priorities for this work" or some such. Also the "--" should
probably be a colon.

Sec  2.2  Is the main point of the first paragraph to say that DoQ and DoT
don't address this type of deployment but leave it open for future docs?  If
so, maybe that's worth stating directly.

Sec 3 I think the ALPN the client "should" use (lowercase) is better than "may
use"

Sec 3.1 Merge first two paragraphs

Sec 3,2 A server *could* use a classic TLS server cert, right? Worth
mentioning? Worth proposing an eKU for DNS?

Sec 4.1 Is this 'happy eyeballs'?  If so, worth mentioning I think.

Sec 4.2, Merge the first two sentences: This document encourages the first
strategy, to minimize timeouts or accidental delays and does not describe the
other two." The remaining paragraphs contain some redundancy or otherwise could
benefit from editing. For example, consider not saying anything about NS
records.

Sec 4.3, combine the two paragraphs that appear just after the table.

Sec 4.4, combine first two paragraphs. Last paragraph seems out of place for
this doc.

Sec 4.5 In the table is "retain across reset" mean server restart? Are the last
two paragraphs duplicate of 4.4? If not, I don't appreciate the difference;
merge them into one.

Sec 4.6, ah, happy eyeballs comparison.  Consider a forward pointer from 4.1

Sec 4.6. Nice details.  Does this borrow from what SMTP opportunistic does? If
so, might be worth mentioning.

Sec 4.6.3.1 "store early data"  Is store the right word?  Send or stuff comes
to mind.

Sec 4.6.3.3  Do not send SNI.  Hmm.  Okay.  That's a big change from common web
tls deployments.  Worth calling out?

Sec 4.6.8.2, can you point to specific sections in the RFCs?  Okay if not.

Sec 4.6.10, there's no title for the section referenced in 7858? :)

Sec 5, "This document has no IANA considerations" is the boilerplate I've seen
most often.

Sec 6.2, A suggestion of what statistics to report would be useful. I also
think the section title isn't great.

Appendix A, is that to be removed when published?  Should A and B explicitly
say they are not normative?