Hi Wes and Warren, We have updated the reference entry for "[DS-IANA]” to reflect the direct registry name. Please review and let us know if any further updates are needed or if you approve the document in its current form. Once we receive approvals, we will ask IANA to update the notes in the registries to match the edited document.
—Files (please refresh)— Updated XML file: https://www.rfc-editor.org/authors/rfc9904.xml Updated output files: https://www.rfc-editor.org/authors/rfc9904.txt https://www.rfc-editor.org/authors/rfc9904.pdf https://www.rfc-editor.org/authors/rfc9904.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9904-auth48diff.html https://www.rfc-editor.org/authors/rfc9904-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9904-diff.html https://www.rfc-editor.org/authors/rfc9904-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9904 Best regards, Karen Moore RFC Production Center > On Nov 5, 2025, at 3:17 AM, Wes Hardaker <[email protected]> wrote: > > Karen Moore <[email protected]> writes: > >> 2) We note that in the Normative References section, [DNSKEY-IANA] >> lists the direct registry name and [DS-IANA] lists the top registry >> name. Should [DS-IANA] list the direct registry name for consistency? > > I think that is best yes. It had to be done for DNSKEY-IANA since there > are two sub-registries within that page and we needed to refer to only > the first. DS-IANA didn't need to be as specific, so we used the more > descriptive (IMHO) longer name. > > But, you're right that consistency is probably better. Thanks for the > suggestion and the switch. > -- > Wes Hardaker > Google > On Nov 4, 2025, at 1:57 PM, Karen Moore <[email protected]> wrote: > > Dear Warren and Wes, > > Thank you for your replies (and Wes, thank you for stopping by the RFC Editor > desk at IETF 124!). We have updated our files accordingly. We have an > additional clarification and question. > > 1) Thanks for the clarifications regarding Tables 2 and 3. The only changes > we made were to Table 2 - we updated values 17, 23, 252, and 254 to reflect > the mnemonic names. > > 2) We note that in the Normative References section, [DNSKEY-IANA] lists the > direct registry name and [DS-IANA] lists the top registry name. Should > [DS-IANA] list the direct registry name for consistency? > > --Files-- > Note that it may be necessary for you to refresh your browser to view the > most recent version. Please review the document carefully to ensure > satisfaction as we do not make changes once it has been published as an RFC. > We will await approvals from each author prior to moving forward with the > publication process. > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9904.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9904.txt > https://www.rfc-editor.org/authors/rfc9904.pdf > https://www.rfc-editor.org/authors/rfc9904.html > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9904-auth48diff.html > https://www.rfc-editor.org/authors/rfc9904-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9904-diff.html > https://www.rfc-editor.org/authors/rfc9904-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9904 > > Best regards, > > Karen Moore > RFC Production Center > > >> On Nov 4, 2025, at 8:02 AM, Wes Hardaker via auth48archive >> <[email protected]> wrote: >> >> Warren Kumari <[email protected]> writes: >> >> I'm following up with some additional comments but any items I didn't >> respond to I agreed with Warren (which was generally: good suggestions >> and thank you). >> >>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >>> the title) for >>> use on https://www.rfc-editor.org/search. >>> --> >>> >>> DNS, rollover, agility >> >> Again, add DNSSEC too please. >> >>> Also, please clarify "incremental update RFCs". Is the intended meaning >>> that future >>> extensions can be made under new, incremental RFCs that update this >>> document? >>> >>> TBD >> >> Yes, and since that's common terminology maybe just "future RFCs" >> instead and we'll just stop trying to add "incremental" as it's >> confusing and doesn't really help anyway. >> >>> 8) <!--[rfced] Section 3. Since there are multiple registries under the >>> "Domain Name System Security (DNSSEC) Algorithm Numbers" registry group, >>> we added the >>> registry name for clarity as shown below. >> [...] >>> Perhaps A: >>> Initial values for the use and implementation recommendation columns in >>> the "DNS >>> Security Algorithm Numbers" registry under the "Domain Name System >>> Security (DNSSEC) >>> Algorithm Numbers" registry group are shown in Table 2. >>> >>> Either is fine with me - whatever y'all and my co-author think…. >> >> I think A is a bit clearer IMHO. Thanks! >> >>> 10) <!--[rfced] Questions about Table 2 >>> >>> a) In Table 2, some of the values in the "Use for" and >>> "Implement for" columns are different than what is listed in "DNS >>> Security Algorithm >>> Numbers" registry (specifically, see numbers 5, 7, and 12). Should Table >>> 2 be updated >>> to match the IANA registry as shown below, or should the IANA registry be >>> updated to >>> match Table 2? >>> >>> The IANA Registry should be updated (which kicked this off); my co-author >>> and I will >>> discuss…. >> >> So these ended up becoming different because we added more columns in >> the long run than was originally specified. >> >>> b) In Table 2, numbers 17, 23, 253, and 254 use terms from the >>> Description column in >>> the registry whereas the rest of the numbers use terms from the >>> Mnemonic column. >> >> Agreed, we should be consistent and mnemonic values should be used. >> >>> 12) <!--[rfced] We note differences between Table 3 and the "Digest >>> Algorithms" >>> registry. Should this document be updated to match the registry as shown >>> below, or >>> should the registry be updated to match this document? >> >> So I believe that the confusion here is that: >> >> 1. this document defines the values at the time the RFC is to be >> published, but the other two related documents immediately change the >> values to more restrictive. Hence, for example, the MUST NOT values for >> GOST in the current table exist because IANA has already taken the >> actions defined in these algorithms. So in steps they: >> >> 1. took the values from this document (rfc8624-bis-13) and made columns >> for them. >> >> THEN >> >> 2. took the values from the must-not-gost document and applied the new >> values. >> >> Thus, the values in the original table are correct because they document >> what existed before any of the tables changed as a result of all our >> documents. So the history is properly preserved by leaving our values >> in the bis document the same, as it's the later must-not-gost and >> must-not-sha1 documents that create the new values that have already >> been placed into the document. >> >> Clear as mud? >> >> In other words: >> >>> Perhaps (to match the IANA registry): >>> >>> 0 Reserved MUST NOT | MUST NOT | MUST NOT | MUST NOT >>> >>> 3 GOST R >>> 34.11-94 MUST NOT | MUST NOT | MUST NOT | MUST NOT >> >> This is wrong, because those values come from a later-numbered RFC that >> changes the values to MUST NOT from the values in this table. >> >>> 15) <!-- [rfced] FYI: We have added an expansion for the following >>> abbreviation per >>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review this and each >>> expansion in >>> the document carefully to ensure correctness. >>> >>> DNS Public Key (DNSKEY) >>> --> >>> >>> Huh. Yes, that looks right — in my brain it is just "DNS Key", but RFC >>> 4034, etc show you >>> to be correct. >> >> Yep, DNSKEY is correct. thanks. >> >> >> -- >> Wes Hardaker >> Google >> >> -- >> auth48archive mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
