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 <iana-mat...@iana.org> 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, 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
