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
