jiebi/TextFlow huggingface dataset:
Original text:
14 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> 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. 2.1. 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. </del>  3. 6.1. <del> 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). </del>  6.2.

Reviewer comments:
From Paul Wouters: From Michael Richardson:
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.
NAME 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.

Revised text:
14 RFC8174 when, and only when, they appear in all capitals, as shown here.  <ins> This document makes use of the terms defined in RFC8499, e.g. "Global DNS".  The following additional terms are used throughout the document: </ins> 3. 6.1.  <ins> 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. </ins> 6.2.
Original text:
Names are formed using Port-Prefix Naming (SVCB Section 2.3).  For example, a DNS service identified by the name "dns1.example.com" and (unusually) the non-default port number 5353 would be represented as <del> "_5353._dns.dns1.example.com.". </del>  4.

Reviewer comments:
Hey Ben, I know the SVCB spec defines this clearly, but I hope you'll feel that this additional sentence strikes a nice balance that can help future readers that, like me, had to dig a bit to un-confuse themselves. Regards, Peter van Dijk
Thanks for the clarification!

Revised text:
Names are formed using Port-Prefix Naming (SVCB Section 2.3).  For example, a DNS service identified by the name "dns1.example.com" and (unusually) the non-default port number 5353 would be represented as  <ins> "_5353._dns.dns1.example.com.".  A DNS service using the default port number of 53 would be represented as "_dns.dns1.example.com.". </ins> 4.
Original text:
5.1. "dohpath" is a single-valued SvcParamKey whose value (both in <del> presentation and wire format) MUST be a URI Template RFC6570 encoded in UTF-8 RFC3629.  If the "alpn" SvcParam indicates support for HTTP, "dohpath" MUST be present.  The URI Template MUST contain a "dns" variable, and MUST be chosen such that the result after DoH template expansion (Section 6 of RFC8484) is always a valid and functional ":path" value (RFC9113, Section 8.3.1). </del>  When using this SVCB record, the client MUST send any DoH requests to the HTTP origin identified by the "https" scheme, the authentication

Reviewer comments:
Section 5.1 says this: The examples are all like this: RFC 6570 says this: I assume that we don't want passed in the SVCB record. Should we clarify that MUST be in relative form, i.e., just the path portion of the URI?
As a normative matter, I think this is already settled in the text, but I'm happy to improve clarity of the description.
Yeah, I think this technically covers it (), but it would be nice to say something at the start of the paragraph to specify that this is just a path segment of the URL.

Revised text:
5.1. "dohpath" is a single-valued SvcParamKey whose value (both in  <ins> presentation and wire format) MUST be a URI Template in relative form (RFC6570, Section 1.1) encoded in UTF-8 RFC3629.  If the "alpn" SvcParam indicates support for HTTP, "dohpath" MUST be present.  The URI Template MUST contain a "dns" variable, and MUST be chosen such that the result after DoH template expansion (Section 6 of RFC8484) is always a valid and functional ":path" value (RFC9113, Section 8.3.1). </ins> When using this SVCB record, the client MUST send any DoH requests to the HTTP origin identified by the "https" scheme, the authentication
Original text:
server.  Clients need to know the intended use of services based on their context.  7. A resolver known as "simple.example" that supports DNS over TLS on

Reviewer comments:
See URL
LGTM I have read the draft. It aims to be agnostic as to whether the DNS server that is the subject of the SVCB record is a recursive resolver or an authoritative nameserver for some zone (typically delegated by its parent). It also aims to facilitate the establishment of an authenticated transport. It should be noted that with authoritative delegations from a parent zone, the "service name" for each delegated to nameserver is always obtained from the unsigned parent-side NS RRset. Consequently unless the transport to the parent zone nameserver is authenticated, there is an unavoidable MiTM exposure even when the zone with the SVCB qname is DNSSEC-signed, because an on-path attacker can tamper with the returned NS records. And of course if the transport to the parent nameserver is not encrypted, the name of the desired child zone is leaked in the clear, defeating some or most of the privacy gains from subsequent use of an encrypted transport with the child zone nameservers. So perhaps the document should note using SVCB to signal transport security for nameservers derived from NS records is predicated on a suitably secure connection to the parent zone. The use of SVCB RRs for authoritative nameservers introduces the possibility that the SVCB target name is different from the "service name" in the NS record. Such additional indirection is perhaps surprising or even undesirable. Also, likely DoH would not be a supported transport for authoritative servers, with DoT or DoQ being the available options. If this draft is to be adopted for use with authoritative nameservers these topics would warrant some further discussion, and perhaps some minimal text is warranted to say as much. Viktor.

