Some of the questions need more granularity in the answers. e.g. "Do we care about the latency of A2DoT-enabled domains?"
We may care on average but with the expectation that the latency/overhead of the first few queries will be amortized over the future queries. On Fri, Nov 12, 2021 at 12:33 PM Petr Špaček <[email protected]> wrote: > > Hello dprive. > > I think that Ben Schwartz really hit nail on the head in his DSGLUE > presentation. > > I suggest we _really_ try to get a better idea about design constraints > first, and work out their implications and protocol from there. > > These are the crucial questions (copied and slightly modified from > https://datatracker.ietf.org/meeting/112/materials/slides-112-dprive-dsglue-01 > slide 5): > > * Can we slow down resolution of existing domains? > > * Do we care about the latency of A2DoT-enabled domains? > > * Do we care about A2DoT under non-A2DoT parents? > - i.e. protecting label N+1 after label N has leaked > - Can we require that non-A2DoT parents are signed? > > * Can we add new RR types to the glue/parent side? > > * Can the child atomically update NS/DS/glue RRSets together in the parent? > > * Can we add new digest types to the DS record? > > * Can we add DS RRs which do not constitute a valid DNSSEC-validation path? > > (The last point was added by me. It equals to "Will RRR ecosystem accept > DS records which are really not a DNSSEC-validable path?".) > > > Let us try an experiment: > > Could you please fill in yes/no in the following form, so we can quickly > see if there are totally different opinions or a rare agreement on some > of the points? > > https://docs.google.com/forms/d/e/1FAIpQLSdllOX_cKT8L7bl8_jhxeQPsg1Iqam_rnD6iVVl_R4mnxBN1A/viewform > > The form will close on: > Sunday 21th November 2021 23:59 UTC > > Maybe it will move us a bit forward if we see some (common) red lines in > the answers. Or maybe not, we'll see. > > P.S. Thank you Ben! > > -- > Petr Špaček > > _______________________________________________ > 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
