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]
