Message-ID: <1ebcb864-1036-4987-b6c0-b934a31be86d@desec.io>
Date: Thu, 6 Mar 2025 16:40:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: =?UTF-8?Q?=C3=89ric_Vyncke?= <evyncke@cisco.com>, The IESG <iesg@ietf.org>
References: 
 <174118263504.762204.2843259903410910075@dt-datatracker-5dd67b77bb-4k4zh>
Content-Language: en-US, de-DE
From: Peter Thomassen <peter@desec.io>
Autocrypt: addr=peter@desec.io; keydata=
 xsFNBFRjVn0BEADXqtra70yxQrT4MQ9DEhN0mxG6XRAOHE6nP18mqxwSlcET7D6w+z3h4ole
 v0tyvUU02c2wg04X8WVfjoHnAvIa1dfUcNpB1+QmfFsw0xIJlbT1ogHkMiPQqR4ChDvE3ND/
 6YCS5+HT6hY+tfU+hpLsKw4l+u1Pg2NPVLYosET1jU84b7xhFnoicnCV3kUNltLtxLKSBAfk
 AXtp1AWWKJbfCr3y0qKElMriicoe5DUZfLrZK2iPcWBxh+n7KMO2g7aqx3aQqwW1+S7Sq7Is
 l6iSurYfIcHb4AfUy4o5nPB8kKACR6BuJmkEQ5WLuTGruWA2fcxaNpICmolMinTzW1CrIjgN
 PoskMYCNIZ2uWxS6LN8hBiGCRL4h9aL4wuT09SvR13oAPI1HD5ph+mH6wD37/ONBXrdjcFNb
 1l/uVkHU/SwwcKDJOsX18T60Ao00fciTbFHgmKtFube0xGK/vjh461TyU+xKD8Orvyeovvxy
 MzCwM3UVq/dkdG2Ys/7Qy/4bUC1nJEwKlLv7ZTdtSckdoU2M6JpPX6i4KDB2YCMbwtqJ842z
 8A/UuE2bL9aDimh/sF8WgPIhlxqF1STNqW1JTIbDPv8HeZnM4nyJOUWStj4uRiETQhBClPLz
 YWtnR+EUsfbSLy81vfupbMqRasDlt6aASobgn+K7Rb1Xs/mDnwARAQABzSBQZXRlciBUaG9t
 YXNzZW4gPHBldGVyQGRlc2VjLmlvPsLBeAQTAQIAIgUCVGNWfQIbIwYLCQgHAwIGFQgCCQoL
 BBYCAwECHgECF4AACgkQ79YUOj7yLS88Dg//SbHnFGrtaImEiM69wyj4GzWnuGk9/upCym/R
 RzdBALCYHU9FUFFHwusiO9A0pnO8qv/GEtqqTHrcL205a6FTivkdZmOsWuN4oo7r4HBc/taI
 FLLUDg2wd8q4m4387sYEqrc3olGfyRB6hrMtEWVJLXHJmpcrxAaI1F2QO4Bu7kcdTnyGFz/p
 ZD8XAof2TWHqJb2ux69DFhiAJeAZlV+h9QrxTedL84l4hq3x1VWsnOEFaCJiThDX920kTnhJ
 ijrDocgAbmQBCniPACpPHYhBhmCJxfVqgfMuLMNsukOmKxsGcGV6rO1zB5ZUhm3O/Ixk6ow3
 6FDKALWihg6Z4P/cJYySMn0iqvHkO8ryT9oJKX//mKaYoF6henXDRLCcRjKwGxFQTEgX+6yc
 pjgvX3rlypjkPT5ho4yEc5ePkQ2gIIHhvZburm1Zr4nDPx6v8+3XUjpXBRTWQ8/0/h0rtLJe
 yOPwGJxcfKf/GutTCqiio0mS01mIY9c2i7JWcljlIuSEUit6CHotc5lBOm2GJwguRJG6cXPY
 SQecwBdcjH3RTzBOv/DN6xWAIV7BmbX/e7DSGAc60mBO1/M0ut+a6CkxRQK8TaE3B3zh1/QO
 nG0XvtZfIY8ZYdTrdEDSV1Pj5pof/fqhhegHRxN2qi4qIuVcrW0jsUsx10IgAynHR7qQKsvO
 wU0EVGNWfQEQAPBA8iPCS4ZRX8stW0WuW7579axSq/Luyik4MWDFalt68lzvUbV0f6faN15+
 aV7VwMTw3rSa2tP0U8crYAAAZ5NrRHXlYms5BK9vsi1322dAvhyNRawdprP627SO+Ez/84tY
 xz1X3M9esbN7gpJtHP6mHW76zYpT447v6c2qlbldjobZTDb6kKSGFCIrPJz9M4jVfya+ovxe
 2Ab7hn2R0CcyMHATV5g1Ry0XXaj5y3bWypActbG9nflRn3NjhHZynu+WEPDUJCO8kNVNYKOw
 HObNTeaLvgvU0ONB8pYJv35kDXMhZLwo5MJuJd5i54CXwpo9mECwLJT1RpJi7u98nBrWyyaH
 s2brG9LPCRKBKOhiHFu57H+cElh+kOvehuS7DFTzjqDwJlkQzP5Hq0G++hZxfdYocKdcdFoh
 RP3dtDAe+Lfiy9qzJicZ6ACbzoQIN58xj0VWAn1W7SuMErOjv84D/FiXHD2Kxtx09wQl8vH0
 Nbh9UgyDBNupToM0ixT+8Ko8eBuYHR53RPxshQhFw4EMIhXiOaxNe1W2Z95QPnYhUGOMoy3I
 v4fxMQUHa4kZSF2qxsFB1Cxol/aBPGwkwoqUvzp23pLQtJ6youYXtLgvx3pR4L52Q5CUzHMa
 HvM67XWgW1KqtnvNBXN9PwtDz/a9fQX1YO4CegrXv8C9Ro+LABEBAAHCwV8EGAECAAkFAlRj
 Vn0CGwwACgkQ79YUOj7yLS8rXA/9EGX2QRfJS94JTdtseu7saTK9a3IKwk6E33GpfXyUVpMt
 sOqV756XQwULZSWoxInRQtWojA8pQxDUYrbA4MpX0Efr2Dx1xIsJ5F3JajOqViB1SbOD2m0f
 bxXbcoWKitsKoag2SlvNOd8rD9FcgDvrkacnaQZcZE8DyyGx0JU451tfoD/igu85NZpTDaWG
 6fth7QRlxmdGWrGXRdXAP29jq1n0I1wIyF/bXlZ7MXjOSsfyPddzsnHFTvNMZKps0QXNF+hi
 ESg9chIeo/IFDDVu6pCtm6mftojx84rczTZiNk8r2T3TU4N8uwWtXn/nj9xd61pnxD0xkTPH
 zxJrCs59WSfYqj3aFNkWO3Lg0/HGnO9wHQKMXcGPsnKITHVzxCNBQtVHomNA7ds6Kt3/WJgS
 pU2ciICvrpvKgPNWQ0d/SeY3vYIRvDLZ12Svx6M3eXDrsgZOT5be7kGVr3t7dBOYKcRHkZUq
 kU1kCcgp0vetISVDOc5fkpdUkAtd5/13pIpz4ikVR3OM4Br4XMVShm6RvoP4pyA+ftCi1+bw
 0UbRCrnHgnG+wtCf5nMDGVLc04vITnII+ESZqlF02a1IFj0Z2MuQK2Oszl2Nsx/LG60G1e/R
 pzKEXIIJgHfbwUCWtV1zQu6v9Ng5H8EqVeWcdaPUwSQMGcDg/sPa4s/OxhgrYBg=
In-Reply-To: 
 <174118263504.762204.2843259903410910075@dt-datatracker-5dd67b77bb-4k4zh>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID-Hash: ZUMACZQ3VNG3IYUOAFTPKFB6UAU6ECP7
CC: draft-ietf-dnsop-generalized-notify@ietf.org, dnsop-chairs@ietf.org,
 dnsop@ietf.org, tjw.ietf@gmail.com, peter.van.dijk@powerdns.com
Precedence: list
Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-dnsop?=
	=?utf-8?q?-generalized-notify-07=3A_=28with_DISCUSS_and_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsop/4VolKVXx6Nz5O9AAkVC4vNaBQ9o>

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