[DNSOP] Re: Éric Vyncke's Discuss on draft-ietf-dnsop-generalized-notify-07: (with DISCUSS and COMMENT)

[Peter Thomassen <[e-mail]>]

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.

> ### 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).

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.

> ----------------------------------------------------------------------
> 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.

> ### 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.

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.

> ### 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

> 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