[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-generalized-notify
> From: Matthijs Mekking > I would use city.ise.mie.example instead, unless you have confirmation > that JPRS is fine with using .jp as an example here. JP domain names have second-level, third-level, and fourth-level delegations, but are provided through a single jp zone. The structure of jp domain names is also published in the public suffix list. Personally, I think it's okay to write down domain names that are known to exist, as they are public information, and since they are written in the draft, I don't think the impact would be much different if they were written in the RFC. What concerns me is that Ise City is not a very large local government, and I don't think that being listed in the RFC will result in storange quiries, but there may be people who are concerned about it. These area third-level examples, but I think "jprs.co.jp" or "wide.ad.jp" would be able to handle any issues. # Other ccTLDs also have fourth-level delegations. # For example: cnri.reston.va.us -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-generalized-notify
Okay, that sounds like confirmation to me. All good then! On 10-01-2025 11:29, Kazunori Fujiwara wrote: From: Matthijs Mekking I would use city.ise.mie.example instead, unless you have confirmation that JPRS is fine with using .jp as an example here. JP domain names have second-level, third-level, and fourth-level delegations, but are provided through a single jp zone. The structure of jp domain names is also published in the public suffix list. Personally, I think it's okay to write down domain names that are known to exist, as they are public information, and since they are written in the draft, I don't think the impact would be much different if they were written in the RFC. What concerns me is that Ise City is not a very large local government, and I don't think that being listed in the RFC will result in storange quiries, but there may be people who are concerned about it. These area third-level examples, but I think "jprs.co.jp" or "wide.ad.jp" would be able to handle any issues. # Other ccTLDs also have fourth-level delegations. # For example: cnri.reston.va.us -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-generalized-notify
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
