jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-add-split-horizon-authority

Commentary: looks great with  's suggested shortening .
To establish its authority over some DNS zone, a participating
network MUST offer one or more encrypted resolvers via DNR I-D.ietf-
add-dnr, DDR I-D.ietf-add-dnr, or an equivalent mechanism (see vpn).
If the encrypted resolver is identified by name (e.g., DNR), at least
one of these resolvers' Authentication Domain Names (ADNs) MUST
appear in an NS record for that zone.  If the encrypted resolver is
identified by IP address (e.g., DDR), then Verified Discovery is
performed (Section 4.2 of I-D.ietf-add-ddr) and at least one of the
subjectAltName entries in the resolver certificate MUST appear in an
NS record for that zone.  This arrangement establishes this
resolver's authority over the zone.
To establish its authority over some DNS zone, a participating
network MUST offer one or more encrypted resolvers via DNR I-D.ietf-
add-dnr, DDR I-D.ietf-add-dnr, or an equivalent mechanism (see vpn).
If the encrypted resolver is identified by name (e.g., DNR), at least
one of these resolvers' Authentication Domain Names (ADNs) MUST
appear in an NS record for that zone.  If the encrypted resolver is
identified by IP address (e.g., DDR), then Verified Discovery is
performed (Section 4.2 of I-D.ietf-add-ddr) and at least one of the
subjectAltName entries in the resolver certificate MUST appear in an
NS record for that zone.  If the encrypted resolver is discovered
using the opportunistic discovery method (Section 4.3 of I-D.ietf-
add-ddr) and resolver certificate is validated based on PKI, at least
one of the subjectAltName entries in the resolver certificate MUST
appear in an NS record for that zone.  This arrangement establishes
this resolver's authority over the zone.
Draft: draft-ietf-add-split-horizon-authority

Commentary: Update looks good to me .
All of the special-use domain names registered with IANA IANA-SUDN,
most notably ".home.arpa", "resolver.arpa.", "ipv4only.arpa." and
".local", are never unique to a specific DNS server's authority.
Thus, these domain names are outside the scope of this document and
MUST NOT be validated using the mechanism described in this document.
A DNS client implementation will continue to follow the special
treatment defined for those special-use domain names.
All of the special-use domain names registered with IANA IANA-SUDN,
most notably ".home.arpa", "resolver.arpa.", "ipv4only.arpa." and
".local", are never unique to a specific DNS server's authority.  All
special-use domain names are outside the scope of this document and
MUST NOT be validated using the mechanism described in this document.
Draft: draft-ietf-add-split-horizon-authority

Commentary: accommodate DDR better accommodation for DDR
To establish its authority over some DNS zone, a participating
network MUST offer one or more encrypted resolvers via DNR I-D.ietf-
add-dnr or an equivalent mechanism (see vpn).  At least one of these
resolvers' Authentication Domain Names (ADNs) MUST appear in an NS
record for that zone.  This arrangement establishes this resolver's
authority over the zone.
To establish its authority over some DNS zone, a participating
network MUST offer one or more encrypted resolvers via DNR I-D.ietf-
add-dnr, DDR I-D.ietf-add-dnr, or an equivalent mechanism (see vpn).
If the encrypted resolver is identified by name (e.g., DNR), at least
one of these resolvers' Authentication Domain Names (ADNs) MUST
appear in an NS record for that zone.  If the encrypted resolver is
identified by IP address (e.g., DDR), then Verified Discovery is
performed (Section 4.2 of I-D.ietf-add-ddr) and at least one of the
subjectAltName entries in the resolver certificate MUST appear in an
NS record for that zone.  This arrangement establishes this
resolver's authority over the zone.
Draft: draft-ietf-add-split-horizon-authority

Commentary: From   : From   : 
 Do you think this is a client configuration that we should reasonably expect ? It seems to me that that behavior would be quite strange , although it is permissible . I think it 's probably clearer for our examples to represent common configurations . 
 Can we discuss it separately ? This PR is for changes in response to feedback in the ADD adoption thread . Do you approve of this PR for that purpose ? Perhaps you can open a new PR if you would like to add more example text . 
 Yes , changes look good to me . Works for me . I proposed this text to address the comment from the WG on whether client implementations will enable DNSSEC to support the proposed mechanism .
This document makes use of the terms defined in RFC8499.  The term
"Global DNS" is defined in RFC8499.
'Encrypted DNS' refers to a DNS protocol that provides an encrypted
channel between a DNS client and server (e.g., DoT, DoH, or DoQ).
The term 'Validated Split-Horizon' is also defined.
A split horizon configuration for some name is considered "validated"
if the network client has confirmed that a parent of that name has
authorized the local network to serve its own responses for that
name.  Such authorization generally extends to the entire subtree of
names below the authorization point.
The client sends the NS query to a pre-configured resolver that is
external to the network, over a secure transport.  Clients SHOULD
apply whatever acceptance rules they would otherwise apply when using
this resolver (e.g. checking the AD bit, validating RRSIGs).
This method applies only if the client is already configured with a
default resolution strategy that sends queries to a resolver outside
of the network over a secure transport.  That resolution strategy is
considered "tamperproof" because any actor who could modify the NS
response could already modify all of the user's other DNS responses.
To ensure that this assumption holds, clients MUST NOT relax the
acceptance rules they would otherwise apply when using this resolver.
For example, if the client would check the AD bit or validate RRSIGs
locally when using this resolver, it must also do so when resolving
NS records for this purpose.