> 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 > <mailto: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 <mailto:war...@kumari.net>> >> *Envoyé :* jeudi 11 septembre 2025 23:57 >> *À :* Sarah Tarrant <starr...@staff.rfc-editor.org >> <mailto:starr...@staff.rfc-editor.org>> >> *Cc :* John R Levine <jo...@taugh.com <mailto:jo...@taugh.com>>; Johan >> Stenstam <johan.stens...@internetstiftelsen.se >> <mailto:johan.stens...@internetstiftelsen.se>>; Peter Thomassen >> <peter=40desec...@dmarc.ietf.org <mailto:peter=40desec...@dmarc.ietf.org>>; >> RFC System <rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>>; >> DNSOP ADs <dnsop-...@ietf.org <mailto:dnsop-...@ietf.org>>; dnsop-chairs >> <dnsop-cha...@ietf.org <mailto:dnsop-cha...@ietf.org>>; Tim Wicinski >> <tjw.i...@gmail.com <mailto:tjw.i...@gmail.com>>; auth48archive >> <auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>>; Oli >> Schacher <oli.schac...@switch.ch <mailto: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><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><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/><http://example.com/>" >> with agent domain "errors.ns1.example.net >> <http://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/><http://example.com/>" >> with agent domain "errors.ns1.example.net >> <http://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
smime.p7s
Description: S/MIME cryptographic signature
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
