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
