On Tue, Feb 18, 2025 at 6:55 AM, Eric Vyncke <
[email protected]> wrote:
>
>
> Dear all,
>
>
>
> Thanks for your patience as I was on vacations when the publication of
> this I-D was requested.
>
No worries, and thanks.
Apologies for my mail client having renumbered the ordered list — it thinks
it was being helpful….
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
>
>
Thanks; done.
> 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`
>
>
Thanks; done.
> 3. Section 1.1, suggest adding a reference to the IANA **registries**
> and not **tables** in addition to citing the names of the registries
>
>
Done.
I spent some time looking into the correct terminology and explored a run
rabbit-hole. We have rewritten it as:
The columns added to the IANA "DNS Security Algorithm Numbers"
[DNSKEY-IANA] and "DNSSEC Delegation Signer (DS) Resource Record (RR)
Type Digest Algorithms" [DS-IANA] registries target DNSSEC operators
and implementers.
(technically "DNS Security Algorithm Numbers" seems to be a subregistry of
the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry, but
the IANA guidance is that "You should almost always use the term "registry"
to refer to a table or collection of assignments made for a common
identifier type").
>
> 4. 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 ?
>
>
Thank you, how is:
"Implementations need to be conservative in the selection of
algorithms they implement in order to minimize both code complexity
and the cryptographic attack surface."
> 5. Section 1.1 s/ be less secure *then* originally thought/ be less
> secure *than* originally thought/ and s/ In general it/ In general*,* it/
>
>
Doh! Done. Schooled by a non-native English speaker :-P
> 6. Section 1.1 s/ which algorithms should be deploy / which algorithms
> should be deploy*ed* / ?
>
>
Thanks; Done!
> 7. 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 ;-)
>
>
Yay!
> 10. Section 2, I think that the right IANA terms are registries/fields
> and not tables/columns (same comments at multiple places)
>
> It looks like you are technically correct ("The best kind of correct") for
the tables vs registries bit, but RFC8126 - "Guidelines for Writing an IANA
Considerations Section in RFCs"
<https://datatracker.ietf.org/doc/rfc8126/> seems
to say that "column" is the correct term for, er, well, a column…..
So I s/table/registry/, but not s/column/field/.
> 11. Section 2, suggest using “MAY” when it is a value to clearly
> separate from the BCP14 MAY
>
> Done.
>
> 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/
>
>
Thank you, we have added justification to the draft.
> 12. Section 4, where is “*” definition in table 3 ?
>
>
That is defined in the existing registry (
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml),
and says:
"* There has been no determination of standardization of the use of this
algorithm with Transaction Security. "
> 14. Sections 3 and 4, suggest splitting the first paragraph in two
> sentences as the audience is different: IANA then operators.
>
>
Done, thanks.
> 15. Section 5 s/ Thus the security/ Thus*,* the security/
>
>
Thanks, done.
> 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.
>
>
Thank you; we have discussed this with the IANA, and they are OK with it.
Basically, the entire document is all about updating IANA information, and
so the IANA considerations section just points at the rest of the document…
While we *could* reorganize the whole document, I think that it would
actually end up confusing.
> 17. Sections 7.1 and 7.2 s/ These values should be populated / These
> values must be populated / and s/ should match / must match /
>
>
Thanks, Done.
> 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`
>
>
Wow, good catch. We have fixed these…
> 20. Section 8 s/ The content*s* of this document was heavily
> discussed/ The content of this document was heavily discussed/
>
>
Thank you, done/
>
> 21. Section 8 s/we/the authors/ ?
>
>
Thank you, done.
> 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
>
>
Thank you, done for RFC 9364.
I left RFC 8624 as Normative, as this is what we are Update'ing — I agree
that once this is published you probably don't need to read it, but I've
always used the "If I were stuck on a desert island, and needed to
understand this document would having the other document be useful? If so,
I make it Normative…" ¯\_(ツ)_/¯
>
>
>
>
> 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...).
>
Awesome, thank you sir…
Warren and Wes.
>
>
> Regards,
>
>
>
> -éric
>
>
>
>
>
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
>
>
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
