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]
