+1 for adoption, I'm willing to review. Thanks, Nils
> > All, > > We've had this document in DNSOP for a bit and Peter has presented > three different meetings. When I went back and looked at the minutes, > the feedback was good. But when the chairs and Warren discussed it, > we had confused ourselves on this document, which is our bad. We > decided to stop confusing ourselves and let the working group help us > out. > > What I did was to pull the comments on this document from the minutes > of the meetings and include them below to make it easier to remember > what was said. > > > This starts a Call for Adoption for draft-thomassen-dnsop-cds- > consistency > > The draft is available here: > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/ > < > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/ > > > > Please review this draft to see if you think it is suitable for > adoption > by DNSOP, and send any comments to the list, clearly stating your > view. > > Please also indicate if you are willing to contribute text, review, > etc. > > This call for adoption ends: 21 June 2023 > > Thanks, > tim wicinski > For DNSOP co-chairs > > Minutes from past meetings on "Consistency for CDS/CDNSKEY and CSYNC > is Mandatory" > > ---- > > 114 > Mark: CDS records are no different than any others > One NS might be down, which would stop the > Peter: This is telling the parent how to act when faced > with > inconsistent information > Viktor: There might be hidden masters > Don't want to get stuck > Peter: Wording could be changed to allow servers down > Ben: There is a missing time constant > When do I recheck if I get an inconsistent set? > Peter: 7344 doesn't put any time limit > Ben: Should suggest some time to retry when there is an > inconstancy > > 115 > Wes: Supports this > Likes mandating checking everywhere > Ralf: Supports this > Can't ask "all" servers in anycast > What if you don't get a response > Peter: Ask each provider > Is willing to add in wording about non responses > Paul Wouters: This wasn't in CSYNC, our bug > Viktor: Concern was hidden masters and nameservers that are > gone > and are never going to come back > > > 116 > Viktor: Corner case: if someone is moving to a host that > doesn't > do DNSSEC > Peter: Could add a way to turn off DNSSEC on transfer > Johan Stenstram: Breaks the logic that "if it is signed, it is > good" > Doesn't like "if this is really important" > Let's not go there > Authoritative servers are proxies for the registrant > Out of sync is reflection on the registrant: business > issues > Wes: CSYNC was for keeping DNS up and running > CSYNC can't fix the business problems > Peter: Agrees that one signature should be OK > Other parts of the spec also suggest asking multiple places -- deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
