Re: [dns-privacy] Secdir early review of draft-ietf-dprive-unilateral-probing-07

I pointed out to Mr Salz that Alajuela is the location of the author in
question, not their employer.

He apologizes for his lack of Geography. (or he should)

tim

On Fri, Jun 9, 2023 at 4:20 PM Rich Salz via Datatracker <noreply@ietf.org>
wrote:

> Reviewer: Rich Salz
> Review result: Has Nits
>
> 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?
>
>
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>