Murray Kucherawy has entered the following ballot position for draft-ietf-dnsop-dnssec-bootstrapping-09: No Objection
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Paul's DISCUSS especially with respect to Section 2. It's peculiar to say a past process is obsolete and you SHOULD NOT use it, because then continuing to use it is technically still supported by this document. Don't we want to say that new implementations MUST NOT do the old thing and MUST do the new thing? Using SHOULD effectively leaves two systems "live" rather than one. This may be some ignorance talking, but: In Section 4.2, if it's found that the child is already securely delegated, should this be an error, or just treat the whole thing like a no-op? Redundant verification returning an error seems an odd choice, but I'm probably missing some context. I think the SHOULD in Section 4.3 should really be more like "Parental agents normally trigger ...". I'm not clear on why this is a normative SHOULD. What if I don't do it in those circumstances, but possibly in others? I'm still compliant with a SHOULD then, right? Why might I do it in other situations? The text doesn't say. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
