Hi Karen, Apologies for the delay; this has been completed:
https://www.iana.org/assignments/dns-sec-alg-numbers/ DNS Security Algorithm Numbers ... Note Adding a new entry to the "DNS Security Algorithm Numbers” registry with a recommended value of "MAY" in the "Use for DNSSEC Signing", "Use for DNSSEC Validation", "Implement for DNSSEC Signing", or "Implement for DNSSEC Validation" columns will be subject to the Specification Required policy as defined in [RFC8126] in order to promote continued evolution of DNSSEC algorithms and DNSSEC agility. New entries added through the Specification Required process will have the value of "MAY” for all columns. Adding a new entry to, or changing an existing value in, the “DNS Security Algorithm Numbers" registry that has any value other than "MAY" in the "Use for DNSSEC Signing", "Use for DNSSEC Validation", "Implement for DNSSEC Signing", or "Implement for DNSSEC Validation" columns requires Standards Action. If an item is not marked as "RECOMMENDED", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. - https://www.iana.org/assignments/ds-rr-types/ Digest Algorithms ... Note Adding a new entry to the "Digest Algorithms" registry with a recommended value of "MAY" in the "Use for DNSSEC Delegation”, "Use for DNSSEC Validation", "Implement for DNSSEC Delegation", or "Implement for DNSSEC Validation" columns SHALL follow the Specification Required policy as defined in [RFC8126]. Adding a new entry to, or changing an existing value in, the "Digest Algorithms" registry that has any value other than “MAY" in the "Use for DNSSEC Delegation", "Use for DNSSEC Validation”, "Implement for DNSSEC Delegation", or "Implement for DNSSEC Validation" columns requires Standards Action. If an item is not marked as "RECOMMENDED", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. Best regards, David Dong IANA Services Sr. Specialist On Fri Nov 07 20:49:18 2025, [email protected] wrote: > Dear IANA, > > Please update the following registries to match the edited document at > <https://www.rfc-editor.org/authors/rfc9904-diff.html>. > > 1) Under the “Note” for the "DNS Security Algorithm Numbers” registry > <https://www.iana.org/assignments/dns-sec-alg-numbers>: > > OLD: > Adding a new entry to the "DNS System Algorithm Numbers" registry > with > a recommended value of "MAY" in the "Use for DNSSEC Signing", "Use > for > DNSSEC Validation", "Implement for DNSSEC Signing", or "Implement > for > DNSSEC Validation" columns will subject to the "Specification > Required” > policy as defined in [RFC8126] in order to promote continued > evolution > of DNSSEC algorithms and DNSSEC agility. New entries added through > the "Specification Required" process will have the value of “MAY" > for all columns. > > Adding a new entry to, or changing existing values in, the "DNS System > Algorithm Numbers" registry for the "Use for DNSSEC Signing", "Use for > DNSSEC Validation", "Implement for DNSSEC Signing", or "Implement for > DNSSEC Validation" columns to any other value than "MAY" requires a > Standards Action. > > NEW: > Adding a new entry to the "DNS Security Algorithm Numbers” > registry with a recommended value of "MAY" in the "Use for DNSSEC > Signing", "Use for DNSSEC Validation", "Implement for DNSSEC > Signing", or "Implement for DNSSEC Validation" columns will be > subject to the Specification Required policy as defined in > [RFC8126] in order to promote continued evolution of DNSSEC > algorithms and DNSSEC agility. New entries added through the > Specification Required process will have the value of "MAY” for > all columns. > > Adding a new entry to, or changing an existing value in, the “DNS > Security Algorithm Numbers" registry that has any value other than > "MAY" in the "Use for DNSSEC Signing", "Use for DNSSEC > Validation", "Implement for DNSSEC Signing", or "Implement for > DNSSEC Validation" columns requires Standards Action. > > 2) Under the “Note” for the “Digest Algorithms” registry > <https://www.iana.org/assignments/ds-rr-types>: > > OLD: > Adding a new entry to the "Digest Algorithms" registry with a > recommended value of "MAY" in the "Use for DNSSEC Delegation”, > "Use for DNSSEC Validation", "Implement for DNSSEC Delegation”, > or "Implement for DNSSEC Validation" columns SHALL follow the > "Specification Required" policy as defined in [RFC8126]. > > Adding a new entry to, or changing existing values in, the > "Digest Algorithms" registry for the "Use for DNSSEC Delegation”, > "Use for DNSSEC Validation", "Implement for DNSSEC Delegation”, > or "Implement for DNSSEC Validation" columns to any other value > than "MAY" requires a Standards Action. > > NEW: > Adding a new entry to the "Digest Algorithms" registry with a > recommended value of "MAY" in the "Use for DNSSEC Delegation”, > "Use for DNSSEC Validation", "Implement for DNSSEC Delegation", or > "Implement for DNSSEC Validation" columns SHALL follow the > Specification Required policy as defined in [RFC8126]. > > Adding a new entry to, or changing an existing value in, the > "Digest Algorithms" registry that has any value other than “MAY" > in the "Use for DNSSEC Delegation", "Use for DNSSEC Validation”, > "Implement for DNSSEC Delegation", or "Implement for DNSSEC > Validation" columns requires Standards Action. > > Thank you in advance! > > Karen Moore > RFC Production Center > > > > Begin forwarded message: > > > > From: Karen Moore <[email protected]> > > Subject: Re: [auth48] AUTH48: RFC-to-be 9904 <draft-ietf-dnsop- > > rfc8624-bis-13> for your review > > Date: November 5, 2025 at 5:19:23 PM PST > > To: Wes Hardaker <[email protected]>, Warren Kumari > > <[email protected]> > > Cc: [email protected], [email protected], dnsop- > > [email protected], [email protected], [email protected], > > [email protected], [email protected] > > > > 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] > >> editor.org> 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] > >>> editor.org> 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]
