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 <[email protected]>; >>> 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]>> 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 > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
