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
<[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
