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], [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]> 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]
