Dear Wes and Warren, IANA has completed the updates to the registries. We will now move this document forward in the publication process along with RFCs-to-be 9905 and 9906.
Thank you for your time and for working closely with us on all of these documents during AUTH48! Best regards, Karen Moore RFC Production Center > On Nov 7, 2025, at 12:11 PM, Karen Moore <[email protected]> wrote: > > Hi Warren, > > We have noted your approval on the AUTH48 status page > (https://www.rfc-editor.org/auth48/rfc9904). > > We will ask IANA to update their registries accordingly, and we will inform > you when the actions are complete. > > Best regards, > > Karen Moore > RFC Production Center > > >> On Nov 7, 2025, at 7:40 AM, Warren Kumari <[email protected]> wrote: >> >> Warren approves of all 3 documents in [C544]: >> draft-ietf-dnsop-rfc8624-bis-13.txt >> draft-ietf-dnsop-must-not-sha1-10.txt >> draft-ietf-dnsop-must-not-ecc-gost-07.txt >> >> Thank you very much! >> W >> >> >> On Wed, Nov 05, 2025 at 8:19 PM, Karen Moore <[email protected]> >> wrote: >> Hi Wes, >> We have noted your approval on the AUTH48 status page >> (https://www.rfc-editor.org/auth48/rfc9904). We now require Warren’s >> approval prior to moving forward with publication. >> Thank you! >> Karen Moore >> RFC Production Center >> On Nov 5, 2025, at 2:34 PM, Wes Hardaker <[email protected]> wrote: >> Karen Moore <[email protected]> writes: >> 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. >> Thank you. I think with that final change we're good. >> -- >> Wes Hardaker >> Google >> On Nov 5, 2025, at 11:30 AM, Karen Moore <[email protected]> >> wrote: >> 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]
