jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-dnsop-glue-is-not-optional

Commentary: idnits mentions this : -- Obsolete informational reference ( is this intentional ? ): RFC 2845 ( Obsoleted by RFC 8945 )
DNS responses sometimes contain optional data in the additional
section.  In-domain glue records, however, are not optional.  Several
other protocol extensions, when used, are also not optional.  This
includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931.
DNS responses sometimes contain optional data in the additional
section.  In-domain glue records, however, are not optional.  Several
other protocol extensions, when used, are also not optional.  This
includes TSIG RFC8945, OPT RFC6891, and SIG(0) RFC2931.
Draft: draft-ietf-dnsop-glue-is-not-optional

Commentary: Minor nit
client SHOULD use another transport retrieve the full response.  This
document clarifies that expectation.
client SHOULD use another transport to retrieve the full response.
This document clarifies that expectation.
Draft: draft-ietf-dnsop-glue-is-not-optional

Commentary: … out presence of glue in zones . 
 No further discussion on list nor here so I will merge this . 
 From the dnsop list ,   suggests the draft could more clearly state that a name server might provide an " incorrect " response because it was n't given necessary glue records in the zone data .
Note that this document only clarifies requirements of name server
software implementations.  It does not change any requirements on
data placed in DNS zones or registries.
Note that this document only clarifies requirements of name server
software implementations.  It does not introduce or change any
requirements on data placed in DNS zones or registries.  In other
words, this document only makes requirements on "available glue
records" (i.e., those given in a zone), but does not make
requirements regarding their presence in a zone.  If some glue
records are absent from a given zone, an authoritative name server
may be unable to return a useful referral response for the
corresponding domain.  The IETF may want to consider a separate
update to the requirements for including glue in zone data, beyond
those given in RFC1034 and RFC1035.
Draft: draft-ietf-dnsop-glue-is-not-optional

Commentary: LGTM despite the attempts at confusion with :)
At the time of writing, most iterative clients send initial queries
over UDP and retry over TCP upon receiving a response with the TC
flag set.  UDP responses are generally limited to between 1232 and
4096 bytes, due to values commonly used for the EDNS0 UDP Message
Size field RFC6891, FLAGDAY2020.  TCP responses are limited to 65,536
bytes.
At the time of writing, most iterative clients send initial queries
over UDP and retry over TCP upon receiving a response with the TC
flag set.  UDP responses are generally limited to between 1232 and
4096 bytes, due to values commonly used for the EDNS0 UDP Message
Size field RFC6891, FLAGDAY2020.  TCP responses are limited to 65,535
bytes.
The authors wish to thank Joe Abley, Brian Dickson, Geoff Huston,
Jared Mauch, George Michaelson, Benno Overeinder, John R Levine,
Shinta Sato, Puneet Sood, Ralf Weber, Tim Wicinski, Suzanne Woolf,
and other members of the DNSOP working group for their input.
The authors wish to thank Joe Abley, Brian Dickson, Geoff Huston,
Jared Mauch, George Michaelson, Yasuhiro Orange Morishita, Benno
Overeinder, John R Levine, Shinta Sato, Puneet Sood, Ralf Weber, Tim
Wicinski, Suzanne Woolf, and other members of the DNSOP working group
for their input.
Draft: draft-ietf-dnsop-glue-is-not-optional

Commentary: work in progress . please do not merge without review & discussion . 
 Should we use the naming for Glue from 8499 ? 
 " Sibling domain glue " " in - domain glue " and maybe we should define " orphan glue / promoted glue " . while we have 8499bis open ? 
 IMO 8499 does n't have glue definitions that are useful for this draft , so yeah , maybe they should be to 8499 .
This section describes different types of glue that may be found in
DNS referral responses.  Note that the type of glue depends on the
QNAME.  A particular record can be in-domain glue for one response
and sibling glue for another.
Sibling glue are glue records that are not contained in the delegated
zone itself, but in another delegated zone from the same parent.  In
many cases, these are not strictly required for resolution, since the
resolver can make follow-on queries to the same zone to resolve the
nameserver addresses after following the referral to the sibling
zone.  However, most nameserver implementations today provide them as
an optimization to obviate the need for extra traffic from iterative
resolvers.
This document clarifies that when a name server generates a referral
response, it MUST either include all in-domain glue records in the
additional section, or MUST set TC=1.
This document clarifies that when a name server generates a referral
response, it SHOULD include available sibling glue records in the
additional section.  If sibling glue records do not fit in the
response, the name server is NOT REQUIRED to set TC=1.
Promoted glue is a special case of sibling glue and should be treated
as such.
Draft: draft-ietf-dnsop-glue-is-not-optional

Commentary: For issue . 
 A colleague asked me to clarify that the document applies only to name server behavior , and does not place any requirements on how zones or registries are populated . i.e. , we are not saying that " glue is not optional " for delegations in a zone . 
 This was done with commit
