Hi Murray, Thank you for your comments, thoughts below.
On 5/16/24 06:53, Murray Kucherawy via Datatracker wrote:
---------------------------------------------------------------------- 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.
I'd like to observe that while both you and Paul have reservations about what Section 2 says regarding RFC 8078, there are opposite conclusions: - Paul suggested to remove the deprecation of RFC 8078 Section 3, and rewrite Section 2 of this draft to say that the new method "provides more security [...], and are therefor RECOMMENDED in favour of the methods specified in [RFC8078]." - You suggested that the the right thing to say is that "new implementations MUST NOT do the old thing". So, the two of you have opposing views regarding whether to live systems are acceptable. As a middle ground, the WG had arrived at the current text, of deprecating the old methods [1]. This also has the advantage (over your proposal) that it encourages old implementations to move on, while your suggestion does not include this incentive. The authors don't have any specific positions, and will be happy to adjust text as needed / determined by the IESG. [1]: https://mailarchive.ietf.org/arch/msg/dnsop/Ld0lgCwJJQvgKIA9eBv8yEtgeoI/
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.
If you set out to perform bootstrapping, than using the algorithm on a bootstrapped zone is an error. The text says that if there is an error, one MUST abort. Whether something else needs to be done depends on circumstances, and (I believe) belongs into an operational BCP (as suggested in Benson's Intdir review, and indeed such a document is planned). That said, there's no problem rewording the text, and not calling this an "error", but a no-op situation. If you feel that the text should be changed, please let me know and we'll do it.
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.
The SHOULD means that delays are to be avoided once the trigger conditions are met (which "normally trigger" does not imply). Does this satisfy the concern? If the concern is still there, we'll change the wording. Best, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
