jiebi/CodeConvo huggingface dataset:
Change:
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!

Discussion:
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> <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.
Change:
This change removes the default protocol, which is currently DNS over TLS ("dot"). Several readers have expressed concern that this default is confusing.
Blocked by URL
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.
approved with 1 question

Discussion:
4.1. <del> These keys indicate the set of supported protocols (SVCB Section 6.1).  The default protocol is "dot", indicating support for DNS over TLS DOT. </del> <ins> This key indicates the set of supported protocols (SVCB Section 6.1). There is no default protocol, so the "no-default-alpn" key does not apply, and the "alpn" key MUST be present. </ins> If the protocol set contains any HTTP versions (e.g. "h2", "h3"), then the record indicates support for DNS over HTTPS DOH, and the

on their default ports.  Note that in this configuration, ALPN negotiation does not defend against cross-protocol downgrade attacks. <del> These keys are automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) </del> 4.2. This key is used to indicate the target port for connection ((SVCB Section 6.2)).  If omitted, the client SHALL use the default port for <del> each transport protocol (853 for DNS over TLS, 443 for DNS over </del> <ins> each transport protocol (853 for DNS over TLS DOT, 443 for DNS over </ins> HTTPS). <del> This key is automatically mandatory if present. </del> <ins> This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) </ins> 4.3.

8. A resolver at "simple.example" that supports DNS over TLS on port <del> 853 (implicitly, as this is the default protocol and its default port): </del> <ins> 853 (implicitly, as this is its default port): </ins> A resolver at "doh.example" that supports only DNS over HTTPS (DNS over TLS is disabled): _dns.doh.example. 7200 IN SVCB 1 <del> doh.example. ( no-default-alpn alpn=h2 dohpath=/dns-query{?dns} ) </del> <ins> doh.example. ( alpn=h2 dohpath=/dns-query{?dns} ) </ins> A resolver at "resolver.example" that supports
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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
Change:
The lack of quoting in some of the examples might make it harder to see what constitutes example and what is punctuation. Highlighting and fonts in the HTML rendering are subtle and not present in text renderings (any more). I've also changed some section references. I'm happy to split that off into a different change or use the form if you prefer that.

Discussion:
3. <del> Names are formed using Port-Prefix Naming (SVCB Section 2.3), with a scheme of "dns".  For example, SVCB records for a DNS service identified as "dns1.example.com" would be located at "_dns.dns1.example.com". </del> <ins> Names are formed using Port-Prefix Naming (Section 2.3 of SVCB), with a scheme of "dns".  For example, SVCB records for a DNS service identified as ""dns1.example.com"" would be located at ""_dns.dns1.example.com"". </ins> 3.1.

When a non-default port number is part of a service identifier, Port- Prefix Naming places the port number in an additional a prefix on the name.  For example, SVCB records for a DNS service identified as <del> "dns1.example.com:9953" would be located at "_9953._dns.dns1.example.com".  If two DNS services operating on </del> <ins> ""dns1.example.com:9953"" would be located at ""_9953._dns.dns1.example.com"".  If two DNS services operating on </ins> different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative endpoints.

4.1. <del> This key indicates the set of supported protocols (SVCB Section 6.1). There is no default protocol, so the "no-default-alpn" key does not apply, and the "alpn" key MUST be present. </del> <ins> This key indicates the set of supported protocols (Section 6.1 of SVCB).  There is no default protocol, so the "no-default-alpn" key does not apply, and the "alpn" key MUST be present. </ins> If the protocol set contains any HTTP versions (e.g. "h2", "h3"), then the record indicates support for DNS over HTTPS DOH, and the

4.2. <del> This key is used to indicate the target port for connection ((SVCB Section 6.2)).  If omitted, the client SHALL use the default port for each transport protocol (853 for DNS over TLS DOT, 443 for DNS over HTTPS). </del> <ins> This key is used to indicate the target port for connection ((Section 6.2 of SVCB)).  If omitted, the client SHALL use the default port for each transport protocol (853 for DNS over TLS DOT, 443 for DNS over HTTPS). </ins> This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".)
Change:
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.

