Late to the party, but I also support this draft. I read the latest
version and I like it. Some comments below. Apologies if there are
duplicate comments.
Best regards,
Matthijs
Section 2.1
-----------
I notice that notifies for DNSKEY have been removed since the initial
implementation. I guess that is fine, since we can specify it in a
follow-up document, and the current specification allows for extension.
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?
Section 4.1
-----------
1. "Construct the lookup name, by injecting the _dsync label after the
first label of the delegation owner name."
Okay, this is technically correct, but let me say that I was confused by
"delegation owner name". I read it as the owner that delegates your
zone, a.k.a. the parent. Probably because "delegation name" or
"delegation owner name" is not something frequently used.
I was going to comment that some clarification was needed how to find
the delegation owner name, but then I read step 3 and that sort of does
the same thing.
Anyway, many words for something that probably does not require a change.
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".
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.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
