Hi all, 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.
Best, Peter 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 -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
