Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-maintain-ds-03: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I support Jari's discuss - but it might be fine to just chat about the 7344 status change, not sure. But that said, I'm balloting yes, as this bootstrapping is definitely needed if DNSSEC is going to prosper. - please check and respond to the secdir review, [1] which overlaps a bit (but not totally) with my comments. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06685.html - 1.3: s/digiest/digest/ - 1.3: definition of RRR isn't clear (enough) - I think you want to define RRR to mean the current public DNS ecosystem maybe, but not sure if there's a subtlety somewhere in e.g. 3rd level and other domains. This might be clearer if you mention the PSL as a way to explain (not define) RRR. OTOH, you don't use RRR later at all, so you could just delete that term entirely and say a parent is typically an entity one above what's in the PSL, but can be lower down the naming hierarchy, e.g. within an enterprise. - section 2: calling operation 2 the "first one" is confusing, maybe re-order for clarity. Oh, and then you later mean "first one" == "operation 1" - so that does need fixing. Or just delete that para. - 2.1: I think you need to say that the acceptance policy for the very first use of CDS requires some out-of-band agreement, or is just done at the whim of the parent based on a possibly unknown policy. Ah, you do say that in section 3 - maybe consider re-doing the split into sections, e.g. make 2.1 be text at the start of 3. - section 3: I think it'd be good to call out the case where the domain is brand-new (i.e. never before existed) and has a CDS from the very first instant. That might fit in to 3.1, but I think it is worth a mention as a) it's a good goal to have (since it minimises the window without DNSSEC to zero) and so hopefully worth supporting and b) there's arguably no additional risk due to the CDS in this case, since the parent is also adding the delegation at the same time and c) it makes for better automation. That said, I'm not sure what s/w changes supporting that'd imply, but since a lot of parent registry code (APIs and such) are likely home-grown today, calling it out here might help ensure that parents don't all e.g. follow 3.3 or otherwise make DNSSEC-from-the-getgo hard or impossible. - 3.4: Do you need to say that the parent in this case ought monitor the child's DNS and react when the right challenge is visible? If it wasn't already done, this section might also be worth checking with some folks working on acme, as they have analysed such cases. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
