jiebi/CodeConvo huggingface dataset:
General background and concepts of DetNet can be found in the DetNet Architecture RFC8655. <del> I-D.ietf-detnet-ip specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  This document focuses on the scenario where DetNet IP nodes are interconnected by a TSN sub-network. </del> <ins> RFC8939 specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  This document focuses on the scenario where DetNet IP nodes are interconnected by a TSN sub-network. </ins> The DetNet Architecture decomposes the DetNet related data plane functions into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service protection and reordering.  The forwarding sub-layer is used to provides congestion protection (low loss, assured latency, and <del> limited reordering).  As described in I-D.ietf-detnet-ip no DetNet specific headers are added to support DetNet IP flows, only the forwarding sub-layer functions are supported inside the DetNet domain.  Service protection can be provided on a per sub-network basis as shown here for the IEEE802.1 TSN sub-network scenario. </del> <ins> limited reordering).  As described in RFC8939 no DetNet specific headers are added to support DetNet IP flows, only the forwarding sub-layer functions are supported inside the DetNet domain.  Service protection can be provided on a per sub-network basis as shown here for the IEEE802.1 TSN sub-network scenario. </ins> 2.
Time-Sensitive Networking, TSN is a Task Group of the IEEE 802.1 Working Group. <del> 2.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 3. <del> I-D.ietf-detnet-ip describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service.  From a data plane perspective, an end-to-end IP model is followed.  DetNet uses "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. </del> <ins> RFC8939 describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service.  From a data plane perspective, an end-to-end IP model is followed.  DetNet uses "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. </ins> DetNet flow aggregation may be enabled via the use of wildcards, masks, prefixes and ranges.  IP tunnels may also be used to support
configure DetNet IP over TSN: DetNet IP related configuration information according to the <del> DetNet role of the DetNet IP node, as per I-D.ietf-detnet-ip. </del> <ins> DetNet role of the DetNet IP node, as per RFC8939. </ins> TSN related configuration information according to the TSN role of the DetNet IP node, as per IEEE8021Q, IEEE8021CB and IEEEP8021CBdb. Mapping between DetNet IP flow(s) (as flow identification defined <del> in I-D.ietf-detnet-ip, it is summarized in Section 5.1 of that document, and includes all wildcards, port ranges and the ability to ignore specific IP fields) and TSN Stream(s) (as stream identification information defined in IEEE8021CB and IEEEP8021CBdb).  Note, that managed objects for TSN Stream identification can be found in IEEEP8021CBcv. </del> <ins> in RFC8939, it is summarized in Section 5.1 of that document, and includes all wildcards, port ranges and the ability to ignore specific IP fields) and TSN Stream(s) (as stream identification information defined in IEEE8021CB and IEEEP8021CBdb).  Note, that managed objects for TSN Stream identification can be found in IEEEP8021CBcv. </ins> This information must be provisioned per DetNet flow.
Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in RFC8655.  DetNet IP data plane specific considerations <del> are summarized in I-D.ietf-detnet-ip.  This section considers exclusively security considerations which are specific to the DetNet IP over TSN sub-network scenario. </del> <ins> are summarized in RFC8939.  This section considers exclusively security considerations which are specific to the DetNet IP over TSN sub-network scenario. </ins> The sub-network between DetNet nodes needs to be subject to appropriate confidentiality.  Additionally, knowledge of what DetNet/
Time-Sensitive Network. <del> 2.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 3. The basic approach defined in I-D.ietf-detnet-mpls supports the
2.1. This document uses the terminology and concepts established in the <del> DetNet architecture RFC8655 and I-D.ietf-detnet-data-plane-framework, and I-D.ietf-detnet-mpls.  The reader is assumed to be familiar with these documents and their terminology. </del> <ins> DetNet architecture RFC8655 and RFC8938, and I-D.ietf-detnet-mpls. The reader is assumed to be familiar with these documents and their terminology. </ins> 2.2.
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
(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> <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
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> <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.
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> <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 <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> <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
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> <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
6.1. <del> If a caching forwarder consults multiple resolvers, it may be possible for it to cache records for the "resolver.arpa" Special Use Domain Name (SUDN) for multiple resolvers.  This may result in clients sending queries intended to discover Designated Resolvers for resolver "foo" and receiving answers for resolvers "foo" and "bar". A client will successfully reject unintended connections because the authenticated discovery will fail or the resolver addresses do not match.  Clients that attempt unauthenticated connections to resolvers discovered through SVCB queries run the risk of connecting to the wrong server in this scenario. To prevent unnecessary traffic from clients to incorrect resolvers, DNS caching resolvers SHOULD NOT cache results for the "resolver.arpa" SUDN other than for Designated Resolvers under their control. </del> <ins> A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" upstream.  This prevents a client from receiving an SVCB record that will fail to authenticate because the forwarder's IP address is not in the upstream resolver's Designated Resolver's TLS certificate SAN field.  A DNS forwarder which already acts as a completely blind forwarder MAY choose to forward these queries when the operator expects that this does not apply, either because the operator knows the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field or that the operator expects clients of the unencrypted resolver to use the SVCB information opportunistically. Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR by a resolver does not communicate a requirement for clients to use the SVCB record when it cannot be authenticated. </ins> 6.2.
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> <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.
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
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.
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
Since clients can receive DNS SVCB answers over unencrypted DNS, on- path attackers can prevent successful discovery by dropping SVCB <del> queries or answers.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack.  To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. </del> <ins> queries or answers, and thus prevent clients from switching to use encrypted DNS.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack.  To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the
Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document as the reference. <ins> 8.2. In accordance with Section 5 of RFC6761, the answers to the following questions are provided relative to this document: Are human users expected to recognize these names as special and use them differently?  In what way? No.  This name is used automatically by DNS stub resolvers running on client devices on behalf of users, and users will never see this name directly. Are writers of application software expected to make their software recognize these names as special and treat them differently?  In what way? No.  There is no use case where a non-DNS application (covered by the next question) would need to use this name. Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently?  If so, how? Yes. DNS client implementors are expected to use this name when querying for a resolver's properties instead of records for the name itself.  DNS servers are expected to respond to queries for this name with their own properties instead of checking the matching zone as it would for normal domain names. Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently?  If so, how? Yes. Caching domain name servers should not forward queries for this name to avoid causing validation failures due to IP address mismatch. Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently?  If so, how? No.  DDR is designed for use by recursive resolvers.  Theoretically, an authoritative server could choose to support this name if it wants to advertise support for encrypted DNS protocols over plain-text DNS, but that scenario is covered by other work in the IETF DNSOP working group. Does this reserved Special-Use Domain Name have any potential impact on DNS server operators?  If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid?  Do DNS server operators need to know about that and understand why?  Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware? This name is locally served, and any resolver which supports this name should never forward the query.  DNS server operators should be aware that records for this name will be used by clients to modify the way they connect to their resolvers. How should DNS Registries/Registrars treat requests to register this reserved domain name?  Should such requests be denied? Should such requests be allowed, but only to a specially- designated entity? IANA should hold the registration for this name.  Non-IANA requests to register this name should always be denied by DNS Registries/ Registrars. </ins>
should be able to use those records while safely ignoring the third record. <del> To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of RFC8484 regarding the avoidance of DNS- based references that block the completion of the TLS handshake. </del> <ins> To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of RFC8484.  Designated Resolvers need to ensure this deadlock is avoidable as described in Section 10 of RFC8484. </ins> This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers.  Other protocols can also use the format defined by I-
policy or user input.  Details of such policy are out of scope of this document.  Clients MUST NOT automatically use a Designated Resolver without some sort of validation, such as the two methods <del> defined in this document or a future mechanism. </del> <ins> defined in this document or a future mechanism.  Use without validation can allow an attacker to direct traffic to an Encrypted Resolver that is unrelated to the original Unencrypted DNS Resolver, as described in security. </ins> A client MUST NOT re-use a designation discovered using the IP address of one Unencrypted DNS Resolver in place of any other
address on multiple different networks, a Designated Resolver that has been discovered on one network SHOULD NOT be reused on any of the other networks without repeating the discovery process for each <del> network. However, if a given Unencrypted DNS Resolver designates a Designated Resolver that does not use a private or local IP address and can be verified using the mechanism described in verified, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in verified.  This is a tradeoff between performance (by having no delay in establishing an encrypted DNS connection on the new network) and functionality (if the Unencrypted DNS Resolver intends to designate different Designated Resolvers based on the network from which clients connect). </del> <ins> network, since the same IP address may be used for different servers on the different networks. </ins> 4.2.
possible. If these checks fail, the client MUST NOT automatically use the <del> discovered Designated Resolver.  Additionally, the client SHOULD </del> <ins> discovered Designated Resolver if this designation was only discovered via a "_dns.resolver.arpa." query (if the designation was advertised directly by the network as described in dnr-interaction, the server can still be used).  Additionally, the client SHOULD </ins> suppress any further queries for Designated Resolvers using this Unencrypted DNS Resolver for the length of time indicated by the SVCB record's Time to Live (TTL) in order to avoid excessive queries that
If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check <del> (opportunistic). </del> <ins> (opportunistic).  If the IP address is not shared, opportunistic use allows for attackers to redirect queries to an unrelated Encrypted Resolver, as described in security. </ins> <del> If resolving the name of a Designated Resolver from an SVCB record yields an IP address that was not presented in the Additional Answers section or ipv4hint or ipv6hint fields of the original SVCB query, the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known and validated IP address for the same Designated Resolver name. </del> <ins> Connections to a Designated Resolver can use a different IP address than the IP address of the Unencrypted DNS Resolver, such as if the process of resolving the SVCB service yields additional addresses. Even when a different IP address is used for the connection, the TLS certificate checks described in this section still apply for the original IP address of the Unencrypted DNS Resolver. </ins> 4.3.
6.4. DNS resolvers that support DDR by responding to queries for <del> _dns.resolver.arpa SHOULD treat resolver.arpa as a locally served zone per RFC6303.  In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa with NODATA and queries of any type for any domain name under </del> <ins> _dns.resolver.arpa MUST treat resolver.arpa as a locally served zone per RFC6303.  In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa with NODATA and queries of any type for any domain name under </ins> resolver.arpa with NODATA. 6.5.