Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: dns-privacy <[e-mail]> On Behalf Of Alexander
> Mayrhofer
> Sent: Wednesday, July 7, 2021 8:36 AM
> To: Andrew Campling <[e-mail]>
> Cc: Brian Haberman <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] Re: [dns-privacy] How do we want to use draft-ietf-
> dprive-phase2-requirements?
> 
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content
> is safe.
> 
> Picking up on this (speaking as an editor of the draft). I don't have any issues
> with option #4 (dropping the draft), and it has expired some time ago
> anyways. However, if we need a space to document operational concerns
> around any specific solution (for example, to avoid repeating the same
> concerns for each new solution space document), then i think the document
> could provide a useful contribution to the WG. Also, i do remember that we
> initially mulled never progressing the draft to an RFC anyways, so it seems its
> current fate pretty much fits that original intent.
> 
> If we do want a space to collect "concerns", a document with "requirements"
> in its name would be slightly misleading, though - "design considerations" or
> similar would probably fit that purpose much better. We could also use a wiki
> page somewhere for that, but i think even an expired draft is a more stable
> resource, compared to a WG wiki page.
> 
> Some of these "design considerations" i've heard / can think of over the last
> years would be:
> 
> - Protocol should not require any probing by recursive servers
> - Protocol should require as little state as possible
> - Recursives would have a much larger set of open "upstream"
> connections than a stub resolver (obviously), so footprint of these sessions is
> critical
> - Auth servers would see a similar amount of open "downstream"
> connections, though that end is probably similar to what recursives see
> downstream - are there differences?
> - Quality / Level of authentication ("better than nothing" principle?)
> 
> So, if we go for option #4, would it make sense to collect those (and
> similar) considerations somewhere?

[SAH] I'd certainly like to see both design _and operational_ considerations captured somewhere, and it makes sense to do it in one place.

There's another expired draft that attempted to capture operational considerations:

https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/

It would be worth exploring it, too, if we see value in capturing this information.

Scott