> On Apr 6, 2016, at 3:50 PM, Shane Kerr <sh...@time-travellers.org> wrote: > > Hello, > > RFC 7344 left out the problems of deletion and addition because they > were scary. > > I think that the draft-ietf-dnsop-maintain-ds document is quite clear > about deleting DS records, and I think it makes sense. > > However, in the case of adding DS records, to me the document is less of > a specification than a discussion about possible approaches to the > difficult issue of when to accept the CDS RRset. This discussion is not > necessarily a problem, because that's all we have today.
Shane thank you for starting this discussion, We could have written “After observing CDS records for 15 days or 2 resigning cycles which ever is longer, accept them and upload DS” Is that better ? It sets expectations But there is the case Parent happens to know the operator of the domain and via out of band knowledge can be sure the domain is operated a that party. In this case the upload should not suffer any delay. So yes I agree having well defined policies is a good idea, but we need help and guidance in making the text better and figure out 2 or 3 reasonable policies, to recommend to people > The reasons that I questioned whether this draft should result in a > standards-track document is because of the ambiguous and vague way that > DNSSEC is enabled with CDS/CDNSKEY. > I get your point, and kind of agee with it (have not asked my co-editor what he thinks) > I do think that RFC 7344 should be standards track. Great, > > To be clear, I'm not strongly opposed to standards track, but I am not > sure what it means to have a standards track document that doesn't > actually tell me how to inter-operate or even really how to do anything > concrete. (This might just be my IETF ignorance, I admit!) > I think having this on standards track is better than not. If there is bad advise in the document we can always replace it with better RFC. Olafur _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop