jiebi/TextFlow huggingface dataset:
Original text:
from TSN (L2) to PW (MPLS) encapsulation.  However, such interworking is out-of-scope in this document and left for further study. <del> A MPLS DetNet flow is configured to carry any number of TSN flows. The DetNet flow specific bandwidth profile SHOULD match the required bandwidth of the App-flow aggregate. </del> 5.3. In the design of I-D.ietf-detnet-mpls an MPLS service label (the

Reviewer comments:
ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Revised text:
from TSN (L2) to PW (MPLS) encapsulation.  However, such interworking is out-of-scope in this document and left for further study.  5.3. In the design of I-D.ietf-detnet-mpls an MPLS service label (the
Original text:
(DetNet) Edge node terminates all related information elements encoded in the MPLS labels. <del> The LSP used to forward the DetNet packet may be of any type (MPLS- LDP, MPLS-TE, MPLS-TP RFC5921, or MPLS-SR RFC8660).  The LSP (F-Label) label and/or the S-Label may be used to indicate the queue processing as well as the forwarding parameters. </del> When a PE receives a packet from the Service Proxy function it MUST <del> add to the packet the DetNet flow-ID specific S-label and create a d-CW.  The PE MUST forward the packet according to the configured DetNet Service and Forwarding sub-layer rules to other PE nodes. </del>  When a PE receives an MPLS packet from a remote PE, then, after processing the MPLS label stack, if the top MPLS label ends up being

Reviewer comments:
ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Revised text:
(DetNet) Edge node terminates all related information elements encoded in the MPLS labels.  When a PE receives a packet from the Service Proxy function it MUST  <ins> handle the packet as defined in I-D.ietf-detnet-mpls. </ins> When a PE receives an MPLS packet from a remote PE, then, after processing the MPLS label stack, if the top MPLS label ends up being
Original text:
3. This document builds on the specification of MPLS over UDP and IP <del> defined in RFC7510.  It replaces the F-Label(s) used in I-D.ietf- detnet-mpls with UDP and IP headers.  The UDP and IP header information is used to identify DetNet flows, including member flows, per I-D.ietf-detnet-ip.  The resulting encapsulation is shown in IP- encap-dn. </del>  Note that this encapsulation works equally well with IPv4, IPv6, and IPv6-based Segment Routing I-D.ietf-6man-segment-routing-header.

Reviewer comments:
Based on 06.17 discussions. F-lables(s) added to Fig1 and text fixed. Adding procedures sections. Multiple notes added for clarifications. Adding controller plane section.
reviewed in Jun 24 meeting

Revised text:
3. This document builds on the specification of MPLS over UDP and IP  <ins> defined in RFC7510.  It may replace partly or entirely the F-Label(s) used in I-D.ietf-detnet-mpls with UDP and IP headers.  The UDP and IP header information is used to identify DetNet flows, including member flows, per I-D.ietf-detnet-ip.  The resulting encapsulation is shown in IP-encap-dn.  There may be zero or more F-label(s) between the S-label and the UDP header. </ins> Note that this encapsulation works equally well with IPv4, IPv6, and IPv6-based Segment Routing I-D.ietf-6man-segment-routing-header.
Original text:
mpls and I-D.ietf-detnet-ip.  This draft does not have additional security considerations. <del> 5. </del>  This document makes no IANA requests.

Reviewer comments:
Based on 06.17 discussions. F-lables(s) added to Fig1 and text fixed. Adding procedures sections. Multiple notes added for clarifications. Adding controller plane section.
reviewed in Jun 24 meeting

Revised text:
mpls and I-D.ietf-detnet-ip.  This draft does not have additional security considerations.  <ins> 7. </ins> This document makes no IANA requests.
Original text:
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 <del> functions.  However this document describes the data structure in sufficient detail that implementers if they desire can write their own code to do this. </del>  Each RRset in the chain is composed of a sequence of wire format DNS resource records.  The format of the resource record is described in RFC1035, Section 3.2.1.  Each RRset in the sequence is followed by its associated RRsig record <del> set.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </del>  where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the signature field

Reviewer comments:
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 Eric Rescorla's 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 can't validate this chain from the above. Similarly, although I think this is enough to break apart the RRSETs into RRs, it doesn'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.

Revised text:
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  <ins> functions. </ins> Each RRset in the chain is composed of a sequence of wire format DNS resource records.  The format of the resource record is described in RFC1035, Section 3.2.1. <ins> The resource records that make up a RRset all have the same owner, type and class, but different RDATA as specified RFC2181, Section 5. </ins> Each RRset in the sequence is followed by its associated RRsig record  <ins> set.  This RRset has the same owner and class as the preceding RRset, but has type RRSIG.  The Type Covered field in the RDATA of the RRsigs identifies the type of the preceding RRset as described in RFC4034, Section 3.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </ins> where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the signature field
Original text:
1. <del> RFC5280 specifies several extended key purpose identifiers for X.509 certificates.  In addition, several extended key purpose identifiers were addedRFC7299 as public OIDs under the IANA PKIX Extended key purpose identifiers arc.  While usage of the any extended key usage value is bad practice for publicly trusted certificates, there is no public and general extended key purpose identifier explicitly assigned for Document Signing certificates.  The current practice is to use id-kp-emailProtection, id-kp-codeSigning or vendor defined Object IDs for general document signing purposes. </del>  In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes

Reviewer comments:
I reviewed and approved this pull request.
Upon further reflection it seems like RFC 7299 and 8358 are informative instead of normative references.

Revised text:
1.  <ins> RFC5280 specifies several extended key usages for X.509 certificates. In addition, several extended key usage had been addedRFC7299 as public OID under the IANA repository.  While usage of any extended key usage is bad practice for publicly trusted certificates, there are no public and general extended key usage explicitly assigned for Document Signing certificates.  The current practice is to use id-kp- emailProtection, id-kp-codeSigning or vendor defined Object ID for general document signing purposes. </ins> In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes
Original text:
5. A DNS client that already knows the name of an Encrypted Resolver can <del> use DEER to discover details about all supported encrypted DNS </del>  protocols.  This situation can arise if a client has been configured to use a given Encrypted Resolver, or if a network provisioning protocol (such as DHCP or IPv6 Router Advertisements) provides a name

Reviewer comments:
Changed 2 instances of DEER to DDR
I was so focused on finding "equivalent" that I missed a couple deer apparently. Thank you!

Revised text:
5. A DNS client that already knows the name of an Encrypted Resolver can  <ins> use DDR to discover details about all supported encrypted DNS </ins> protocols.  This situation can arise if a client has been configured to use a given Encrypted Resolver, or if a network provisioning protocol (such as DHCP or IPv6 Router Advertisements) provides a name
Original text:
6. <del> Resolver deployments that support DEER are advised to consider the </del>  following points. 6.1.

Reviewer comments:
Changed 2 instances of DEER to DDR
I was so focused on finding "equivalent" that I missed a couple deer apparently. Thank you!

Revised text:
6.  <ins> Resolver deployments that support DDR are advised to consider the </ins> following points. 6.1.
Original text:
mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a <del> resolver is known.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities. </del>  1.

Reviewer comments:
Three changes Re-ordered statements in the abstract to place the restriction on unencrypted bootstrapping next to the unencrypted statement (instead of after the encrypted bootstrapping statement, which makes the restriction seem like a conflict where it excludes bootstrapping from a name instead of an IP address) Re-ordered security considerations (placed the "clients can opt to do other things" statement at the end after the MUSTs/SHOULDs for this doc) s/client/clients for grammatical correctness

Revised text:
mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a  <ins> resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known. </ins> 1.
Original text:
7. <del> Since client can receive DNS SVCB answers over unencrypted DNS, on- </del>  path attackers can prevent successful discovery by dropping SVCB packets.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated

Reviewer comments:
Three changes Re-ordered statements in the abstract to place the restriction on unencrypted bootstrapping next to the unencrypted statement (instead of after the encrypted bootstrapping statement, which makes the restriction seem like a conflict where it excludes bootstrapping from a name instead of an IP address) Re-ordered security considerations (placed the "clients can opt to do other things" statement at the end after the MUSTs/SHOULDs for this doc) s/client/clients for grammatical correctness

Revised text:
7.  <ins> Since clients can receive DNS SVCB answers over unencrypted DNS, on- </ins> path attackers can prevent successful discovery by dropping SVCB packets.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated
Original text:
but be operated by an attacker that is trying to observe or modify user queries without the knowledge of the client or network. <del> The constraints on validation of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this documents, which are referred to as Authenticated Discovery and Opportunistic Discovery.  Clients MAY use some other mechanism to validate and use Designated Resolvers discovered using the DNS SVCB record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. </del> If the IP address of a Designated Resolver differs from that of an Unencrypted Resolver, clients applying Authenicated Discovery (authenticated) MUST validate that the IP address of the Unencrypted

Reviewer comments:
Three changes Re-ordered statements in the abstract to place the restriction on unencrypted bootstrapping next to the unencrypted statement (instead of after the encrypted bootstrapping statement, which makes the restriction seem like a conflict where it excludes bootstrapping from a name instead of an IP address) Re-ordered security considerations (placed the "clients can opt to do other things" statement at the end after the MUSTs/SHOULDs for this doc) s/client/clients for grammatical correctness

Revised text:
but be operated by an attacker that is trying to observe or modify user queries without the knowledge of the client or network.  If the IP address of a Designated Resolver differs from that of an Unencrypted Resolver, clients applying Authenicated Discovery (authenticated) MUST validate that the IP address of the Unencrypted
Original text:
to cases where the Unencrypted Resolver and Designated Resolver have the same IP address.  8. 8.1.

Reviewer comments:
Three changes Re-ordered statements in the abstract to place the restriction on unencrypted bootstrapping next to the unencrypted statement (instead of after the encrypted bootstrapping statement, which makes the restriction seem like a conflict where it excludes bootstrapping from a name instead of an IP address) Re-ordered security considerations (placed the "clients can opt to do other things" statement at the end after the MUSTs/SHOULDs for this doc) s/client/clients for grammatical correctness

Revised text:
to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. <ins> The constraints on validation of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this document, which are referred to as Authenticated Discovery and Opportunistic Discovery.  Clients MAY use some other mechanism to validate and use Designated Resolvers discovered using the DNS SVCB record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. </ins> 8. 8.1.
Original text:
queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically.  While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such as via manual configuration, a VPN, or on a network with protections

Reviewer comments:
NAME does this work for you?
OK, so I said LGTM, but how does a server know that it is such a server? Can't I just publish a random DDR record for 1.1.1.1?
As I mentioned in the session, this is partly covered in SVCB-DNS, but perhaps we need a tighter rule. I've opened an issue to discuss it: URL I'm not entirely sure which draft this kind of text ought to go in. If you think this logic applies beyond DDR (e.g. in ADoT cases), then it probably should go in the SVCB-DNS draft. Otherwise, maybe DDR is the place.
NAME for security considerations, I'm OK with multiple drafts having warnings. I think this particular attack should be mentioned in DDR, since other uses of DNS SVCB could be over more trusted channels.
NAME if your resolver responds to URL, then we expect the address of the resolver I asked to be covered in the cert. So, if I send a packet to 1.1.1.1, 1.1.1.1 has to be covered. So, if you just provide a "random" DDR record in response to URL, you can only point to some resolver that has your IP address in its cert, which presumably is sufficient coordination for the resolver to "know" it has this set up.
Right. Good point.
As mentioned at the microphone, if we are to allow the query-path to be specified in the clear like this, we need to require that servers not have different responses with different query paths.
LGTM

Revised text:
queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. <ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the HTTP path alone, since an attacker could modify the "dohpath" parameter. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such as via manual configuration, a VPN, or on a network with protections
Original text:
This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".)  4.3. These SvcParamKeys from SVCB apply to the "dns" scheme without

Reviewer comments:
Closes URL
Allowing the use of nonstandard port numbers in SVCB for DNS provides valuable operational flexibility, but it also creates a risk related to cross-protocol confusion attacks, in which a malicious server convinces a client to send TCP contents that can be misparsed as a different protocol by a non-TLS victim server. For example, a malicious DNS server could indicate an SNI or session ticket that can be misparsed as a command by a recipient server, and use DNS rebinding to change its own apparent IP address to the victim server. Clients would then send this server-controlled payload to the victim server. This is dangerous if the client is implicitly authorized to control the victim server (e.g. authorization by IP address). Note that only DoT and DoH (over TCP) are amenable to these attacks. QUIC Initial encryption ensures that the packet has no meaning to a recipient that is not QUIC-aware, and any QUIC-aware recipient should not be vulnerable to these attacks. We should consider ways to minimize the impact of these attacks. For example, we could require clients to restrict the value of the parameter to a small fixed list, or refer to the . Credit to NAME

Revised text:
This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) <ins> Support for the "port" key can be unsafe if the client has implicit elevated access to some network service (e.g. a local service that is inaccessible to remote parties) and that service uses a TCP-based protocol other than TLS.  A hostile DNS server might be able to manipulate this service by causing the client to send a specially crafted TLS SNI or session ticket that can be misparsed as a command or exploit.  To avoid such attacks, clients SHOULD NOT support the "port" key unless one of the following conditions applies: The client is being used with a DNS server that it trusts not attempt this attack. The client is being used in a context where implicit elevated access cannot apply. The client restricts the set of allowed TCP port values to exclude any ports where a confusion attack is likely to be possible (e.g. the "bad ports" list from the "Port blocking" section of FETCH). </ins> 4.3. These SvcParamKeys from SVCB apply to the "dns" scheme without
Original text:
defined for the DNS. Note that this document only clarifies requirements of name server <del> software implementations.  It does not change any requirements on data placed in DNS zones or registries. </del>  1.1.

Reviewer comments:
…out presence of glue in zones.
No further discussion on list nor here so I will merge this.
From the dnsop list, Ralf Weber suggests the draft could more clearly state that a name server might provide an "incorrect" response because it wasn't given necessary glue records in the zone data.

Revised text:
defined for the DNS. Note that this document only clarifies requirements of name server  <ins> 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. </ins> 1.1.
Original text:
5. This section defines the terms used for the systems that act as DNS <del> clients, DNS servers, or both. </del>  For terminology specific to the public DNS root server system, see RSSAC026.  That document defines terms such as "root server", "root

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

Revised text:
5. This section defines the terms used for the systems that act as DNS  <ins> 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. </ins> For terminology specific to the public DNS root server system, see RSSAC026.  That document defines terms such as "root server", "root