On Sat, Apr 12, 2014 at 3:28 AM, Patrik Fältström <p...@frobbit.se> wrote: > No, I want B. That CDS and CDNSKEY is staying in the zone.
Doh! Yes. Sorry, when I resent this with the subject added I forgot which order I'd listed the two options - I'd though A was B and B was A. Unless we hear objections I'm planning on doing what Patrik and Matthijs suggested, option ***B***. Gods I suck at this. W > > Patrik > > On 12 apr 2014, at 00:11, Warren Kumari <war...@kumari.net> wrote: > >> [ Apologies all - I initially sent this with no subject line. >> Resending. Hopefully this makes things clearer... Also, unless we hear >> strong objections I'm planning on doing what Patrik and Matthijs >> suggested, option A ] >> >> >> On Fri, Apr 11, 2014 at 5:12 PM, Warren Kumari <war...@kumari.net> wrote: >>> Hi there all, >>> >>> At the moment this document says that the child SHOULD remove the >>> CDS/CDNSKEY record once the parent has consumed / acted on it (this >>> behavior was requested by someone -- unfortunately I cannot remember >>> whom). >>> >>> I *think* that I'm hearing that folk would prefer that the child >>> SHOULD leave it in, or, less strongly MAY remove it. >>> >>> 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. >>> >>> Can folk please let us know if they would prefer: >>> A: The child SHOULD remove the CDS/CDNSKEY RR from the zone once the >>> parent has published it (currently documented behavior) or >>> >>> B: The child SHOULD NOT remove the CDS/CDNSKEY RR (will require a >>> small edit to the doc) >>> >>> My personal preference is for B - it seems more elegant, but (as >>> always) we'll do whatever the WG wants. >>> >>> W >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
