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

Commentary: cc   : 
 This is an improvement over the existing text and is formally more correct , I think . That means , however , that it is technically a substantive change . I think it is not a substantive change that would make any difference to any DNSOP participant so I think this is ok without going back to the WG .
Note that this is a definition independent of the DNS RFCs, and
the definition here also applies to systems other than the DNS.
RFC1034 defines the "domain name space" using mathematical trees
and their nodes in graph theory, and this definition has the same
practical result as the definition here.  Using graph theory, a
domain name is a list of labels identifying a portion along one
edge of a directed acyclic graph.  A domain name can be relative
to parts of the tree, or it can be fully qualified (in which case,
it begins at the common root of the graph).
Note that this is a definition independent of the DNS RFCs, and
the definition here also applies to systems other than the DNS.
RFC1034 defines the "domain name space" using mathematical trees
and their nodes in graph theory, and this definition has the same
practical result as the definition here.  Any path of a directed
acyclic graph can be represented by a domain name consisting of
the labels of its nodes, ordered by decreasing distance from the
root(s) (which is the normal convention within the DNS, including
this document).  A domain name whose last label identifies a root
of the graph is fully qualified; other domain names whose labels
form a strict prefix of a fully qualified domain name are relative
to its first omitted node.
The need for the term "fully qualified domain name" comes from the
existence of partially qualified domain names, which are names
where one or more of the earliest labels in the ordered list are
omitted (for example, a name of "www" derived from
"www.example.net").  Such relative names are understood only by
context.
The need for the term "fully qualified domain name" comes from the
existence of partially qualified domain names, which are names
where one or more of the last labels in the ordered list are
omitted (for example, a domain name of "www" relative to
"example.net" identifies "www.example.net").  Such relative names
are understood only by context.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: I like the additional wording . I 'll add it and take the question to the chairs to take to the WG . 
 Good catch on " DNS over TLS " -"DNS over HTTPS " . I did n't go with " DNS Queries over HTTPS " because it does n't really describe the protocol . 
 Simple mistake : " DNS over TLS " should be " DNS over HTTPS " at line 1040 . Or " DNS Queries over HTTPS " may be better because it is a draft name . If we 're going to add class here , then I think ( 1 ) we need to go back to the WG and ( 2 ) we need to add something : " In practice , the class for nearly every query is IN . There are some queries for CH , but they are usually for the purposes of information about the server itself rather than for a different type of address " I wrote a doc some time ago attempting to deprecate class , because of the way it keeps popping up as though it is viable .
A class "identifies a protocol family or instance of a protocol"
(Quoted from RFC1034, Section 3.6).  "The DNS tags all data with a
class as well as the type, so that we can allow parallel use of
different formats for data of type address."  (Quoted from
RFC1034, Section 2.2).  In practice, the class for nearly every
query is "IN".  There are some queries for "CH", but they are
usually for the purposes of information about the server itself
rather than for a different type of address.
The domain name where a RR is found (RFC1034, Section 3.6).  Often
appears in the term "owner name".
"The domain name where a RR is found" (Quoted from RFC1034,
Section 3.6).  Often appears in the term "owner name".
"A DNS server that implements DNS over TLS RFC7858 and may
optionally implement DNS over DTLS RFC8094."  (Quoted from
RFC8310, Section 2) Other types of DNS servers might also be
considerd privacy-enabling, such as those running DNS over HTTPS
I-D.ietf-doh-dns-over-https.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: " each other " is clearer in English . I agree that " whole labels " is better and have changed the text . 
 At line 139 , " each other " may be " others " ? At line 358 , " full labels " may be " whole labels " or " each label " .
