Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-02.txt

[Shumon Huque <[e-mail]>]

On Wed, Mar 9, 2022 at 10:19 AM Joe Abley <[e-mail]> wrote:

> On Mar 9, 2022, at 00:12, Shumon Huque <[e-mail]> 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.