Discussion:
7. <del> A resolver at "simple.example" that supports DNS over TLS on port 853 (implicitly, as this is its default port): </del> <ins> A resolver at ""simple.example"" that supports DNS over TLS on port 853 (implicitly, as this is its default port): </ins> <del> A resolver at "doh.example" that supports only DNS over HTTPS (DNS over TLS is not supported): </del> <ins> A resolver at ""doh.example"" that supports only DNS over HTTPS (DNS over TLS is not supported): </ins> <del> A resolver at "resolver.example" that supports </del> <ins> A resolver at ""resolver.example"" that supports: </ins> <del> DNS over TLS on "resolver.example" ports 853 (implicit in </del> <ins> DNS over TLS on ""resolver.example"" ports 853 (implicit in </ins> record 1) and 8530 (explicit in record 2), with <del> "resolver.example" as the Authentication Domain Name, </del> <ins> ""resolver.example"" as the Authentication Domain Name, </ins> DNS over HTTPS at "https://resolver.example/dns-query{?dns}" (record 1), and

<del> A nameserver at "ns.example" whose service configuration is </del> <ins> A nameserver at ""ns.example"" whose service configuration is </ins> published on a different domain:
Change:
Put the text that was taken out of the payload ident section back in. Fixed some compile warnings Two were figs too large One was use of [IEEE1588] instead of Rest were apparently unused references Requesting pull so we are in sync on this.
Looks OK to me. Merging all these chnanes.

Discussion:
The only nodes that needs to know the payload type of a flow are the DetNet ingress node and the DetNet egress nodes.  The ingress node has to know how to process the packet it receives from the ingress <del> AC, and egress edge node has to know how to.. </del> <ins> AC, and egress edge node has to know how to prepare the packet for transmission on the egress AC. On ingress a DetNet edge node has to classify the packets into those that are for transmission as Detnet packets and those that are for transmission as "normal" packets at one of more lower priorities. The packet type is indicated to the egress edge node through the value of the S-label.  Thus, when the egress edge node looks up the S-label one of the parameters returned is the packet type which in turn tells the egress edge node how to prepare the packet for transmission over the egress AC. The consequence of this approach is that if multiple packet encapsulations are processed on a node, each will need its own S-Label.  That is not generally a problems, since it is anticipated that only one encapsulation type intented for carriage as a DetNet flow will be present on any egress.  However, IPv4 and IPv6 have different forwarding equivalence classes (FEC) in MPLS and are therefore allocated different labels rather than being distinguished through the IP version field in the IP header.  Futhermore IPv4 and IPv6 when running directly over Ethernet are identified via the Ethertype rather than via the IP version number.  Whilst it ought to be safe to identify the IP type though the IP version number the absence this approach in practical applications suggests that it is more conservative to distinguish between IP types through the S-Label.  Thus when the payload is IP, two S-Labels are used, one to identify an IPv4 payload and one to identify an IPv6 payload. </ins> [Editor's note: We have specified the above for _data_ to leave the door open for the GAL based OAM method as an alternative to

When DetNet is used, there is an underlying assumption that the applicaton(s) require clock synchronization such as the Precision <del> Time Protocol (PTP) [IEEE1588].  The relay nodes may or may not utilize clock synchronization in order to provide zero congestion loss and controlled latency delivery.  In either case, there are a few possible approaches of how synchronization protocol packets are </del> <ins> Time Protocol (PTP) IEEE1588.  The relay nodes may or may not utilize clock synchronization in order to provide zero congestion loss and controlled latency delivery.  In either case, there are a few possible approaches of how synchronization protocol packets are </ins> forwarded and handled by the network: PTP packets can be sent either as DetNet flows or as high-priority
Change:
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.

Discussion:
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> <ins> implemented at an edge or relay node. </ins> A control word used for sequencing and identifying duplicate packets at the DetNet service layer.
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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
Change:
Proposed updated ASCII art for mail flow. Proposed stripped down description of ASCII art. Proposed new text for Domain Owner actions.

Discussion:
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. <del> In essence, the steps are as follows: </del> <ins> Issue 2, Original text to be deleted and/or repurposed: Issue 2, Proposed replacement text: </ins> 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> <ins> Issue 2, Original text: Issue 2, Proposed replacement text: </ins> 6.6.
Change:
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

Discussion:
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> <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",
Change:
idnits mentions this: -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945)

Discussion:
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> <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
Change:
Clarify glue, slightly reorder.
Merging - as mentioned in email, I will also add a more typical case of sibling glue (that doesn't involve cross zone and circular dependency). PR forthcoming ...

Discussion:
retrieve the full response.  This document clarifies that expectation. <del> While not common, real life examples of servers that fail to set TC=1 when glue records are available exist and they do cause resolution failures.  The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC RFC4033, RFC4034, RFC4035 referral response, this behaviour has also been seen with plain DNS responses as well.  The records have been truncated for display purposes.  Note that at the time of this writing, this configuration has been corrected and the response correctly sets the TC=1 flag. DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

3. <del> This document clarifies correct DNS server behaviour expectations and does not introduce new security considerations. </del> <ins> While not common, real life examples of servers that fail to set TC=1 when glue records are available exist and they do cause resolution failures. 3.1. The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC RFC4033, RFC4034, RFC4035 referral response, this behaviour has also been seen with plain DNS responses as well.  The records have been truncated for display purposes.  Note that at the time of this writing, this configuration has been corrected and the response correctly sets the TC=1 flag. DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. 3.2. A zone's sibling glue is glue in another zone that is required for proper resolving.  While the example below is obvious, real life examples can be more complex and not obvious. This situation is harder to detect if the sibling zones are nog hosted on the same nameservers. 3.3. When a zone is deleted but the parent notices that its NS glue records are required for other zones, it MAY opt to take these (now orphaned) glue records into its own zone to ensure that other zones depending on this glue are not broken.  Technically, these NS records are no longer glue records, but authorative data of the parent zone, and should be added to the DNS response similarly to regular glue records. </ins> 4. <ins> This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations. 5. </ins> There are no actions for IANA.
Change:
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.

Discussion:
because it helps describe the DNS and naming systems similar to the DNS. <del> An ordered list of zero or more labels. </del> <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.