"A domain is a subdomain of another domain if it is contained
within that domain.  This relationship can be tested by seeing if
the subdomain's name ends with the containing domain's name."
(Quoted from RFC1034, Section 3.1).  For example, in the host name
"nnn.mmm.example.com", both "mmm.example.com" and
"nnn.mmm.example.com" are subdomains of "example.com".
"A domain is a subdomain of another domain if it is contained
within that domain.  This relationship can be tested by seeing if
the subdomain's name ends with the containing domain's name."
(Quoted from RFC1034, Section 3.1).  For example, in the host name
"nnn.mmm.example.com", both "mmm.example.com" and
"nnn.mmm.example.com" are subdomains of "example.com".  Note that
the comparisons here are done on whole labels; that is,
"ooo.example.com" is not a subdomain of "oo.example.com".
A server operating in recursive mode may be thought of as having a
name server side (which is what answers the query) and a resolver
side (which performs the resolution function).  Systems operating
in this mode are commonly called "recursive servers".  Sometimes
they are called "recursive resolvers".  While strictly the
difference between these is that one of them sends queries to
another recursive server and the other does not, in practice it is
not possible to know in advance whether the server that one is
querying will also perform recursion; both terms can be observed
in use interchangeably.
A server operating in recursive mode may be thought of as having a
name server side (which is what answers the query) and a resolver
side (which performs the resolution function).  Systems operating
in this mode are commonly called "recursive servers".  Sometimes
they are called "recursive resolvers".  In practice it is not
possible to know in advance whether the server that one is
querying will also perform recursion; both terms can be observed
in use interchangeably.
A specialized piece of hardware that is used to create keys for
signatures and to sign messages.  In DNSSEC, HSMs are often used
to hold the private keys for KSKs and ZSKs and to create the
signatures used in RRSIG records at periodic intervals.
A specialized piece of hardware that is used to create keys for
signatures and to sign messages without ever disclosing the
private key.  In DNSSEC, HSMs are often used to hold the private
keys for KSKs and ZSKs and to create the signatures used in RRSIG
records at periodic intervals.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: There is one typo at " Authoritative data : " . Other differences are OK . | < t < xref target="RFC4033"/ , Section 2 , defines " Authoritative RRset " which is related | to authoritative data [ bu ] has a more precise definition.</t("bu"is " but " ? ) 
 I missed to change branch and I commited to this branch . please review " " .
"Name Error - Meaningful only for responses from an authoritative
name server, this code signifies that the domain name referenced
in the query does not exist."  (Quoted from RFC1035,
Section 4.1.1.)  RFC2308 established NXDOMAIN as a synonym for
Name Error.
"Name Error - This code signifies that the domain name referenced
in the query does not exist."  (Quoted from RFC1035,
Section 4.1.1.)  RFC2308 established NXDOMAIN as a synonym for
Name Error.
A program "that extract[s] information from name servers in
response to client requests."  (Quoted from RFC1034, Section 2.4)
"The resolver is located on the same machine as the program that
requests the resolver's services, but it may need to consult name
servers on other hosts."  (Quoted from RFC1034, Section 5.1) A
resolver performs queries for a name, type, and class, and
receives answers.  The logical function is called "resolution".
In practice, the term is usually referring to some specific type
of resolver (some of which are defined below), and understanding
the use of the term depends on understanding the context.
A program "that extract[s] information from name servers in
response to client requests."  (Quoted from RFC1034, Section 2.4)
A resolver performs queries for a name, type, and class, and
receives answers.  The logical function is called "resolution".
In practice, the term is usually referring to some specific type
of resolver (some of which are defined below), and understanding
the use of the term depends on understanding the context.
A name server that only serves authoritative data and ignores
requests for recursion.  It will "not normally generate any
queries of its own.  Instead, it answers non-recursive queries
from iterative resolvers looking for information in zones it
serves."  (Quoted from RFC4697, Section 2.4) In this case,
"ignores requests for recursion" means "responds to requests for
recursion with responses indicating that recursion was not
performed".
RFC4033, Section 2, defines "Authoritative RRset" which is related
to authoritative data but has a more precise definition.
Like the NSEC record, the NSEC3 record also provides authenticated
denial of existence; however, NSEC3 records mitigate against zone
enumeration and support Opt-Out.  NSEC resource records require
associated NSEC3PARAM resource records.  NSEC3 and NSEC3PARAM
resource records are defined in RFC5155.
Like the NSEC record, the NSEC3 record also provides authenticated
denial of existence; however, NSEC3 records mitigate against zone
enumeration and support Opt-Out.  NSEC3 resource records require
associated NSEC3PARAM resource records.  NSEC3 and NSEC3PARAM
resource records are defined in RFC5155.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: In the " TTL " section this appears : Also , if a value is flushed from the cache when its value is still positive , the value effectively becomes zero . ( 1 ) Does n't make sense to flush a value . I think the intention was to say " if an RRSet is flushed ... " ( 2 ) nitpick : " when its value is still positive " sounds like maybe it makes assumptions about the way that caches work . It sounds like the TTL is decremented and updated in the cache over time . Something like " the end of the TTL interval " may be better . ( 3 ) I 'm not quite sure what " effectively becomes zero " means for data that has been flushed . If its flushed its gone or at least not usable again in the future .
The reason that the TTL is the maximum time to live is that a
cache operator might decide to shorten the time to live for
operational purposes, such as if there is a policy to disallow TTL
values over a certain number.  Also, if a value is flushed from
the cache when its value is still positive, the value effectively
becomes zero.  Some servers are known to ignore the TTL on some
RRsets (such as when the authoritative data has a very short TTL)
even though this is against the advice in RFC 1035.
The reason that the TTL is the maximum time to live is that a
cache operator might decide to shorten the time to live for
operational purposes, such as if there is a policy to disallow TTL
values over a certain number.  Some servers are known to ignore
the TTL on some RRsets (such as when the authoritative data has a
very short TTL) even though this is against the advice in RFC
1035.  An RRset can be flushed from the cache before the end of
the TTL interval, at which point the value of the TTL becomes
unknown because the RRset with which it was associated no longer
exists.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: In May , 2015 ,   noted that the definition of " referral " in the current draft at the time was not good . He said : It would be good to review the current definition and make improvements if necessary . 
 Fixed with PR
