Hi Joe This is a good idea. Some minor review comments below.
> 1. Introduction
> A resolver with an NTA in effect might send a response that
> ordinarily would have been suppressed because of validation failures.
> This document defines a new EDE that can be sent with a response to
Minor editorial nit: I suggest s/with/within/ or s/with/in/
> indicate that the response was subject to an active NTA.
> 3. Operational Considerations
> A resolver with multiple NTAs in place simultaneously MAY include
> multiple instances of this EDE in a single response, each
> representing a different NTA.
Is this so that the different EDE option instances may have different
EXTRA-TEXT values?
> The operator MAY use the EXTRA-TEXT field to add context about the
> NTA, such as the name at which it was configured, the reason it was
> put in place, a reference where more information can be found, or its
> expected duration. As noted in Section 2 of [RFC8914], EXTRA-TEXT is
> intended for human consumption; operators SHOULD keep it readable and
> SHOULD NOT include private or sensitive information. Structured data
> MAY be included in the EXTRA-TEXT field, as described in
> [I-D.ietf-dnsop-structured-dns-error].
I-D.ietf-dnsop-structured-dns-errors are only mean to be generated in
EDE options with specific INFO-CODEs {Filtered, Censored, Blocked}, and
they are further extended by the sub-codes in that draft (i.e., they
depend on the INFO-CODEs being in {Filtered, Censored, Blocked}.
Would it not be better or even more correct to seperate the
I-D.ietf-dnsop-structured-dns-error into a different EDE option, i.e.,
separate from the NTA EDE option?
Overall, nice and succinct.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
