On Wed, Mar 9, 2022 at 10:19 AM Joe Abley <[email protected]> wrote:
> On Mar 9, 2022, at 00:12, Shumon Huque <[email protected]> wrote: > > This document looks good. Some comments: >> >> In fact, the Extensible Provisioning >> Protocol (EPP) [RFC5731], that is often used by TLDs to configure >> delegation parameters has no provision to set the TTL. This inhibits >> a child zone owner's ability to make more rapid changes >> >> This is somewhat misleading. Even if EPP had the functionality, the >> parent zone would still want to set their own TTL to reasonable values >> for _their_ dpeloyment considerations. So the implication of the problem >> of "EPP cannot set TTL" is not really right. I would remove this text. >> > > The first sentence is fact. > > > Since the E in EPP stands for extensible, and since there's an active > community (an active ietf working group, even, with participants who are > registry operators) working on such extensions, I'm not sure the truth of > the first sentence is useful generally. > > in any case, I agree with Paul that the operator of a child zone generally > should have no expectation of being able to influence the TTL in the > delegation NS set (above the zone cut). > > I also think it makes sense just to remove this commentary. > Ok, I'm persuaded to remove the EPP mention. When a delegation response is received during iteration, a validation query should be sent in parallel with the resolution of > the triggering query > > "Referral response" not "delegation response" I think. Yes, that would be the more commonly used term. Will fix. Shumon.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
