jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: Proposed changes to QNAME text from  and others on the list .
RFC2308, however, has an alternate definition that puts the QNAME
in the answer (or series of answers) instead of the query.  It
defines QNAME as: "...the name in the query section of an answer,
or where this resolves to a CNAME, or CNAME chain, the data field
of the last CNAME.  The last CNAME in this sense is that which
contains a value which does not resolve to another CNAME."  This
definition has a certain internal logic, because of the way CNAME
substitution works and the definition of CNAME.  If a name server
does not find an RRset that matches a query, but it finds the same
name in the same class with a CNAME record, then the name server
"includes the CNAME record in the response and restarts the query
at the domain name specified in the data field of the CNAME
record."  (RFC1034 Section 3.6.2).  This is made explicit in the
resolution algorithm outlined in Section 4.3.2 of RFC1034, which
says to "change QNAME to the canonical name in the CNAME RR, and
go back to step 1" in the case of a CNAME RR.  Since a CNAME
record explicitly declares that the owner name is canonically
named what is in the RDATA, then there is a way to view the new
name (i.e. the name that was in the RDATA of the CNAME RR) as also
being the QNAME.
This creates a kind of confusion, however, because the answer to a
query that results in CNAME processing contains in the echoed
Question Section one QNAME (the name in the original query), and a
second QNAME that is in the data field of the last CNAME.  The
confusion comes from the iterative/recursive mode of resolution,
which finally returns an answer that need not actually have the
same owner name as the QNAME contained in the original query.
QNAME (original): The name actually sent in the Question
Section in the orignal query, which is always echoed in the
(final) reply in the Question Section when the QR bit is set to
1.
QNAME (effective): A name actually resolved, which is either
the name originally queried, or a name received in a CNAME
chain response.
QNAME (final): The name actually resolved, which is either the
name actually queried or else the last name in a CNAME chain
response.
Draft: draft-ietf-dnsop-terminology-bis-05

Commentary: Two definitions of In - bailiwick are unclear and seems the same . In - bailiwick name server names have two meanings . One is narrow and requires glue records . The other is wide and may have glue records . There are needs to distinguish two types of in - bailiwick name server names .   used NS Types as < in - domain / in - bailiwick / externalin OARC 26 .   proposed " in domain " , " sibing domain " , and " unrelated " . " unrelated " is out - of - bailiwick . I propose to add " in domain " and " sibling domain " , update " in - bailiwick " and add a description for " out - of - bailiwick " . If this proposal is reasonable , please improve the text and merge . 
 lgtm ( apart from the typo ) 
 I like the idea but still , this is sufficiently muddy area to warrant short example for each type . It will be great with examples and I will definitely support the new wording over the old one .
The antonym of in-bailiwick.
An adjective to describe a name server whose name is either
subordinate to or (rarely) the same as the zone origin.  In-
bailiwick name servers may have glue records in their parent zone
(using the first of the definitions of "glue records" in the
definition above).  'In-bailiwick' names are divided into two type
of name server names: 'in-domain' names and 'Sibling domain'
names.
An adjective to describe a name server whose name is either
subordinate to or (rarely) the same as the ownwer name of the NS
resource records.  In-domain name server name MUST have glue
records or name resolution fails.  For example, a delegation for
"child.example.com" may have "in-domain" name server name
"ns.child.example.com".
A name server's name that is either subordinate to or (rarely) the
same as the zone origin and not subordinate to or the same as the
owner name of the NS resource records.  Glue records for sibling
domains are allowed, but not necessary.  For example, a delegation
for "child.example.com" in "example.com" zone may have "Sibling"
name server name "ns.another.example.com".
The antonym of in-bailiwick.  An adjective to describe a name
server whose name is not subordinate to or the same as the zone
origin.  Glue records for out-of-bailiwick name servers are
useless.
Draft: draft-ietf-dnsop-terminology-bis-05

Commentary: Should n't that be " An ordered list of one or more labels " ? If not , I 'd like to see some text specifically addressing the zero - length case .
An ordered list of zero or more labels.
An ordered list of one or more labels.