Hello Peter, Thank you for your quick and detailed reply.
See below for EVY> and more comments. In short, the proposed changes address my current blocking DISCUSS issues :-) Looking forward for your revised I-D (note that next week I will be away from keyboard so no urgency for a revised I-D). Regards -éric From: Peter Thomassen <pe...@desec.io> Date: Thursday, 6 March 2025 at 16:41 To: Eric Vyncke (evyncke) <evyn...@cisco.com>, The IESG <i...@ietf.org> Cc: draft-ietf-dnsop-generalized-not...@ietf.org <draft-ietf-dnsop-generalized-not...@ietf.org>, dnsop-cha...@ietf.org <dnsop-cha...@ietf.org>, dnsop@ietf.org <dnsop@ietf.org>, tjw.i...@gmail.com <tjw.i...@gmail.com>, peter.van.d...@powerdns.com <peter.van.d...@powerdns.com> Subject: Re: [DNSOP] Éric Vyncke's Discuss on draft-ietf-dnsop-generalized-notify-07: (with DISCUSS and COMMENT) Hi Éric, Many thanks for your thorough review! On 3/5/25 14:50, Éric Vyncke via Datatracker wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > [...] > Other thanks to Peter van Dijk, the DNS directorate reviewer, please consider > this dns-dir review: > https://datatracker.ietf.org/doc/review-ietf-dnsop-generalized-notify-07-dnsdir-telechat-van-dijk-2025-03-03/ These have been addressed; for details, see https://mailarchive.ietf.org/arch/msg/dnsop/cshGzSbl4ikFE-PDkxwN9uJDD6k/. > ### Section 4.1 > > Deeply sorry, but please use only the example domains in this document rather > than `mie.jp`, which is not an example/documentation domain name if not > mistaken. Done. EVY> Superb > ### Section 4.3 > > Where is a 'valid NOTIFY' defined in `Upon receipt of a (potentially > forwarded) > valid NOTIFY(CDS) `? The previous sentence talks about an invalid case (where a NOTIFY relates to several domains); it was intended to imply in this sentence that we're now describing the handling of valid NOTIFYs (i.e., the ones that are not invalid as previously described). EVY> So, the only invalid case is when there are more than 1 child zone ? This was not super clear to be honest and your new text is addressing my concern. But indeed, it may be unclear, so we removed "valid" and added "Otherwise," at the beginning: NEW NOTIFY messages carrying notification payloads (records) for more than one child zone MUST be discarded, as sending them is an error. Otherwise, upon receipt of a (potentially forwarded) NOTIFY message for a particular child zone at the published notification endpoint, [...] > This is also related to section 2.1 where the behavior for > unknown/unspecified RRtype/scheme is not defined. Section 4.3 describes how a parent handles NOTIFY messages it receives. Section 2.1, on the other hand, describes the DSYNC record that a child uses to figure out how to send a NOTIFY to the parent. It cannot happen that the parent receives a NOTIFY with an invalid scheme, because the scheme is not a parameter of the message received by the parent. Rather, it's used by the child to decide how to construct/send the message. If a child sees a DSYNC record with a scheme that is unknown (either unassigned, or unsupported by the child), it simply won't send a message according to that scheme (because it wouldn't know what to do). Hope that clarifies this a bit! The main point is that parents don't have to worry about it, and children don't have to worry about it either. EVY> understood > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > ## COMMENTS (non-blocking) > > ### Intended status and section 7 > > The intended status is "proposed standard" for a rather important change > (albeit if only for optimization, i.e., can fail) but there are no real live > deployments yet. Did the WG consider using an experimental status first, and > proposed standard after 1 year of experimentation ? We did consider Experimental status. The WG believed that implementations will not be problematic, and we'd like to avoid the extra cycles for everyone (including IESG) for a change-status RFC in two years from now etc. As the WG was OK with Proposed Standard, we'd prefer to leave this as is. EVY> still not convinced completely to be honest, but I agree that failures won’t be catastrophic. Also, nice to read that this was discussed within the WG. > ### Section 1.1 > > This section would be more palatable for non-DNS expert by adding some > examples. > > s/design requirements/design goals/ (as this is not real hard requirements) Done. > ### Section 2.3 > > All text is normative in a PS, but why not stressing the "should" by using a > "SHOULD" in `message should be sent to the address and port listed` ? > > Please explain also why some DNS servers could bypass this "should". Only uppercase keywords are to be interpreted as described in BCP 14. The "should" here expresses the parent's intention, and is not a normative statement. ("We publish a DSYNC record which child operators should use to nudge us to update the delegation.") We therefore don't think it should (haha) be uppercase, nor does it need to be explained when it can be bypassed. EVY> beside the smile above ;-) all the text is really normative, i.e., the “should” should (aha ;-) ) have some bypass explanations. EVY> the proposed new text avoids the problem, so all is good In case this makes anyone uneasy, here's a suggested alternative: OLD For now, the only scheme defined is 1 (mnemonic: NOTIFY). It indicates that when a new CDS/CDNSKEY (or CSYNC) RRset is published, a NOTIFY message (see Section 4) should be sent to the address and port listed in the corresponding DSYNC record, using conventional [RFC1035] DNS transport. NEW For now, the only scheme defined is 1 (mnemonic: NOTIFY). By publishing a DSYNC record with this scheme, a parent indicates that they would like child operators to send them a NOTIFY message (see Section 4) upon publication of a new CDS/CDNSKEY/CSYNC RRset, to the address and port listed in that DSYNC record and using conventional [RFC1035] DNS transport. Please let us know if you'd like this change to be made. > ### Section 3 > > s/for discovering that notification target./for discovering that notification > target(s)./ ? There's only one target, because Section 3: There MUST NOT be more than one DSYNC record for each combination of RRtype and Scheme. EVY> my bad > ### Section 3.1 > > Suggest instantiating all fields (scheme/port/target) of the example as done > in > other examples. The other examples in Section 2.3 illustrate the semantic of the DSYNC record overall, and thus are fully instantiated. The focus here is on the wildcard; we don't want people to think there's anything special about the port instantiated (for example). But indeed, it does make sense though to instantiate parameters that are actually assigned and not free variables (i.e., the rrtype and scheme). So suggest the following new: NEW *._dsync.example. IN DSYNC CDS NOTIFY port target *._dsync.example. IN DSYNC CSYNC NOTIFY port target EVY> better indeed even if I still wonder why port/target are not instantiated > Should there be an informative reference for `in ICANN's model` ? That's a good idea, but I wasn't able to find a good one. We'll request a manual submission from Warren at this point (as suggested by John Scudder), but suggestions for such a reference by others remain welcome! Thanks again, Johan, John, Peter
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