The DNS uses glue records to allow iterative clients to find the
addresses of nameservers that are contained within a delegated zone.
Authoritative Servers are expected to return all available glue
records in referrals.  If message size constraints prevent the
inclusion of all glue records in a UDP response, the server MUST set
the TC flag to inform the client that the response is incomplete, and
that the client SHOULD use TCP to retrieve the full response.
The DNS uses glue records to allow iterative clients to find the
addresses of nameservers that are contained within a delegated zone.
Authoritative Servers are expected to return all available glue
records in referrals.  If message size constraints prevent the
inclusion of all glue records in a UDP response, the server MUST set
the TC flag to inform the client that the response is incomplete, and
that the client SHOULD use TCP to retrieve the full response.  This
document updates RFC 1034 to clarify correct server behavior.
Note that this document only clarifies requirements of name server
software implementations.  It does not place any requirements on data
placed in DNS zones or registries.
Draft: draft-ietf-dnsop-glue-is-not-optional

Commentary: Clarify glue , slightly reorder . 
 Merging - as mentioned in email , I will also add a more typical case of sibling glue ( that does n't involve cross zone and circular dependency ) . PR forthcoming ...
While not common, real life examples of servers that fail to set TC=1
when glue records are available exist and they do cause resolution
failures.  The example below from June 2020 shows a case where none
of the glue records, present in the zone, fitted into the available
space and TC=1 was not set in the response.  While this example shows
an DNSSEC RFC4033, RFC4034, RFC4035 referral response, this behaviour
has also been seen with plain DNS responses as well.  The records
have been truncated for display purposes.  Note that at the time of
this writing, this configuration has been corrected and the response
correctly sets the TC=1 flag.
This document clarifies correct DNS server behaviour expectations and
does not introduce new security considerations.
While not common, real life examples of servers that fail to set TC=1
when glue records are available exist and they do cause resolution
failures.
The example below from June 2020 shows a case where none of the glue
records, present in the zone, fitted into the available space and
TC=1 was not set in the response.  While this example shows an DNSSEC
RFC4033, RFC4034, RFC4035 referral response, this behaviour has also
been seen with plain DNS responses as well.  The records have been
truncated for display purposes.  Note that at the time of this
writing, this configuration has been corrected and the response
correctly sets the TC=1 flag.
A zone's sibling glue is glue in another zone that is required for
proper resolving.  While the example below is obvious, real life
examples can be more complex and not obvious.
This situation is harder to detect if the sibling zones are nog
hosted on the same nameservers.
When a zone is deleted but the parent notices that its NS glue
records are required for other zones, it MAY opt to take these (now
orphaned) glue records into its own zone to ensure that other zones
depending on this glue are not broken.  Technically, these NS records
are no longer glue records, but authorative data of the parent zone,
and should be added to the DNS response similarly to regular glue
records.
This document clarifies correct DNS server behaviour and does not
introduce any changes or new security considerations.
Draft: draft-ietf-dnsop-glue-is-not-optional

Commentary: yeah my bad . what s the right way to do comments ? DW
The DNS uses glue records to allow iterative clients to find the
addresses of nameservers that live within the delegated zone.  Glue
records are expected to be returned as part of a referral and if they
cannot be fitted into the UDP response, TC=1 MUST be set to inform
the client that the response is incomplete and that TCP SHOULD be
used to retrieve the full response.
The Domain Name System (DNS) RFC1034, RFC1035 uses glue records to
allow iterative clients to find the addresses of nameservers that
live within the delegated zone.  Glue records are expected to be
returned as part of a referral and if they cannot be fitted into the
UDP response, TC=1 MUST be set to inform the client that the response
is incomplete and that TCP SHOULD be used to retrieve the full
response.
The DNS uses glue records to allow iterative clients to find the
addresses of nameservers that are contained within a delegated zone.
Servers are expected to return available glue records in referrals.
If message size constraints prevent the inclusion of glue records in
a UDP response, the server MUST set the TC flag to inform the client
that the response is incomplete, and that the client SHOULD use TCP
to retrieve the full response.
The Domain Name System (DNS) RFC1034, RFC1035 uses glue records to
allow iterative clients to find the addresses of nameservers that are
contained within a delegated zone.  Servers are expected to return
available glue records in referrals.  If message size constraints
prevent the inclusion of glue records in a UDP response, the server
MUST set the TC flag to inform the client that the response is
incomplete, and that the client SHOULD use TCP to retrieve the full
response.
Glue records are added to the parent zone as part of the delegation
process.  They are expected to be returned as part of a referral and
if they can't fit in a UDP response TC=1 MUST be set to signal to the
client to retry over TCP.  This document reinforces that expectation.
This document reinforces correct DNS server behaviour expectations
and does not introduce new security considerations.
This document clarifies correct DNS server behaviour expectations and
does not introduce new security considerations.