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, starr...@staff.rfc-editor.org 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 <starr...@staff.rfc- > > 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 <pe...@desec.io> 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 > >>>> <johan.stens...@internetstiftelsen.se> wrote: > >>>> > >>>> > >>>>> On 12 Sep 2025, at 11:04, Peter Thomassen <pe...@desec.io> 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, mohamed.boucad...@orange.com 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 <war...@kumari.net> > >>>>>> *Envoyé :* jeudi 11 septembre 2025 23:57 > >>>>>> *À :* Sarah Tarrant <starr...@staff.rfc-editor.org> > >>>>>> *Cc :* John R Levine <jo...@taugh.com>; Johan Stenstam > >>>>>> <johan.stens...@internetstiftelsen.se>; Peter Thomassen > >>>>>> <peter=40desec...@dmarc.ietf.org>; RFC System <rfc-editor@rfc- > >>>>>> editor.org>; DNSOP ADs <dnsop-...@ietf.org>; dnsop-chairs > >>>>>> <dnsop-cha...@ietf.org>; Tim Wicinski <tjw.i...@gmail.com>; > >>>>>> auth48archive <auth48archive@rfc-editor.org>; Oli Schacher > >>>>>> <oli.schac...@switch.ch> > >>>>>> *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 > >>>>>> <starr...@staff.rfc-editor.org<mailto:starr...@staff.rfc- > >>>>>> 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 > >>>>>> <johan.stens...@internetstiftelsen.se<mailto:johan.stens...@internetstiftelsen.se>> > >>>>>> 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
