All The call for adoption period for this draft wrapped up this morning. While we saw several strong comments and issues raised, we also saw the working group wishing to adopt this work and working on it. We consider this passed. Thanks all, and we will work with the authors to itemize the list of larger issues
thanks tim On Wed, Jun 7, 2023 at 11:52 AM Tim Wicinski <[email protected]> wrote: > > 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/ > > 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 > >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
