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]
