> -----Original Message----- > From: dns-privacy <[email protected]> On Behalf Of Alexander > Mayrhofer > Sent: Wednesday, July 7, 2021 8:36 AM > To: Andrew Campling <[email protected]> > Cc: Brian Haberman <[email protected]>; [email protected] > 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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
