jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-dnssec-chain-extension-07

Commentary: by middleboxes
This draft describes a new TLS RFC5246 TLS13 extension for transport
of a DNS record set serialized with the RFC4034 needed to
authenticate that record set.  The intent of this proposal is to
allow TLS clients to perform DANE Authentication RFC6698 RFC7671 of a
TLS server without performing additional DNS record lookups and
incurring the associated latency penalty.  It also provides the
ability to avoid potential problems with TLS clients being unable to
look up DANE records because of an interfering or broken middlebox on
the path between the client and a DNS server.  And lastly, it allows
a TLS client to validate the server's DANE (TLSA) records itself
without needing access to a validating DNS resolver to which it has a
secure connection.
This draft describes a new TLS RFC5246 TLS13 extension for transport
of a DNS record set serialized with the RFC4034 needed to
authenticate that record set.  The intent of this proposal is to
allow TLS clients to perform DANE Authentication RFC6698 RFC7671 of a
TLS server without performing additional DNS record lookups and
incurring the associated latency penalty.  It also provides the
ability to avoid potential problems with TLS clients being unable to
look up DANE records because of an interfering or broken middlebox on
the path between the client and a DNS server HAMPERING.  And lastly,
it allows a TLS client to validate the server's DANE (TLSA) records
itself without needing access to a validating DNS resolver to which
it has a secure connection.
Draft: draft-ietf-tls-dnssec-chain-extension-07

Commentary: Remove statement that the document describes the data structure in sufficient detail for implementers and describe more clearly how individual RRsets and the successive RRSig record set are identified by referencing the relevant sections in RFC 's ; and remove the in response to    DISCUSS point : IMPORTANT : I 'm not sure that this is actually sufficient to allow an independent implementation without referring to the other documents . I mean , I think I pretty clearly ca n't validate this chain from the above . Similarly , although I think this is enough to break apart the RRSETs into RRs , it does n't tell me how to separate the RRSETs from each other . I think you need to either make this a lot more complete or alternately stop saying it 's sufficient .
This sequence of native DNS wire format records enables easier
generation of the data structure on the server and easier
verification of the data on client by means of existing DNS library
functions.  However this document describes the data structure in
sufficient detail that implementers if they desire can write their
own code to do this.
This sequence of native DNS wire format records enables easier
generation of the data structure on the server and easier
verification of the data on client by means of existing DNS library
functions.
Draft: draft-ietf-tls-dnssec-chain-extension-04

Commentary: Small tweak to text to make clearer that validation RRsets can be in any order .
The subsequent RRsets MUST contain the full sequence of DNS records
needed to authenticate the TLSA record set from the server's trust
anchor.  Typically this means a sequence of DNSKEY and DS RRsets that
cover all zones from the target zone containing the TLSA record set
to the trust anchor zone.
The subsequent RRsets MUST contain the full set of DNS records needed
to authenticate the TLSA record set from the server's trust anchor.
Typically this means a set of DNSKEY and DS RRsets that cover all
zones from the target zone containing the TLSA record set to the
trust anchor zone.  The TLS client should be prepared to receive this
set of RRsets in any order.
Draft: draft-shore-tls-dnssec-chain-extension-02

Commentary: CHAINQUERY is now .
In the future, proposed DNS protocol enhancements, such as the
CHAINQUERY may offer easy ways to obtain all of the chain data in one
transaction with an upstream DNSSEC aware recursive server.
In the future, proposed DNS protocol enhancements, such as the
RFC7901 may offer easy ways to obtain all of the chain data in one
transaction with an upstream DNSSEC aware recursive server.