Data from the authority section of a non-authoritative answer.
RFC1035 Section 2.1 defines "authoritative" data.  However,
referrals at zone cuts (defined in zones) are not authoritative.
Referrals may be zone cut NS resource records and their glue
records.  NS records on the parent side of a zone cut are an
authoritative delegation, but are normally not treated as
authoritative data.  In general, a referral is a way for a server
to send an answer saying that the server does not know the answer,
but knows where the query should be directed in order to get an
answer.  Historically, many authoritative servers answered with a
referral to the root zone when queried for a name for which they
were not authoritative, but this practice has declined.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: Added text to in - bailiwick and examples
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.
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.  Following table shows examples of delegation types.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: The current definition says : The example is ambiguous . It should instead say : 
 PR is at 
 FWIW I still find it confusing . proposed alternative : The need for the term " fully qualified domain name " comes from the existence of partially qualified domain names , which are names where one or more of the later labels in the desired name are omitted . For example , a user may enter " www " and rely on the application or operating system to append an appropriate domain suffix , turning it into " " . Such partially qualified names are understood only by context . 
 Hi , I ’m a bit confused by “ earliest ” and “ latest ” here —  ’s wording ( " earliest labels in the ordered list ” ) made sense to me but  changed it ( to “ later labels in the desired list ” ) . I ’d suggest making it explicitly refer to " earlier labels in the ordering of nodes from the root of the tree , ” because otherwise “ earlier ” or “ later ” both make my head hurt .  
 My thinking was that as I read the name ( e.g. left - to - right ) the " www " part is earliest and the " " part is later . The way we talk about ordering of labels seems sort of fundamental and it would be a shame to have it buried in this one definition of FQDN . Its not really a terminology issue , but is there some way to make it more prominent and apply to the document as a whole ? 
 Understood , was just thinking that it ’s not obvious whether we mean reading order or evaluation order or something else unless we say so . Had n't thought of it , but yes . This is where I ’m reminded there ’s not really a definition of “ domain name ” out there to incorporate . There ’s been a proposed definition kicking around for awhile , which was briefly discussed somewhere ( the arcing list ? ) and I tried to get   to add to draft - lewis - domain - name . I do n’t think this document is the place to propose one not previously found in an RFC , although I ’d be fine with the WG considering the question if the editors disagree . Suzanne 
 There is in fact a definition of " domain name " to incorporate . Under " Global DNS " , it says : We use " first " there , and we use it in a way that is the opposite of " earliest " in the current wording for FQDN , and thus the need for change .  's proposal is better than what we have now , but we can maybe even do better . How about :
The need for the term "fully qualified domain name" comes from the
existence of partially qualified domain names, which are names
where one or more of the earliest labels in the ordered list are
omitted (for example, "www").  Such relative names are understood
only by context.
The need for the term "fully qualified domain name" comes from the
existence of partially qualified domain names, which are names
where one or more of the earliest labels in the ordered list are
omitted (for example, a name of "www" derived from
"www.example.net").  Such relative names are understood only by
context.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: I have your text ( approximately ) and merged the pull request . 
 During the discussion that led to RFC 7719 , there was a request to split out error names in their own terms to make them easier to find in the document . Now with the index in place , this seems like a good idea . 
 Oooh , yes , I think that this would be great . [ Sorry for the non - substantive / bikeshed comment ] 
 Entered in the doc as 
 I think this is ok , but I 'd like a tiny edit before the list starts : " The names as of this writing are described below , but the official list is in the IANA registry . " Or something like this . I just do n't want to suggest we 're arguing with the authoritative registry .
Some of response codes that are defined in RFC1035 have acquired
their own shorthand names.  Some common response code names that
appear without reference to the numeric value are "FORMERR",
"SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to
as "Name Error").  All of the RCODEs are listed at
http://www.iana.org/assignments/dns-parameters, although that site
uses mixed-case capitalization, while most documents use all-caps.
Some of response codes that are defined in RFC1035 have acquired
their own shorthand names.  All of the RCODEs are listed at
http://www.iana.org/assignments/dns-parameters, although that site
uses mixed-case capitalization, while most documents use all-caps.
Some of the names are described here, but the official list is in the
IANA registry.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: … erative resolution 
 Agree with your fix to the definition . 
 During the lead - up to RFC 7719 ,   asked for four terms to be defined : Recursive query Non - recursive query Iterative query Iterative resolution The were not in RFC 7719 but could be in the -bis . 
 Updated the document in 
 I do n't think iterative query is a synonym . I think an iterative query is a non - recursive query that happens to be a query in a series of recursive queries but that is itself not a recursive query . No ? That seems more consistent with the iterative resolution definition that follows .