Revised text:
server.  Clients need to know the intended use of services based on their context. <ins> Not all features of this specification will be applicable or effective in all contexts: If the authentication name is received over an insecure channel (e.g., a glue NS record), this specification cannot prevent the client from connecting to an attacker. Different transports might prove to be popular for different purposes (e.g., stub resolution vs. iterative resolution). Implementors are not obligated to implement all the defined transports, although doing so is beneficial for compatibility. Where resolution speed is a high priority, the SVCB TargetName SHOULD follow the convention described in Section 11.2 of SVCB, and the use of AliasMode records (Section 2.4.2 of SVCB) is NOT RECOMMENDED. </ins> 7. A resolver known as "simple.example" that supports DNS over TLS on
Original text:
7. <del> A resolver at "simple.example" that supports DNS over TLS on port 853 (implicitly, as this is its default port): </del>  <del> A resolver at "doh.example" that supports only DNS over HTTPS (DNS over TLS is not supported): </del>  <del> A resolver at "resolver.example" that supports </del>  <del> DNS over TLS on "resolver.example" ports 853 (implicit in </del>  record 1) and 8530 (explicit in record 2), with <del> "resolver.example" as the Authentication Domain Name, </del>  DNS over HTTPS at "https://resolver.example/dns-query{?dns}" (record 1), and <del> A nameserver at "ns.example" whose service configuration is </del>  published on a different domain:

Reviewer comments:
These are really minor, was making all your dns names use the same syntax you started with ("") But I think the examples should look similar in nature. (i'm also thinking of some horrible bad examples to include)
agreed - totally missed that. I pushed up the edit if that is easier.

Revised text:
7.  <ins> A resolver at ""simple.example"" that supports DNS over TLS on port 853 (implicitly, as this is its default port): </ins>  <ins> A resolver at ""doh.example"" that supports only DNS over HTTPS (DNS over TLS is not supported): </ins>  <ins> A resolver at ""resolver.example"" that supports: </ins>  <ins> DNS over TLS on ""resolver.example"" ports 853 (implicit in </ins> record 1) and 8530 (explicit in record 2), with  <ins> ""resolver.example"" as the Authentication Domain Name, </ins> DNS over HTTPS at "https://resolver.example/dns-query{?dns}" (record 1), and  <ins> A nameserver at ""ns.example"" whose service configuration is </ins> published on a different domain:
Original text:
A Packet Reorder Function (PROF) re-orders packets within a DetNet flow that are received out of order.  This function may be <del> implemented at an edge node or end system. </del>  A control word used for sequencing and identifying duplicate packets at the DetNet service layer.

Reviewer comments:
Also pick up simplified makefile from ip draft
EMAIL NAME NAME can you take a look...
I got one specific comment on reordering and relay functions... comment embedded.

Revised text:
A Packet Reorder Function (PROF) re-orders packets within a DetNet flow that are received out of order.  This function may be  <ins> implemented at an edge or relay node. </ins> A control word used for sequencing and identifying duplicate packets at the DetNet service layer.
Original text:
supported. The place such URIs are specified (see general-record-format) allows <del> a list of these to be provided.  A report is normally sent to each listed URI in the order provided by the Domain Owner.  Receivers MAY impose a limit on the number of URIs to which they will send reports but MUST support the ability to send to at least two.  The list of URIs is separated by commas (ASCII 0x2C). </del>  Each URI can have associated with it a maximum report size that may be sent to it.  This is accomplished by appending an exclamation

Reviewer comments:
should serve to regulate the size of reports, by sending them more often. See .
The work of the design team is to propose text at this stage. Discussion of the proposed text can take place on-list starting after April 23.

Revised text:
supported. The place such URIs are specified (see general-record-format) allows  <ins> a list of these to be provided.  The list of URIs is separated by commas (ASCII 0x2c).  A report is normally sent to each listed URI in the order provided by the Domain Owner. </ins> Each URI can have associated with it a maximum report size that may be sent to it.  This is accomplished by appending an exclamation
Original text:
In essence, the steps are as follows:  5. One of the most obvious points of security scrutiny for DMARC is the

Reviewer comments:
How come ARC compliance becomes an integral part of DMARC? They are different protocols.
The work of the design team is to propose text at this stage. Discussion of the proposed text can take place on-list starting after April 23.

Revised text:
In essence, the steps are as follows: <ins> 4.4. Domain owners, intermediaries, and mail receivers can all claim to implement DMARC, but what that means will depend on their role in the transmission of mail.  To remove any ambiguity from the claims, this document specifies the following minimum criteria that must be met for each agent to rightly claim to be "implementing DMARC". Domain Owner: To implement DMARC, a domain owner MUST configure its domain to request that unauthenticated mail be rejected or at least treated with suspicion.  This means that it MUST publish a policy record that: While 'none' is a syntactically valid value for both the p and sp tags, the practical value of either the p tag or sp tag being 'none' means that the domain owner is still gathering information about mail flows for the domain or sub-domains, and is not yet ready to commit to requesting that unauthenticated mail receive different handling than authenticated mail. Intermediary: To implement DMARC, an intermediary MUST do the following before passing the message to the next hop or rejecting it as appropriate: Mail Receiver: To implement DMARC, a mail receiver MUST do the following: </ins> 5. One of the most obvious points of security scrutiny for DMARC is the
Original text:
4.3.  The above diagram shows a simple flow of messages through a DMARC- aware system.  Solid lines denote the actual message flow, dotted lines involve DNS queries used to retrieve message policy related to authentication modules.  "sMTA" is the sending MTA, and "rMTA" is the receiving MTA. <del> In essence, the steps are as follows: </del>  5. 6.5. <del> To implement the DMARC mechanism, the only action required of a Domain Owner is the creation of the DMARC policy record in the DNS. However, in order to make meaningful use of DMARC, a Domain Owner must at minimum either establish an address to receive reports, or deploy authentication technologies and ensure Identifier Alignment. Most Domain Owners will want to do both. DMARC reports will be of significant size, and the addresses that receive them are publicly visible, so we encourage Domain Owners to set up dedicated email addresses to receive and process reports, and to deploy abuse countermeasures on those email addresses as appropriate. Authentication technologies are discussed in RFC6376 (see also RFC5585 and RFC5863) and RFC7208. </del>  6.6.

Reviewer comments:
Proposed updated ASCII art for mail flow. Proposed stripped down description of ASCII art. Proposed new text for Domain Owner actions.

Revised text:
4.3. <ins> Issue 2, Original text: Issue 2, Proposed replacement text: </ins> The above diagram shows a simple flow of messages through a DMARC- aware system.  Solid lines denote the actual message flow, dotted lines involve DNS queries used to retrieve message policy related to authentication modules.  "sMTA" is the sending MTA, and "rMTA" is the receiving MTA.  <ins> Issue 2, Original text to be deleted and/or repurposed: Issue 2, Proposed replacement text: </ins> 5. 6.5.  <ins> Issue 2, Original text: Issue 2, Proposed replacement text: </ins> 6.6.
Original text:
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 <del> that the client SHOULD use TCP to retrieve the full response. </del>  1. protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
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 45cb8efcbf03c193791a14894aeb8d9d2a15096e

Revised text:
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  <ins> that the client SHOULD use TCP to retrieve the full response.  This document updates RFC 1034 to clarify correct server behavior. </ins> 1. protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. <ins> 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. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Original text:
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 <del> includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </del>  At the time of this writing, addresses (A or AAAA records) for a delegation's authoritative name servers are the only type of glue

Reviewer comments:
idnits mentions this: -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945)

