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

[Alexander Mayrhofer <[e-mail]>]

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?

best,
Alex

On Tue, Apr 27, 2021 at 11:25 PM Andrew Campling
<[e-mail]> wrote:
>
> On 26 April 2021 20:45, Brian Haberman wrote:
>
> > Does anyone else have an opinion on this?
>
> > On 4/19/21 5:13 PM, Brian Haberman wrote:
> >> All,
> >>      As was raised on the thread discussing suggestions for the
> >> requirements draft, there is some question on how the WG wants to use
> >> draft-ietf-dprive-phase2-requirements in progressing our
> >> recursive-to-authoritative privacy work item. The draft currently has
> >> one sub-section that describes requirements (5.1) and another section
> >> that describes optional features (5.2), albeit with 2119 SHOULDs.
> >>
> >>      My question to the WG is how do we want to use this draft? I see
> >> four possible approaches, but I am sure someone will point out others.
> >>
> >> 1. Strictly requirements - these would be MUST-level functions that
> >> the WG determines have to be supported by any solutions draft.
> >>
> >> 2. Strictly design considerations - these would be functional areas
> >> that the WG determines need to be considered, but not necessarily
> >> included, by any solutions draft.
> >>
> >> 3. Requirements & design considerations - This is generally where the
> >> current draft sits IMO.
> >>
> >> 4. Drop the draft and let the solutions flow.
> >>
> >> Let's discuss the focus of the draft and then we can determine what
> >> updates are needed/necessary.
> >>
> >> Regards,
> >> Brian
> >>
>
> Building on the Root Server Operators Statement on DNS Encryption, I think there would be benefit in gaining input from TLD operators to establish whether they are interested in adopting encryption, as well as any insight into deployment considerations, the relative attractiveness of potential solutions etc.  Developing solutions without sufficient understanding of the requirements and operational concerns of the intended beneficiaries risks wasting a lot of effort pursuing the wrong solutions to the wrong problems.  Capturing this information would seem to fit within a requirements document.
>
> Andrew
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy