Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)
draft-ietf-dnsop-svcb-https-09

I support Francesca Palombini's discuss.

Thanks to Dale Worley for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ctABeNgyI1ywOHNXs17ZO07rLFY).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

"Table of Contents", paragraph 2, nit:
> iding transient connections to a sub-optimal default server, negotiating a pr
>                                  ^^^^^^^^^^^
This word is normally spelled as one.

Section 2.4.2. , paragraph 10, nit:
> its SvcParams all comply with each others' requirements. Zone-file implement
>                                    ^^^^^^^
Did you mean "other's"?

Section 3.2. , paragraph 2, nit:
> ons. 4.2. Recursive resolvers Whether or not the recursive resolver is aware
>                               ^^^^^^^^^^^^^^
Consider shortening this phrase to just "Whether". It is correct though if you
mean "regardless of whether".

Section 9.1. , paragraph 5, nit:
> o alt3.example:9443 * Fallback to the the client's non-Alt-Svc connection beh
>                                   ^^^^^^^
Possible typo: you repeated a word.

Section 9.3. , paragraph 2, nit:
> rtext HTTP. If this redirection would result in a loss of functionality (e.g
>                                 ^^^^^^^^^^^^
Consider removing "would". (Usually, "would" does not occur in a conditional
clause, unless to make a request or give a polite order.).

Section 12. , paragraph 3, nit:
> his registry are subject to a First Come First Served registration policy ([
>                                     ^^^^
It seems that a comma is missing.

"D.2. ", paragraph 14, nit:
> fy the IANA instructions (pure First Come First Served) - Recommend against
>                                      ^^^^
It seems that a comma is missing.

Document references draft-ietf-tls-esni-13, but -14 is the latest available
revision.

To this DNS non-expert, I found it hard to follow the motivation for AliasMode. In particular, I asked myself the following questions that could have been answered in the Introduction or in (2.4.2):

- Why is it not OK for a CNAME to alias the apex, but OK for AliasMode to do so? [having asked around, it's because CNAME aliases all the record types, which is nonsensical for the apex, and AliasMode does not]

- For non-apex domains, under what conditions would I use AliasMode instead of a CNAME? Is it just when I don't want to bring along record types besides A, AAAA, and SVCB?

I support Francesca's DISCUSS around use of SHOULDs.

Thanks for the fixes to IANA Considerations.  One minor issue remains, which is that we're allowing an automatically-expiring document (an I-D) to set the bar for what constitutes a valid Format Reference.  Given such a registration might be permanent, a disappearing reference seems a curious choice.  The discussion in the WG indicates that this is done to support experimental registrations and the like; it might be good for the text to say so.

I would like to thank Joe for the Opsdir review.

I just have some minor comments (I'm not a DNS expert):

In 2.3,
   to indicate that "foo://api.example.com:8443" is aliased to
   "svc4.example.net".  The owner of example.net, in turn, could publish
   this record:

   svc4.example.net.  7200  IN SVCB 3 svc4.example.net. (
       alpn="bar" port="8004" ech="..." )

   to indicate that these services are served on port number 8004, which
   supports the protocol "bar" and its associated transport in addition
   to the default transport protocol for "foo://".

I can understand how this record indicates that it supports protocol "bar", but it is not obvious to me how this record also indicates that it also supports "foo://".

2.4.1.  SvcPriority

   RRSets are explicitly unordered collections, so the SvcPriority field
   is used to impose an ordering on SVCB RRs.  SVCB RRs with a smaller
   SvcPriority value SHOULD be given preference over RRs with a larger
   SvcPriority value.

Would it be helpful for this text to indicate under what conditions this SHOULD is not a MUST?  Which is perhaps related to the text in section 5.1?

   The primary purpose of AliasMode is to allow aliasing at the zone
   apex, where CNAME is not allowed.  In AliasMode, the TargetName will
   be the name of a domain that resolves to SVCB, AAAA, and/or A
   records.  (See Section 6 for aliasing of SVCB-compatible RR types.)
   The TargetName SHOULD NOT be equal to the owner name, as this would
   result in a loop.

It was unclear to me that this is a SHOULD NOT rather than a MUST NOT.  I.e., are there some circumstances where it is useful to not comply with this.

   In AliasMode, records SHOULD NOT include any SvcParams, and
   recipients MUST ignore any SvcParams that are present.

Again, I wasn't sure why this isn't a MUST NOT rather than a SHOULD NOT?

Finally, thank you for providing the examples in 11.3, I found them to be particularly helpful.

Regards,
Rob

Thanks to Kyle Rose for the security feedback in the TSVART review.

** Section 2.1.  Per the ABNF (with the caveat that my manual review of such syntax might be rusty):

--  What role does “value = *OCTET” play in the specification of SvcParams?  It doesn’t appear to be used or explained.

-- Should a top-level ‘SvcParams’ rule be defined (i.e., define the formal syntax of the entire parameter which is a list of SvcParam)?

-- (Editorial) To make it clear that “char-string” is defined in Appendix A, it would be helpful to:

OLD
SvcParamValue = char-string

NEW
SvcParamValue = char-string    ; per Appendix A

** Section 3.1.  Recommend explicit saying which connection should be abandoned – s/the client SHOULD abandon the connection attempt/the client SHOULD abandon the connection attempt to the target service/

** Section 7.4.  Unpacking the first paragraph for easier commentary:

(a)   The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients
   MAY use to reach the service.  

(b) If A and AAAA records for TargetName
   are locally available, the client SHOULD ignore these hints.
   

(c) Otherwise, clients SHOULD perform A and/or AAAA queries for
   TargetName as in Section 3, and clients SHOULD use the IP address in
   those responses for future connections.  

(a) seems to be saying that the value of the SrcParamValue is going to return an IP address associated with a TargetName. (b) seems to be saying that if the client already has an IP address for the TargetName in the cache, then ignore the hints.  Per (c), why would A/AAAA queries need to be performed to resolve TargetName?  Isn’t the hint the associated IP address?

** Section 9.3.  Editorial.  s/the the/the/

** Section 10.  Editorial.  s/the value of the parameter is an ECHConfigList [ECH]/ the value of the parameter is an ECHConfigList per Section 4 of [ECH]

** Section 10.  Editorial. s/ProtocolNameList in Section 7.1/ ProtocolNameList in Section 7.1.2/

** Section 10.2. s/smaller SvcPriority/lower SvcPriority value/

** Section A.1  Per the ABNF:
-- What role does “item” rule play?  It’s not referenced or explained.  (see below)

-- It would be useful to state somewhere which ABNF rule corresponds to which form of the list.  Perhaps something like:

OLD 
   For implementations that allow "," and "\" in item values, the
   following escaping syntax applies:

NEW
For implementations that allow "," and "\" in item values, the   ‘comma-separated’ rule for the escaping syntax applies.  For those that do not required escaping, the ‘item’ syntax rule applies.

Thanks for the efforts on this specification. Thanks to Kyle Rose for his TSVART reviews, my understanding is those issues are not really transport related issues and has been addressed.

I am think I am sympathetic to Ben's discuss but also understand this is well within the HSTS norms. I will be watching that discussion.

I have only one question: My understanding on this specification is - if there is a record 

   _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net.

then _foo.example.com must not have any ServiceMode SVCB record. is that correct? it was not so obvious to me.

Thank you for the work put into this document. Important piece of work as it is related to some ADD documents as well. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tim Wicinski for the shepherd's write-up including the detailed section about the WG consensus even if I regret the absence of intended status justification. 

I hope that this helps to improve the document,

Regards,

-éric

Cosmetic one: I have seen only two "ordinary AAAA/A lookups" and too many "A or AAAA"... this hurts my IPv6 eyes ;-)

## Section 1
Just a thank you for such a well-written and clear introduction. This comment also applies to most of the document BTW !

## Section 1.1
"Enable SRV-like benefits (e.g. apex delegation, as mentioned above) for HTTP, where SRV [SRV] has not been widely adopted", if the "old" SRV has not been adopted, then what is the probability of having the "new" SVCB adopted ?

Should "HSTS" be expanded at first use ?

## Section 1.2
In "Cooperating DNS recursive resolvers will perform subsequent record resolution (for SVCB, A, and AAAA records)", is it assumed that only cached information (A, AAAA) will be used ? Else, it may slow down the resolution of the SVCB.

In "Additional Section of the response", is it assumed that the response in this sentence is only a response to a SVCB query ?

## Section 2.2
What is the reason for using uncompressed fully-qualified targetname ? Should there be some justifications for this absence of compression ?

## Section 2.4.1
Usually when "SHOULD" is used, the specification describes the exception(s).

## Section 2.4.2
Same comment about the use of "SHOULD" (also in many other places)

"In AliasMode, the TargetName will be the name of a domain that resolves to SVCB, AAAA, and/or A records. ", is it a "will" or a "MUST" ? Should "CNAME" also be a potential answer (at the expense of another query)?

"this AliasMode record can be replaced by a CNAME" except for apex ...

## Section 2.5.2
Suggest to use a SVCB RR rather than HTTPS to ease the reading of the example.

If compressed DNS name would be allowed (see my comment on sect 2.2) then using "." would bring nearly no size benefit.

## Section 3

Would a mechanism similar to happy eye ball be used to request SVCB, AAAA, and A ? It is described later in section 5 but an early hint would not hurt.

"Clients resolve AAAA and/or A records for the selected TargetName, and MAY choose between them using an approach such as Happy Eyeballs" why not a "SHOULD" ?

## Section 4.1
"authoritative DNS servers SHOULD return A, AAAA, and SVCB records in the Additional Section for any TargetNames that are in the zone", shouldn't the SVCB RRs be in the Answer section? What did I misread ?

## Section 7.2
Strongly suggest not to limit ports to UDP and TCP but either cite UDP and TCP as examples or include SCTP/DCCP.

## Section 7.4
"For best performance, server operators SHOULD include an "ipv6hint" parameter whenever they include an "ipv4hint" parameter." There is a bias in the sentence for "ipv4hint" and it should only applies when both "ipv6hint" and "ipv4hint" exist.

## Section 11.1
"zone owners SHOULD choose alias target names that indicate the scheme in use", would a "it is RECOMMENDED" be more applicable and suitable ?