Hi Peter,
On 09-01-2025 21:31, Peter Thomassen wrote:
Hi Matthijs,
Thank you for your helpful review! Please find some responses below:
On 1/9/25 14:09, Matthijs Mekking wrote:
Section 3
---------
"There MUST NOT be more than one DSYNC record for each combination of
rrtype and scheme."
I wonder what the argument is for this. Doesn't this prevent
redundancy and failover for notification targets?
The argument is that if there are several, then there are several ways
to handle that (use all? pick one? try sequentially? which sequence?).
The question of how to handle this situation was raised in the Dnsdir
review [1]. The authors figured that regardless of which strategy is
specified, sender implementations would most likely not implement that
complexity, but try the "first", and fire and forget. It seemed that
simplicity would lead to more reliable operation in this case.
[1]:
https://mailarchive.ietf.org/arch/msg/dnsop/LFsvddryRr-aYM3BTGyo7My1bD0/
Fair enough.
2. "If a DSYNC RRset results, return it."
This reads weird. I guess something like "If there is a validated
positive DSYNC answer, return it".
Fixed. ("If a positive DSYNC answer results, return it.")
Thanks.
The example in step 3 uses city.ise.mie.jp, but there are domain names
reserved for documentation purposes ("example.", "example.com.",
"example.net.", "example.org.", and any names falling within those
domains), so let's use one of these for the example.
Opinions differ; others found that particular example very useful [2].
We picked this because it is very illustrative, and because the
existence of reserved example names does imply that one cannot use other
examples. However, we're open to replacing the example; it would be
great if you could in this case suggest some text. (I did not manage to
come up with one that's equally instructive.)
[2]:
https://mailarchive.ietf.org/arch/msg/dnsop/6NRRI-p4Xsw0p9UVNIGuAuxhqQ0/
I would use city.ise.mie.example instead, unless you have confirmation
that JPRS is fine with using .jp as an example here.
(Perhaps you picked this domain name because it is a real world case of
a delegation with empty non-terminals, but it is not guaranteed that
this will always be the case anyway).
Best regards, Matthijs
Thanks again,
Peter + co-authors
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
