Magnus Nyström via Datatracker <nore...@ietf.org> writes: Hi Magnus,
Thanks for the detailed review. You raised some good points. See my inline responses below: > 1. Section 2 states "Domain Security Algorithm Numbers" as a new > registry. However, the texto nly refers to a "DNS System Algorithm > Numbers" registry. Are these intended to be the same? [...] > 5. Section 3. Title name for registry does not match the registry's > name in Section 2's table. So the full length title of the page [1] is: "Domain Name System Security (DNSSEC) Algorithm Numbers" but the registry we're modifying within it is: "DNS Security Algorithm Numbers" So we really mean the second one, and I'll change the table. Thanks for the good catch. > 2. Section 2 states "Adding a new entry to the "DNS System Algorithm > Numbers" registry ... is via the "Specification Required" policy" - > would it not be clearer to state: "Adding a new entry to the "DNS > System Algorithm Numbers" registry ... SHALL follow the > "Specification Required" policy" > 3. Section 2. Same as for item 2 but for the Digest paragraph. That's fine with me, thanks! Fixed. > 4. Also in Section 2, I do not understand "Use for columns was also > set to the same values from [RFC8624], as there is no existing > documented values and general interpretation of the registries to > date indicate they should be the same, although may differ in the > future" - besides the grammar errors here, how can you set to the > "same" values if there is [sic] no existing documented values? I do get your confusion. The point was that we had to set them to something, and since the general belief now was the values should be the same as the implementation field we set them to be identical. How about this: The following sections state the initial values to be populated into these rows. The "Implement for" column values are transcribed from [RFC8624]. The "Use for" columns were also set to the same values since the general interpretation to date indicates they have been treated as values for both "implementation" and "use". We note that the values for "Implement for" and "Use for" may diverge in the future. > 6. Section 5. Second paragraph seems superfluous as this document is > not about management of keys, systems, etc. So this was inserted as the root cause of why the document is being written. It is about the management of algorithms, eg. I don't think we should remove it at this point since it came out of multiple discussions within dnsop, and I doubt you think it truly harms the document. > 7. Section 6. "Therefore, algorithm deprecation must be done very > slowly and only after careful consideration and measurement of its > use" - better to write "Therefore, algorithm deprecation must be > done only after careful consideration" - if an algorithm is > demonstrably broken, then it is worse to allow its continued use > than being explicit about the zone not being secure. "Very slowly" > is also indeterminate. I think that's a good point, so I changed it to "Therefore, algorithm deprecation must be done only after careful consideration and ideally slowly when possible." which is close to what you wanted but still includes a reference to "slowly". -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
