> On Sep 7, 2023, at 2:32 AM, Zaheduzzaman Sarker via Datatracker
> <nore...@ietf.org> wrote:
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for working on this specification. My review does yield any TSV related
> issues.
>
> I have following minor comments that I believe will improve the document
> quality when addressed -
>
> # While this specification updates RFC2308, RFC4038 and RFC4697, the
> Introduction section only mentions RFC2308. Would be good to give emphasis on
> all the updates.
Good catch, this has been updated.
>
> # Regarding Motivation section, I like the motivation section up front and
> understanding of the problem to solve before going into solution description.
> So I would like to keep this section where it is.
Thank you.
>
> # Section 2 says -
>
> If any one of the available servers provides a useful response, then it
> is not considered a resolution failure.
>
> with that I am not sure why responses in section 2.1 and 2.2 are qualified
> as useful responses. Please add some clarification texts in those sections.
The types of responses described in 2.1 (SERVFAIL) and 2.2 (REFUSED) should not
be
considered “useful”. Rather they are NOT useful because they neither provide
the
requested data, a referral, nor indicate that the requested data does not exist.
Since the meaning of useful might not be as clear as it could be, we would
propose to
add this to the opening paragraph of section 2:
A response is considered
useful when it provides either the requested data, a delegation a
descendant zone,
or an indication that no data exists at the given name.
Does that clear up the confusion?
DW
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
