Dear all, Thanks for your patience as I was on vacations when the publication of this I-D was requested. As the DNSOP responsible AD is also an author, I was selected as the acting responsible AD for this I-D. Hence, here are some comments that I want to be addressed (either by replying to me or by a revised I-D) before proceeding to the IETF Last Call.
1. The shepherd write-up is very terse , so far so good, but does not include a justification for the intended status (PS is the correct one of course) or whether cited authors agree to be authors 2. The id-nits tool indicates several issues to be fixed, notably fixing the the update meta-data tag 3. Abstract, is there a missing “and” in ` This is done both to allow the list to be more easily updated, to allow the list to be more easily referenced` 4. Section 1.1, suggest adding a reference to the IANA *registries* and not *tables* in addition to citing the names of the registries 5. Section 1.1, to be honest, I have no clue what is meant by ` the risk of algorithm compromise` ...or do you mean a vulnerability discovered in a crypto algo ? 6. Section 1.1 s/ be less secure *then* originally thought/ be less secure *than* originally thought/ and s/ In general it/ In general*,* it/ 7. Section 1.1 s/ which algorithms should be deploy / which algorithms should be deploy*ed* / ? Even if not a SHOULD, readers will welcome to read what are the consequences of bypassing this should or when the should can be bypassed. 8. Section 1.2, as “deprecated” is rather vague in the IETF context, suggest explaining what is meant by deprecated in this document 9. Section 1.3 I like your last paragraph ;-) 10. Section 2, I think that the right IANA terms are registries/fields and not tables/columns (same comments at multiple places) 11. Section 2, suggest using “MAY” when it is a value to clearly separate from the BCP14 MAY 12. Section 2, I am completely unclear about the justification of a BCP14 MAY in `MAY requires a Standards Action`. I think that some justification for the MAY will be welcome/ 13. Section 4, where is “*” definition in table 3 ? 14. Sections 3 and 4, suggest splitting the first paragraph in two sentences as the audience is different: IANA then operators. 15. Section 5 s/ Thus the security/ Thus*,* the security/ 16. Sections 2 & 7, I find it strange to find IANA policies and values in section 2 and having a reference to this section 2 in the actual IANA considerations (section 7). This would require some heavy text change, but I sincerely believe that this will be clearer. 17. Sections 7.1 and 7.2 s/ These values should be populated / These values must be populated / and s/ should match / must match / 18. Section 7.2 I think it is either ` Update the registration policy for the [DS-IANA<http://www.iana.org/assignments/ds-rr-types>] registry to match the text describing update requirements above. 19. ` (unclear what the “above” means here) or ` the registration policy for the [DS-IANA<http://www.iana.org/assignments/ds-rr-types>] registry should match the text in describing the requirements in Section 2 of this document` 20. Section 8 s/ The content*s* of this document was heavily discussed/ The content of this document was heavily discussed/ 21. Section 8 s/we/the authors/ ? 22. References RFC 9364 seems more informative than normative to me, less assertive though on RFC 8624 as it is borderline to be informative only Once the above points are addressed, then I will proceed with the publication of this important document. I will make sure that the 3 IETF Last Calls and the IESG ballots indicate the right reading order among the 3 Warren & Wes I-Ds ;-), i.e., start with this one (and not ending by this one as I did...). Regards, -éric
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