Synonym for non-recursive query that happens to be a query in a
series of recursive queries, but that is itself not a recursive
query.  This term is used in a number of RFCs though never
explicitly defined.
In iterative resolution, the client repeatedly makes non-recursive
queries and follows referrals and/or aliases.  The iterative
resolution algorithm is described in Section 5.3.3 of RFC1034.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: In June 2015 ,   said : I think that " superordinate " and " subordinate " might be worth mentioning here , with reference to their definitions in EPP . 
 Added in 
 I think this is ok . Friendly amendment is to note that these are strictly ways of referring to the relationship standing of two domains where one is a subdomain of the other . ( But I do n't know that we need to do this , hence the approval . )
These terms are introduced in RFC3731 but not defined there.
Instead, they are given in examples.  "For example, domain name
'example.com' has a superordinate relationship to host name
ns1.example.com'."  "For example, host ns1.example1.com is a
subordinate host of domain example1.com, but it is a not a
subordinate host of domain example2.com."  (Quoted from RFC3731,
Section 1.1.)  These terms are strictly ways of referring to the
relationship standing of two domains where one is a subdomain of
the other.
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: … empt to define " resolve " and " resolution " . 
 This issue concerns consistency and definition of some terms in the document . " Name server " , " name server " and , perhaps , " server " seem to be used interchangeably . None of those terms have a formal definition in the document . The terms are also used in conjunction with various modifiers like " authoritative server " , " DNS server " , etc . While all those terms are likely pretty well - known , for the purposes of this document , un my opinion , it would be helpful to give a generic definition of " server " , and how it is then combined with modifiers to form terminology for specific types of servers . Based on the definition of " server " , it would be helpful to include a definition for " name server " , " name server " or " DNS server " ( pick one ) and then use that term uniformly throughout the document . 
 Added a note about this in 
 Fixed in 
 These are common terms that are used in contexts that are not always associated with the resolver itself , so they should have stand - alone definitions . 
 First attempt at definition in
This section defines the terms used for the systems that act as DNS
clients, DNS servers, or both.
This section defines the terms used for the systems that act as DNS
clients, DNS servers, or both.  In the RFCs, DNS servers are
sometimes called "name servers", "nameservers", or just "servers".
There is no formal definition of DNS server, but the RFCs generally
assume that it is an Internet server that listens for queries and
sends responses using the DNS protocol defined in RFC1035 and its
successors.
A related term is "resolve", which is not formally defined in
RFC1034 or RFC1035.  An imputed definition might be "asking a
question that consists of a domain name, class, and type, and
receiving some sort of answer".  Similarly, an imputed definition
of "resolution" might be "the answer received from resolving".
Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: I have been unable to find a definition of " insecure delegation " , but it is a term in common use . The closest I found was some handwaving in the NSEC3 doc . Perhaps worth adding ? [ Feel free to close issue if inappropriate , etc . ] 
 We should define it . It appears starting in RFC 4956 . The definition there is : That seems fine to me 
 Fixed in
None.