Revised text:
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  <ins> includes TSIG RFC8945, OPT RFC6891, and SIG(0) RFC2931. </ins> At the time of this writing, addresses (A or AAAA records) for a delegation's authoritative name servers are the only type of glue
Original text:
because it helps describe the DNS and naming systems similar to the DNS. <del> An ordered list of zero or more labels. </del>  Note that this is a definition independent of the DNS RFCs, and the definition here also applies to systems other than the DNS.

Reviewer comments:
Shouldn'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.

Revised text:
because it helps describe the DNS and naming systems similar to the DNS.  <ins> An ordered list of one or more labels. </ins> Note that this is a definition independent of the DNS RFCs, and the definition here also applies to systems other than the DNS.
Original text:
to prove or deny the existence of the insecure delegations. (Adapted from RFC7129, Section 5.1)  "The practice of discovering the full content of a zone via successive queries."  (Quoted from RFC5155, Section 1.3.)  This is also sometimes called "zone walking".  Zone enumeration is

Reviewer comments:
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 URL

Revised text:
to prove or deny the existence of the insecure delegations. (Adapted from RFC7129, Section 5.1) <ins> "A signed name containing a delegation (NS RRset), but lacking a DS RRset, signifying a delegation to an unsigned subzone." (Quoted from RFC4956, Section 2.) </ins> "The practice of discovering the full content of a zone via successive queries."  (Quoted from RFC5155, Section 1.3.)  This is also sometimes called "zone walking".  Zone enumeration is
Original text:
function is performed by the DNS operator plus other entities who decide about the allowed contents of the zone.  8. Most DNSSEC terms are defined in RFC4033, RFC4034, RFC4035, and Stealth server Stub resolver Subdomain  T TLD

Reviewer comments:
In June 2015, Joe Abley said: I think that "superordinate" and "subordinate" might be worth mentioning here, with reference to their definitions in EPP.
Added in URL
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 don't know that we need to do this, hence the approval.)

Revised text:
function is performed by the DNS operator plus other entities who decide about the allowed contents of the zone. <ins> 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. </ins> 8. Most DNSSEC terms are defined in RFC4033, RFC4034, RFC4035, and Stealth server Stub resolver Subdomain <ins> Subordinate Superordinate </ins> T TLD
Original text:
make it a full-service resolver), but some recursive resolvers might not cache.  "The act of finding the list of root servers from a configuration that lists some or all of the purported IP addresses of some or all of those root servers."  (Quoted from RFC8109, Section 2.) Insecure delegation Instance Iterative mode  K Key signing key (KSK) Negative caching Negative response Next closer name  O OPT RR RRset Recursive mode  Recursive resolver Referrals Registrant

Reviewer comments:
…erative resolution
Agree with your fix to the definition.
During the lead-up to RFC 7719, Tony Finch 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 URL
I don'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.

Revised text:
make it a full-service resolver), but some recursive resolvers might not cache. <ins> A query with the Recursion Desired (RD) bit set to 1 in the header.(See Section 4.1.1 of RFC1035.)  If recursive service is available and is requested by the RD bit in the query, the server uses its resolver to answer the query.  (See Section 4.3.2 of RFC1035.) A query with the Recursion Desired (RD) bit set to 0 in the header.  A server can answer non-recursive queries using only local information: the response contains either an error, the answer, or a referral to some other server "closer" to the answer. (See Section 4.3.1 of RFC1035.) 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. A name server may be presented with a query that can only be answered by some other server.  The two general approaches to dealing with this problem are "recursive", in which the first server pursues the query for the client at another server, and "iterative", in which the server refers the client to another server and lets the client pursue the query there.  (See Section 2.3 of RFC1034.) 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. </ins> "The act of finding the list of root servers from a configuration that lists some or all of the purported IP addresses of some or all of those root servers."  (Quoted from RFC8109, Section 2.) Insecure delegation Instance Iterative mode <ins> Iterative query Iterative resolution </ins> K Key signing key (KSK) Negative caching Negative response Next closer name <ins> Non-recursive query </ins> O OPT RR RRset Recursive mode <ins> Recursive query </ins> Recursive resolver Referrals Registrant