Hi Wes, see below. On Mon, Mar 17, 2025 at 12:04 AM Wes Hardaker <wjh...@hardakers.net> wrote:
> 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. > How about: 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 are set to the same values as the "implement for" 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. > OK. It was a minor comment anyway. > > > 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". > I think w/o "slowly" is better since "careful consideration" covers that and "slowly" is again not defined, and who decides "when possible"? /M > > -- > Wes Hardaker > USC/ISI > -- -- Magnus
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
