At Mon, 14 Apr 2014 15:10:56 +0200, Matthijs Mekking <matth...@nlnetlabs.nl> wrote:
> > C: The child MAY remove the CDS/CDNSKEY RR from the zone once the > > parent has published it, and this is how to do that safely. > > > > So I'm ok if they stay in, but we need a way to get them out for the > > ones that need that. > > I actually am for C too, mainly because the parental agent has to deal > with this scenario anyway. As long as this is not the default scenario, > it is fine with me. Hence MAY sounds reasonable to me. > > The rules can be: > > Wait until the new CDS and/or CDNSKEY RRsets have propagated to all the > child name servers. Then, for each parent name server, query the DS > RRset and make sure it is in sync with the CDS and/or CDNSKEY RRset. > Only then it is safe to remove the CDS and/or CDNSKEY RRsets again. I'm fine with option C (but not "RR", but "RRset"), too, but probably more important, I'd like the draft to explain why one might want to remove the CDS/CDNSKEY RRsets. Warren's explanation makes sense to me: At Fri, 11 Apr 2014 18:11:39 -0400, Warren Kumari <war...@kumari.net> wrote: > > This (IMO) makes the doc and the child's life simpler, but potentially > > makes a bit more work for the parent -- currently most of the > > time the parent will see no CDS, and so will go back to sleep. If the > > child leaves them around, the parent will need to check them against > > what is currently published and take action if they differ. (except the "and take action if they differ" part; we can't avoid this overhead by removing the CDS/CDNSKEY RRsets when there is no change) but the rationale is not obvious, at least to me. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
