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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
