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-edi...@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
