Hi David, Looks great!
Thank you, Sarah Tarrant RFC Production Center > On Sep 17, 2025, at 1:02 PM, David Dong via RT <[email protected]> wrote: > > Hi Sarah, > > Apologies; the columns are now aligned. > > Please see: > https://www.iana.org/assignments/dns-parameters/ > > Thank you! > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Wed Sep 17 13:04:50 2025, [email protected] wrote: >> Hi David, >> >> I'm looking at the registry and also the CSV version. The columns >> don't appear to be aligned, as in the headers "Purpose" and >> "Reference" are not directly on top of their respective columns. >> >> Is there any way to fix that? >> >> Thank you, >> Sarah Tarrant >> RFC Production Center >> >>> On Sep 16, 2025, at 6:13 PM, David Dong via RT <[email protected]> >>> wrote: >>> >>> Hi Sarah, >>> >>> This has been completed: >>> >>> RRtype Scheme (Mnemonic) Purpose Reference >>> ... >>> CDS 1 (NOTIFY) Delegation management [RFC-ietf-dnsop-generalized- >>> notify-09] >>> CSYNC 1 (NOTIFY) Delegation management [RFC-ietf-dnsop-generalized- >>> notify-09] >>> ... >>> >>> Registry: >>> https://www.iana.org/assignments/dns-parameters/ >>> >>> Best regards, >>> >>> David Dong >>> IANA Services Sr. Specialist >>> >>> On Mon Sep 15 21:19:43 2025, [email protected] wrote: >>>> Hi IANA, >>>> >>>> Please make the following update to the "Domain Name System (DNS) >>>> Parameters" registry at https://www.iana.org/assignments/dns- >>>> parameters/. >>>> >>>> Merge the "Scheme" and "Mnemonic" columns to read "Scheme >>>> (Mnemonic)" >>>> with values "1 (NOTIFY)" (two times). >>>> >>>> OLD: >>>> ...+========+==========+=======================+===========+ >>>> ...| Scheme | Mnemonic | Purpose | Reference | >>>> ...+========+==========+=======================+===========+ >>>> ... ... >>>> ...| 1 | NOTIFY | Delegation management | RFC 9859 | >>>> ...+--------+----------+-----------------------+-----------+ >>>> ...| 1 | NOTIFY | Delegation management | RFC 9859 | >>>> ...+--------+----------+-----------------------+-----------+ >>>> ... ... >>>> >>>> NEW: >>>> ...+===================+=======================+===========+ >>>> ...| Scheme (Mnemonic) | Purpose | Reference | >>>> ...+===================+=======================+===========+ >>>> ... ... >>>> ...| 1 (NOTIFY) | Delegation management | RFC 9859 | >>>> ...+-------------------+-----------------------+-----------+ >>>> ...| 1 (NOTIFY) | Delegation management | RFC 9859 | >>>> ...+-------------------+-----------------------+-----------+ >>>> ... ... >>>> >>>> Thank you, >>>> Sarah Tarrant >>>> RFC Production Center >>>> >>>>> On Sep 15, 2025, at 3:51 PM, Sarah Tarrant <[email protected] >>>>> editor.org> wrote: >>>>> >>>>> Hi Peter, >>>>> >>>>> Good catch! I'll get that to IANA right away. >>>>> >>>>> Thank you, >>>>> Sarah Tarrant >>>>> RFC Production Center >>>>> >>>>>> On Sep 15, 2025, at 3:22 PM, Peter Thomassen <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi Sarah, >>>>>> >>>>>> Thanks. >>>>>> >>>>>> The IANA registry needs to be updated to reflect the new column >>>>>> layout. Please let me know if we need to prod them in case this >>>>>> doesn't happen automatically. >>>>>> >>>>>> Final nit: The new sentence "Future assignments are maintained the >>>>>> registry created in Section 6.2." is missing an "in". >>>>>> >>>>>> Best, >>>>>> Peter >>>>>> >>>>>> >>>>>> On 9/15/25 09:48, Sarah Tarrant wrote: >>>>>>> Hi all, >>>>>>> Thank you for your replies. My apologies for including the wrong >>>>>>> AD >>>>>>> Med - Thank you for your approval and notes. I have updated the >>>>>>> document accordingly and have marked your approval on the AUTH48 >>>>>>> status page for this document (see https://www.rfc- >>>>>>> editor.org/auth48/rfc9589). >>>>>>> We have now received all necessary approvals and consider AUTH48 >>>>>>> complete. Thank you for your attention and guidance during the >>>>>>> AUTH48 process. >>>>>>> We will move this document forward in the publication process at >>>>>>> this time. >>>>>>> The updated files have been posted here (please refresh): >>>>>>> https://www.rfc-editor.org/authors/rfc9859.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9859.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9859.html >>>>>>> https://www.rfc-editor.org/authors/rfc9859.xml >>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>> https://www.rfc-editor.org/authors/rfc9859-diff.html >>>>>>> (comprehensive >>>>>>> diff) >>>>>>> https://www.rfc-editor.org/authors/rfc9859-auth48diff.html >>>>>>> (AUTH48 >>>>>>> changes only) >>>>>>> Note that it may be necessary for you to refresh your browser to >>>>>>> view the most recent version. >>>>>>> For the AUTH48 status of this document, please see: >>>>>>> https://www.rfc-editor.org/auth48/rfc9859 >>>>>>> Thank you, >>>>>>> Sarah Tarrant >>>>>>> RFC Production Center >>>>>>>> On Sep 12, 2025, at 10:22 AM, Johan Stenstam >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 12 Sep 2025, at 11:04, Peter Thomassen <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> While I like some of these changes and would prefer not >>>>>>>>> applying >>>>>>>>> some others, none of them in my view are important enough to >>>>>>>>> spend any time discussing, so I would be OK with these changes >>>>>>>>> and am signaling my approval independently of which of them are >>>>>>>>> applied or not. >>>>>>>> >>>>>>>> I agree with Peter and John. I can live with or without these >>>>>>>> changes. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Johan >>>>>>>> >>>>>>>>> On 9/12/25 07:52, [email protected] wrote: >>>>>>>>>> Hi all, >>>>>>>>>> I approve the change in Appendix A.2. >>>>>>>>>> As I m’ there, please find below some few nits I tagged when >>>>>>>>>> reviewing the document: >>>>>>>>>> * 1.1: nit >>>>>>>>>> OLD: >>>>>>>>>> This suggests that the lookup process be ignorant >>>>>>>>>> of the details of the parent-side relationships (e.g., >>>>>>>>>> whether >>>>>>>>>> or not >>>>>>>>>> there is a registrar.) This is addressed by parameterizing >>>>>>>>>> the >>>>>>>>>> ^^^^ >>>>>>>>>> NEW: >>>>>>>>>> This suggests that the lookup process be ignorant >>>>>>>>>> of the details of the parent-side relationships (e.g., >>>>>>>>>> whether >>>>>>>>>> or not >>>>>>>>>> there is a registrar). This is addressed by parameterizing >>>>>>>>>> the >>>>>>>>>> * “may optionally” is redundant. I suggest to drop >>>>>>>>>> “optionally” >>>>>>>>>> in the following: >>>>>>>>>> CURRENT: >>>>>>>>>> The parent operator may then >>>>>>>>>> (optionally) announce the notification endpoint in a >>>>>>>>>> delegation- >>>>>>>>>> and >>>>>>>>>> A scheme number may optionally have exactly one >>>>>>>>>> mnemonic. >>>>>>>>>> * 1.1: this is a PS >>>>>>>>>> OLD: The solution proposed here >>>>>>>>>> NEW: The solution specified here >>>>>>>>>> * Section 2.1 >>>>>>>>>> (1) >>>>>>>>>> Please add a caption/legend for the figure as this helps/eases >>>>>>>>>> external referencing: >>>>>>>>>> NEW: >>>>>>>>>> Figure 1: DSYNC RDATA Wire Format >>>>>>>>>> (2) Add a reference to the registry for the readers’ >>>>>>>>>> convenience: >>>>>>>>>> CURRENT: >>>>>>>>>> RRtype: The type of generalized NOTIFY that this DSYNC RR >>>>>>>>>> defines >>>>>>>>>> the desired target address for (see the "Resource Record >>>>>>>>>> (RR) >>>>>>>>>> TYPEs" registry). >>>>>>>>>> Registry: https://www.iana.org/assignments/dns-parameters/dns- >>>>>>>>>> parameters.xhtml#dns-parameters- >>>>>>>>>> 4<https://www.iana.org/assignments/dns-parameters/dns- >>>>>>>>>> parameters.xhtml#dns-parameters-4> >>>>>>>>>> (3) Point to where future values are maintained. The >>>>>>>>>> authoritative source is the registry not the subset of values >>>>>>>>>> frozen in this description. >>>>>>>>>> OLD: >>>>>>>>>> Value 1 is described in >>>>>>>>>> this document, and values 128-255 are Reserved for Private >>>>>>>>>> Use. >>>>>>>>>> All other values are currently unassigned. >>>>>>>>>> NEW: >>>>>>>>>> Value 1 is described in >>>>>>>>>> this document, and values 128-255 are Reserved for Private >>>>>>>>>> Use. >>>>>>>>>> Other values are currently unassigned. Future assignments >>>>>>>>>> are >>>>>>>>>> maintained the registry created in Section 6.2. >>>>>>>>>> (4) Transport port number >>>>>>>>>> OLD >>>>>>>>>> Port: The port on the target host of the notification >>>>>>>>>> service. >>>>>>>>>> NEW: >>>>>>>>>> Port: The transport port number on the target host of the >>>>>>>>>> notification service. >>>>>>>>>> * Section 2.3 >>>>>>>>>> The address is not listed as such in the record. I suggest the >>>>>>>>>> following or similar chane: >>>>>>>>>> OLD: >>>>>>>>>> address and port listed in that DSYNC record and using >>>>>>>>>> conventional >>>>>>>>>> DNS transport [RFC1035]. >>>>>>>>>> NEW: >>>>>>>>>> address and port number that corresponds to that DSYNC record >>>>>>>>>> and using conventional >>>>>>>>>> DNS transport [RFC1035]. >>>>>>>>>> * Section 4.2 >>>>>>>>>> The discovery is discussed in the previous sub-section, not >>>>>>>>>> the >>>>>>>>>> previous section (i.e., section 3). >>>>>>>>>> OLD: >>>>>>>>>> the endpoints discovered as described in the previous >>>>>>>>>> section. >>>>>>>>>> NEW: >>>>>>>>>> the endpoints discovered as described in Section 4.1. >>>>>>>>>> * Section 4.3 >>>>>>>>>> EDE is already introduced 4.2.1 >>>>>>>>>> OLD: >>>>>>>>>> processing by sending a report query with an appropriate >>>>>>>>>> extended >>>>>>>>>> DNS error (EDE) code >>>>>>>>>> NEW : >>>>>>>>>> processing by sending a report query with an appropriate >>>>>>>>>> EDE code >>>>>>>>>> Cheers, >>>>>>>>>> Med >>>>>>>>>> *De :*Warren Kumari <[email protected]> >>>>>>>>>> *Envoyé :* jeudi 11 septembre 2025 23:57 >>>>>>>>>> *À :* Sarah Tarrant <[email protected]> >>>>>>>>>> *Cc :* John R Levine <[email protected]>; Johan Stenstam >>>>>>>>>> <[email protected]>; Peter Thomassen >>>>>>>>>> <[email protected]>; RFC System <rfc-editor@rfc- >>>>>>>>>> editor.org>; DNSOP ADs <[email protected]>; dnsop-chairs >>>>>>>>>> <[email protected]>; Tim Wicinski <[email protected]>; >>>>>>>>>> auth48archive <[email protected]>; Oli Schacher >>>>>>>>>> <[email protected]> >>>>>>>>>> *Objet :* Re: [AD] AUTH48: RFC-to-be 9859 <draft-ietf-dnsop- >>>>>>>>>> generalized-notify-09> for your review >>>>>>>>>> Hi there, >>>>>>>>>> Warren has no authority here anymore - I'd suggest that Med >>>>>>>>>> should be substituted. >>>>>>>>>> W >>>>>>>>>> On Thu, Sep 11, 2025 at 4:51 PM, Sarah Tarrant >>>>>>>>>> <[email protected]<mailto:[email protected] >>>>>>>>>> editor.org>> wrote: >>>>>>>>>> Hi John, Johan, Peter, and *Warren, >>>>>>>>>> *AD review - Warren - Regarding the following nit from Peter: >>>>>>>>>> Appendix A.2 >>>>>>>>>> OLD (current, after RFC editing) >>>>>>>>>> [DNSSEC-AUTO] >>>>>>>>>> NEW >>>>>>>>>> [RFC8901] >>>>>>>>>> (Rationale: the DNSSEC-AUTO draft was anticipated to be >>>>>>>>>> published before this but was not; the currently correct >>>>>>>>>> informative reference therefore is RFC 8901.) >>>>>>>>>> Please review the informative reference update and let us >>>>>>>>>> know >>>>>>>>>> if this change is approved: >>>>>>>>>> Removed: I-D.ietf-dnsop-dnssec-automation >>>>>>>>>> Replaced with: RFC 8901 (which was already an informative >>>>>>>>>> reference) >>>>>>>>>> Best viewed at: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9859-auth48diff.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9859-auth48diff.html> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9859-auth48rfcdiff.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9859- >>>>>>>>>> auth48rfcdiff.html> >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> Peter, John, and Johan - Thank you for your replies. We have >>>>>>>>>> updated the document accordingly and have marked your approval >>>>>>>>>> on the AUTH48 status page for this document (see >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9589 <https://www.rfc- >>>>>>>>>> editor.org/auth48/rfc9589>). >>>>>>>>>> We will await Warren's approval prior to moving this document >>>>>>>>>> forward in the publication process. >>>>>>>>>> The updated files have been posted here (please refresh): >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9859.txt >>>>>>>>>> <https://www.rfc- >>>>>>>>>> editor.org/authors/rfc9859.txt> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9859.pdf >>>>>>>>>> <https://www.rfc- >>>>>>>>>> editor.org/authors/rfc9859.pdf> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9859.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9859.html> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9859.xml >>>>>>>>>> <https://www.rfc- >>>>>>>>>> editor.org/authors/rfc9859.xml> >>>>>>>>>> The relevant diff files have been posted here (please >>>>>>>>>> refresh): >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9859-diff.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9859-diff.html> >>>>>>>>>> (comprehensive diff) https://www.rfc- >>>>>>>>>> editor.org/authors/rfc9859- >>>>>>>>>> auth48diff.html<https://www.rfc-editor.org/authors/rfc9859- >>>>>>>>>> auth48diff.html> (AUTH48 changes only) >>>>>>>>>> Note that it may be necessary for you to refresh your browser >>>>>>>>>> to >>>>>>>>>> view the most recent version. >>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9859<https://www.rfc- >>>>>>>>>> editor.org/auth48/rfc9859> >>>>>>>>>> Thank you, >>>>>>>>>> Sarah Tarrant >>>>>>>>>> RFC Production Center >>>>>>>>>> On Sep 11, 2025, at 5:28 AM, Johan Stenstam >>>>>>>>>> <[email protected]<mailto:[email protected]>> >>>>>>>>>> wrote: >>>>>>>>>> Hi Sarah, >>>>>>>>>> A) FYI, regarding: >>>>>>>>>> We updated "native" to "built-in" and "traditional" to >>>>>>>>>> "original". Please verify. >>>>>>>>>> I approve this change. >>>>>>>>>> B) Regarding: >>>>>>>>>> Current: >>>>>>>>>> Therefore, it is RECOMMENDED that the child delay >>>>>>>>>> sending >>>>>>>>>> notifications to the recipient until a consistent >>>>>>>>>> public >>>>>>>>>> view of the >>>>>>>>>> pertinent records is ensured. >>>>>>>>>> Perhaps: >>>>>>>>>> Therefore, it is RECOMMENDED that the child would delay >>>>>>>>>> sending >>>>>>>>>> notifications to the recipient until a consistent >>>>>>>>>> public >>>>>>>>>> view of the >>>>>>>>>> pertinent records could be ensured. >>>>>>>>>> I approve this change. >>>>>>>>>> Please review the document carefully to ensure >>>>>>>>>> satisfaction as we do not make changes once it has been >>>>>>>>>> published as an RFC. >>>>>>>>>> For a clear record, please send approvals after viewing >>>>>>>>>> the document in its current form. >>>>>>>>>> The updated files have been posted here (please >>>>>>>>>> refresh): https://www.rfc-editor.org/authors/rfc9859.txt >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9859.txt> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9859.pdf >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9859.pdf> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9859.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9859.html> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9859.xml >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9859.xml> >>>>>>>>>> The relevant diff files have been posted here (please >>>>>>>>>> refresh): https://www.rfc-editor.org/authors/rfc9859-diff.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9859-diff.html> >>>>>>>>>> (comprehensive diff) https://www.rfc- >>>>>>>>>> editor.org/authors/rfc9859- >>>>>>>>>> auth48diff.html<https://www.rfc-editor.org/authors/rfc9859- >>>>>>>>>> auth48diff.html> (AUTH48 changes only) >>>>>>>>>> I have reviewed the entire updated document and have no >>>>>>>>>> objections. That said, I do agree with Peter that his >>>>>>>>>> suggested >>>>>>>>>> change would be an improvement (but it is not a show-stopper): >>>>>>>>>> CURRENT >>>>>>>>>> For example, when receiving a NOTIFY(CDS) message for >>>>>>>>>> "example.com<http://example.com/>" >>>>>>>>>> with agent domain "errors.ns1.example.net >>>>>>>>>> <http://errors.ns1.example.net/>", and when the requested DS >>>>>>>>>> update is found to break the delegation, then the >>>>>>>>>> following report >>>>>>>>>> query may be made (preferably over TCP): >>>>>>>>>> NEW >>>>>>>>>> For example, when receiving a NOTIFY(CDS) message for >>>>>>>>>> "example.com<http://example.com/>" >>>>>>>>>> with agent domain "errors.ns1.example.net >>>>>>>>>> <http://errors.ns1.example.net/>", and when the requested DS >>>>>>>>>> update is found to break the delegation, then the >>>>>>>>>> following report >>>>>>>>>> query with EDE code 6 (DNSSEC Bogus) may be made, >>>>>>>>>> preferably over TCP: >>>>>>>>>> Regards, >>>>>>>>>> Johan Stenstam >>>>>>>>>> ____________________________________________________________________________________________________________ >>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>>> informations confidentielles ou privilegiees et ne doivent >>>>>>>>>> donc >>>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si >>>>>>>>>> vous avez recu ce message par erreur, veuillez le signaler >>>>>>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. >>>>>>>>>> Les >>>>>>>>>> messages electroniques etant susceptibles d'alteration, >>>>>>>>>> Orange decline toute responsabilite si ce message a ete >>>>>>>>>> altere, >>>>>>>>>> deforme ou falsifie. Merci. >>>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>>> privileged information that may be protected by law; >>>>>>>>>> they should not be distributed, used or copied without >>>>>>>>>> authorisation. >>>>>>>>>> If you have received this email in error, please notify the >>>>>>>>>> sender and delete this message and its attachments. >>>>>>>>>> As emails may be altered, Orange is not liable for messages >>>>>>>>>> that >>>>>>>>>> have been modified, changed or falsified. >>>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Like our community service? 💛 >>>>>>>>> Please consider donating at >>>>>>>>> >>>>>>>>> https://desec.io/ >>>>>>>>> >>>>>>>>> deSEC e.V. >>>>>>>>> Möckernstraße 74 >>>>>>>>> 10965 Berlin >>>>>>>>> Germany >>>>>>>>> >>>>>>>>> Vorstandsvorsitz: Nils Wisiol >>>>>>>>> Registergericht: AG Berlin (Charlottenburg) VR 37525 >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Like our community service? 💛 >>>>>> Please consider donating at >>>>>> >>>>>> https://desec.io/ >>>>>> >>>>>> deSEC e.V. >>>>>> Möckernstraße 74 >>>>>> 10965 Berlin >>>>>> Germany >>>>>> >>>>>> Vorstandsvorsitz: Nils Wisiol >>>>>> Registergericht: AG Berlin (Charlottenburg) VR 37525 >>>>>> >>>>> >>> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
