jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-add-svcb-dns

Commentary: See 
 LGTM
Mailing list commentary: 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 .
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Draft: draft-ietf-add-svcb-dns

Commentary: Section 5.1 says this : The examples are all like this : RFC 6570 says this : I assume that we do n'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 .
Paragraph (version A):
"dohpath" is a single-valued SvcParamKey whose value (both in
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).
Paragraph (version B):
"dohpath" is a single-valued SvcParamKey whose value (both in
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).
Draft: draft-ietf-add-svcb-dns

Commentary: Closes 
 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
Paragraph (version B):
The client is being used with a DNS server that it trusts not
attempt this attack.
Paragraph (version B):
The client is being used in a context where implicit elevated
access cannot apply.
Paragraph (version B):
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).
Draft: draft-ietf-add-svcb-dns

Commentary: 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 .
Paragraph (version A):
DNS over TLS on "resolver.example" ports 853 (implicit in
record 1) and 8530 (explicit in record 2), with
"resolver.example" as the Authentication Domain Name,
Paragraph (version B):
DNS over TLS on ""resolver.example"" ports 853 (implicit in
record 1) and 8530 (explicit in record 2), with
""resolver.example"" as the Authentication Domain Name,
Draft: draft-ietf-add-svcb-dns

Commentary: This should help with the case in DDR . See 
 Much better . Thanks for indulging me .
Paragraph (version A):
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"".
Paragraph (version B):
SVCB record names (i.e.  QNAMEs) 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
queried at ""_dns.dns1.example.com"".
Paragraph (version B):
Binding authority - The service name (Section 1.4 of SVCB) and
optional port number used as input to Port-Prefix Naming.
Paragraph (version B):
Authentication name - The name used for secure transport
authentication.  It must be a DNS hostname or a literal IP
address.  Unless otherwise specified, it is the service name from
the binding authority.
Paragraph (version A):
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
""dns1.example.com:9953"" would be located at
""_9953._dns.dns1.example.com"".  If two DNS services operating on
different port numbers provide different behaviors, this arrangement
allows them to preserve the distinction when specifying alternative
endpoints.
Paragraph (version B):
When the binding authority specifies a non-default port number, Port-
Prefix Naming places the port number in an additional a prefix on the
name.  For example, if the binding authority is
""dns1.example.com:9953"", the client would query for SVCB records at
""_9953._dns.dns1.example.com"".  If two DNS services operating on
different port numbers provide different behaviors, this arrangement
allows them to preserve the distinction when specifying alternative
endpoints.
Paragraph (version A):
Clients MUST authenticate the server to its name during secure
transport establishment.  This name is the hostname used to construct
the original SVCB query, and cannot be influenced by the SVCB record
contents.  Accordingly, this draft does not mandate the use of
DNSSEC.  This draft also does not specify how clients authenticate
the name (e.g. selection of roots of trust), which might vary
according to the context.
Paragraph (version B):
During secure transport establishment, clients MUST authenticate the
server to its authentication name, which is not influenced by the
SVCB record contents.  Accordingly, this draft does not mandate the
use of DNSSEC.  This draft also does not specify how clients
authenticate the name (e.g. selection of roots of trust), which might
vary according to the context.
Draft: draft-ietf-add-svcb-dns

Commentary: 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 .
Paragraph (version A):
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".
Paragraph (version B):
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"".
Paragraph (version A):
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
"dns1.example.com:9953" would be located at
"_9953._dns.dns1.example.com".  If two DNS services operating on
different port numbers provide different behaviors, this arrangement
allows them to preserve the distinction when specifying alternative
endpoints.
Paragraph (version B):
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
""dns1.example.com:9953"" would be located at
""_9953._dns.dns1.example.com"".  If two DNS services operating on
different port numbers provide different behaviors, this arrangement
allows them to preserve the distinction when specifying alternative
endpoints.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
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).
Paragraph (version B):
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).
Draft: draft-schwartz-svcb-dns

Commentary: 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 
 Section 5.1 says this : The examples are all like this : RFC 6570 says this : I assume that we do n'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
Paragraph (version A):
These keys indicate the set of supported protocols (SVCB
Section 6.1).  The default protocol is "dot", indicating support for
DNS over TLS DOT.
Paragraph (version B):
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.
Paragraph (version A):
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, 443 for DNS over
HTTPS).
Paragraph (version A):
This key is automatically mandatory if present.
Paragraph (version B):
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).
Draft: draft-schwartz-svcb-dns

Commentary: Hey  , 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 ,    
 Thanks for the clarification !
Paragraph (version A):
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
"_5353._dns.dns1.example.com.".
Paragraph (version B):
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
"_5353._dns.dns1.example.com.".  A DNS service using the default port
number of 53 would be represented as "_dns.dns1.example.com.".