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

The following Last Call announcement was sent out (ends 2023-04-03):

From: The IESG
To: IETF-Announce
CC: Tim Wicinski , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-svcb-https@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Service binding and parameter
specification via the DNS (DNS SVCB and
  HTTPS RRs)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-04-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.


Your attention please...
This is a second IETF LC for this document - it was originally approved on 2022-05-25 and sent to the RFC Editor.
However, it had a reference to a reference to a document (ECH in the TLS WG) which will still be many months in the making -- and other documents are now waiting on this document.

As the ECH reference was for an "optional feature", after discussions with the authors, WG, chairs, chairs of TLS, authors of ECH, authors of the other documents, IESG, etc we asked the RFC Editor to return the document. It has now had the ECH feature removed, and has had another WGLC, and this is the IETF LC on the removal of the text.

It probably didn't need all of this process stuff, but I figured it is better to have transparency (and, yes, this is being coordinated with the documents that rely on this doc!)
Please see the shepherd's writeup if this is confusing...

Diff from the previously approved version: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html

We now return you to your regularly scheduled LC text...


Abstract


  This document specifies the "SVCB" and "HTTPS" DNS resource record
  (RR) types to facilitate the lookup of information needed to make
  connections to network services, such as for HTTP origins.  SVCB
  records allow a service to be provided from multiple alternative
  endpoints, each with associated parameters (such as transport
  protocol configuration), and are extensible to support future uses
  (such as keys for encrypting the TLS ClientHello).  They also enable
  aliasing of apex domains, which is not possible with CNAME.  The
  HTTPS RR is a variation of SVCB for use with HTTP [HTTP].  By
  providing more information to the client before it attempts to
  establish a connection, these records offer potential benefits to
  both performance and privacy.

  TO BE REMOVED: This document is being collaborated on in Github at:
  https://github.com/MikeBishop/dns-alt-svc
  (https://github.com/MikeBishop/dns-alt-svc).  The most recent working
  version of the document, open issues, etc. should all be available
  there.  The authors (gratefully) accept pull requests.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/



No IPR declarations have been submitted directly on this I-D.

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

This document specifies the "SVCB" and "HTTPS" DNS resource record
(RR) types to facilitate the lookup of information needed to make
connections to network services, such as for HTTPS origins.  SVCB
records allow a service to be provided from multiple alternative
endpoints, each with associated parameters (such as transport
protocol configuration and keys for encrypting the TLS ClientHello).
They also enable aliasing of apex domains, which is not possible with
CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
origins.  By providing more information to the client before it
attempts to establish a connection, these records offer potential
benefits to both performance and privacy.


Working Group Summary:

Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records.  The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule.

Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/

WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/

This document carried on to the RFC Editor's quere where it was sitting for a long time waiting for the completion of draft-ietf-tls-esni.  This turned out to be taking much longer than had been expected, and this document was holding up other documents in other working groups, so after some discussion, the document was brought back from the RFC Editor's queue to the working group, the authors removed the sections referncing the ECH options to place in a new document, and
republished.  Their changes are here:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html

Also, the Area Director's discussion of this process

https://mailarchive.ietf.org/arch/msg/dnsop/5aiWtJbmAoqj7-5oD03Rgw1PEoo/


Document Quality:

While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this.

Document Shepherd:  Tim Wicinski

Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR


(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11)

  == Outdated reference: draft-ietf-httpbis-semantics has been published as
    RFC 9110

  -- Possible downref: Normative reference to a draft: ref. 'HTTP'

  ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110)

  ** Downref: Normative reference to an Informational RFC: RFC 7871

  == Outdated reference: draft-ietf-quic-http has been published as RFC 9114

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state

(15) There is one downward normative reference to  RFC 7871, which has one existing downward reference.

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews.

(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

This document specifies the "SVCB" and "HTTPS" DNS resource record
(RR) types to facilitate the lookup of information needed to make
connections to network services, such as for HTTPS origins.  SVCB
records allow a service to be provided from multiple alternative
endpoints, each with associated parameters (such as transport
protocol configuration and keys for encrypting the TLS ClientHello).
They also enable aliasing of apex domains, which is not possible with
CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
origins.  By providing more information to the client before it
attempts to establish a connection, these records offer potential
benefits to both performance and privacy.


Working Group Summary:

Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records.  The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule.

Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/

WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/

This document carried on to the RFC Editor's quere where it was sitting for a long time waiting for the completion of draft-ietf-tls-esni.  This turned out to be taking much longer than had been expected, and this document was holding up other documents in other working groups, so after some discussion, the document was brought back from the RFC Editor's queue to the working group, the authors removed the sections referncing the ECH options to place in a new document, and
republished.  Their changes are here:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html

Also, the Area Director's discussion of this process

https://mailarchive.ietf.org/arch/msg/dnsop/5aiWtJbmAoqj7-5oD03Rgw1PEoo/


Document Quality:

While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this.

Document Shepherd:  Tim Wicinski

Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR


(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11)

  == Outdated reference: A later version (-12) exists of
    draft-ietf-tls-esni-11

  ** Downref: Normative reference to an Informational RFC: RFC 7871

  -- Obsolete informational reference (is this intentional?): RFC 3513
    (Obsoleted by RFC 4291)

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) There is one normative reference for draft-ietf-tls-esni, that is not ready for advancement.

(15) There is one downward normative reference to  RFC 7871, which has one existing downward reference.

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews.

(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

This document specifies the "SVCB" and "HTTPS" DNS resource record
(RR) types to facilitate the lookup of information needed to make
connections to network services, such as for HTTPS origins.  SVCB
records allow a service to be provided from multiple alternative
endpoints, each with associated parameters (such as transport
protocol configuration and keys for encrypting the TLS ClientHello).
They also enable aliasing of apex domains, which is not possible with
CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
origins.  By providing more information to the client before it
attempts to establish a connection, these records offer potential
benefits to both performance and privacy.


Working Group Summary:

Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records.  The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule.

Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/

WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/

This document carried on to the RFC Editor's quere where it was sitting for a long time waiting for the completion of draft-ietf-tls-esni.  This turned out to be taking much longer than had been expected, and this document was holding up other documents in other working groups, so after some discussion, the document was brought back from the RFC Editor's queue to the working group, the authors removed the sections referncing the ECH options to place in a new document, and
republished.  Their changes are here:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html

Also, the Area Director's discussion of this process

https://mailarchive.ietf.org/arch/msg/dnsop/5aiWtJbmAoqj7-5oD03Rgw1PEoo/


Document Quality:

While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this.

Document Shepherd:  Tim Wicinski

Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR


(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11)

  == Outdated reference: A later version (-12) exists of
    draft-ietf-tls-esni-11

  ** Downref: Normative reference to an Informational RFC: RFC 7871

  -- Obsolete informational reference (is this intentional?): RFC 3513
    (Obsoleted by RFC 4291)

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) There is one normative reference for draft-ietf-tls-esni, that is not ready for advancement.

(15) There is one downward normative reference to  RFC 7871, which has one existing downward reference.

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews.

(19) N/A

(20) No Yang Necessary

[Ballot comment]
Thank you for the work on this document, and for addressing my previous DISCUSS and COMMENTs.

Many thanks to Cullen Jennings for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/.

Francesca

[Ballot discuss]
Thank you for the work on this document.

Many thanks to Cullen Jennings for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/.

Thank you for addressing my previous DISCUSS and COMMENTs. I have reviewed v-09 and I noticed 4 points were not addressed (or I missed them). Do let me know if you think no further clarifications were necessary - just making sure these were not missed, as I have not seen any answers to them.

Re: the use of SHOULD - thank you for adding context to most of them. I did not see any added context to these following two SHOULDs:

> Zone-file implementations SHOULD enforce self-consistency.

and

> If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD apply the same validation policy to SVCB.

If SHOULD is used, then it must be accompanied by at least one of:
(1) A general description of the character of the exceptions and/or in what areas exceptions are likely to arise.  Examples are fine but, except in plausible and rare cases, not enumerated lists.
(2) A statement about what should be done, or what the considerations are, if the "SHOULD" requirement is not met.
(3) A statement about why it is not a MUST.

Francesca

[Ballot comment]
4. -----

The value is then
  validated and converted into wire-format in a manner specific to each
  key.

FP: Section 15.3.1 states

  registration policy ([RFC8126], Section 4.5).  The designated expert
  MUST ensure that the Format Reference is stable and publicly
  available, and that it specifies how to convert the SvcParamValue's
  presentation format to wire format.

This covers the conversion, but does not cover the validation mentioned above. (This could be really easily addressed by making sure that not only it specifies how to convert but also how to validate).


10. -----

Table 1

FP: The table reports that

  | 65280-65534 | N/A            | Private Use    | (This document) |

But that is not specified in the text above, that only talks about expert review registration policy. That should be made consistent.

[Ballot comment]
While a little more complicated that I'd wish, it seems this does seem to be one of the simpler and more robust solutions to the "CNAME at apex" problem.

As for Ben's (former) DISCUSS, Ben is correct that this document pushes deployments towards https and makes assumptions that the http and https namespaces are providing identical context even though formally this is not the case. While technically this is a protocol issue, I do believe that in practice everyone already assumes that the content for a certain domain name would be the same for http and https unless the http just contains a redirect to https. I find this case similar to the case where everyone in the world assumes Paul@nohats.ca and paul@nohats.ca goes to the same mailbox, even though SMTP formally claims the LHS may not be interpreted in such a way and could be delivered to different people.

As such, I am not taking over Ben's DISCUSS on this.

[Ballot comment]
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.

[Ballot discuss]
Section 15.3.1 creates a new IANA registry with a First Come First Served registration policy.  RFC 8126 says this of that policy:

  It is also important to understand that First Come First Served
  really has no filtering.  Essentially, any well-formed request is
  accepted.

Yet this document stipulates:

  [...]  The Format Reference
  MUST specify how to convert the SvcParamValue's presentation format
  to wire format and MAY detail its intended meaning and use.  An entry
  MAY specify a Format Reference of the form "Same as (other key Name)"
  if it uses the same presentation and wire formats as an existing key.

These seem to me to be in conflict.  We're asking IANA to do more than what the BCP says is valid here.  Should this instead be Expert Review?

[Ballot comment]
I support Francesca's DISCUSS around use of SHOULDs.

I also support Ben's DISCUSS about IANA Considerations.  I originally held a DISCUSS that noted Section 15.3.1 creates a new IANA registry with a First Come First Served registration policy.  RFC 8126 says this of that policy:

  It is also important to understand that First Come First Served
  really has no filtering.  Essentially, any well-formed request is
  accepted.

Yet this document stipulates:

  [...]  The Format Reference
  MUST specify how to convert the SvcParamValue's presentation format
  to wire format and MAY detail its intended meaning and use.  An entry
  MAY specify a Format Reference of the form "Same as (other key Name)"
  if it uses the same presentation and wire formats as an existing key.

These seem to me to be in conflict.  We're asking IANA to do more than what the BCP says is valid here.  Should this instead be Expert Review?

[Ballot discuss]
[Appendix D.2]

* Sorry to be super nitpicky/petty about this.

  With respect to Figure 7: IPv4-mapped IPv6 addresses have a complicated
  history (see RFC 4942 S2.2 for an amuse-bouche, as well as itojun's
  draft-itojun-v6ops-v4mapped-harmful).

  Unless there is something very useful to be gained by the inclusion of this
  example (what?) I would strongly suggest removing it.  I fear it will only
  cause confusion.

[Ballot comment]
[S2.3; comment]

* "When a prior CNAME or SVCB record has aliased to a SVCB record, each
  RR shall be returned under its own owner name."

  I think this could use some explanation and a reference to Section 11.
  Perhaps something along the lines of

      This is in account of the client resolution process [Section 3].
      See also discussion in [Section 11.1].

[Ballot discuss]
Section 15.3.1 creates a new IANA registry with a First Come First Served registration policy.  RFC 8126 says this of that policy:

  It is also important to understand that First Come First Served
  really has no filtering.  Essentially, any well-formed request is
  accepted.

Yet this document stipulates:

  [...]  The Format Reference
  MUST specify how to convert the SvcParamValue's presentation format
  to wire format and MAY detail its intended meaning and use.  An entry
  MAY specify a Format Reference of the form "Same as (other key Name)"
  if it uses the same presentation and wire formats as an existing key.

These seem to me to be in conflict.  We're asking IANA to do more than what the BCP says is valid here.  Should this instead be Expert Review?

[Ballot discuss]
Thank you for the work on this document

Many thanks to Cullen Jennings for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/.

I am concerned by the use of SHOULD in this document. In several places (see 1. below for what I identified as problematic SHOULDs) the document lacks text about why these are SHOULD and not MUST or MAY. I agree with John Klensin, who formulated it very clearly:

If SHOULD is used, then it must be accompanied by at least one of:
(1) A general description of the character of the exceptions and/or in what areas exceptions are likely to arise.  Examples are fine but, except in plausible and rare cases, not enumerated lists.
(2) A statement about what should be done, or what the considerations are, if the "SHOULD" requirement is not met.
(3) A statement about why it is not a MUST.


I also have a number of non blocking comments and questions. I will appreciate answers to my questions, to improve my understanding. If any clarification comes out of it, I hope it will help improve the document.

Francesca

1. -----

FP: SHOULD lacking additional context:

  Within a SVCB RRSet, all RRs SHOULD have the same Mode.  If an RRSet

  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.

  In AliasMode, the SVCB record aliases a service to a TargetName.
  SVCB RRSets SHOULD only have a single resource record in AliasMode.
  If multiple are present, clients or recursive resolvers SHOULD pick
  one at random.

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

  Zone-file implementations
  SHOULD enforce self-consistency.

  If the client is SVCB-optional, and connecting using this list of
  endpoints has failed, the client SHOULD attempt non-SVCB connection
  modes.

  If the client enforces DNSSEC validation on A/AAAA responses, it
  SHOULD apply the same validation policy to SVCB.

  If the client is unable to complete SVCB resolution due to its chain
  length limit, the client SHOULD fall back to the authority endpoint,
  as if the origin's SVCB record did not exist.

  For compatibility with clients that require default transports, zone
  operators SHOULD ensure that at least one RR in each RRSet supports
  the default transports.

  Global Scoped Entry Registry [Attrleaf].  The scheme SHOULD have an
  entry in the IANA URI Schemes Registry [RFC7595].  The scheme SHOULD
  have a defined specification for use with SVCB.

[Ballot comment]

2. -----

  This subsection briefly describes the SVCB RR in a non-normative
  manner.  (As mentioned above, this all applies equally to the HTTPS
  RR which shares the same encoding, format, and high-level semantics.)

FP: I am not sure about why this section is described as non-normative but does define requirements etc. Maybe it is normatively described somewhere else? Then a pointer to that makes sense. Also why does this mention encoding and format but there is no encoding specified.

3. -----

  format specific to the SvcParamKey.  Their definition should specify
  both their presentation format and wire encoding (e.g., domain names,
  binary data, or numeric values).  The initial SvcParamKeys and

FP: I have the feeling "should" is not the right term here, I suggest to change to "must" or "is required to". Also, it would have been useful to me to add a pointer to RFC 8499 in the terminology about "presentation format".

4. -----

The value is then
  validated and converted into wire-format in a manner specific to each
  key.

FP: Section 15.4 states

  registration policy ([RFC8126], Section 4.4).  The Format Reference
  MUST specify how to convert the SvcParamValue's presentation format
  to wire format and MAY detail its intended meaning and use.  An entry

This covers the conversion, but does not cover the validation mentioned above.

5. -----

  SvcParams in presentation format MAY appear in any order, but keys
  MUST NOT be repeated.

FP: Seems to contradict

  SvcParamKeys SHALL appear in increasing numeric order.

6. -----

  If the client has an in-progress TCP connection to
  [2001:db8::2]:1234, it MAY proceed with TLS on that connection using
  ech="222...", even though the other record in the RRSet has higher
  priority.

FP: I believe this is descriptive of the example and should not use BCP 14 MAY.

7. -----


  For example, the following is a valid list of SvcParams:

  ech=... key65333=ex1 key65444=ex2 mandatory=key65444,ech


FP: I expected this to be a comma separated list.

8. -----

  length prefix.  In presentation format, the value is a single
  ECHConfigList encoded in Base64 [base64].  Base64 is used here to

FP: Please clarify that "Base 64 Encoding" (Section 4) is used (rather than "Base 64 Encoding with URL and Filename Safe Alphabet" (Section 5))

9. -----

FP: According to 8126, the registry "Service Parameter Keys (SvcParamKeys)" should include a change controller field.

10. -----

Table 1

FP: The table reports that

  | 65280-65534 | N/A            | Private Use    | (This document) |

But that is not specified in the text above, that only talks about first come first serve registration policy. That should be made consistent.

# Nits and Editorials

11. ------

When the "=" is omitted, the value is interpreted as empty.

FP: When the optional "=" SvcParamValue is omitted

12. -----

  All protocols employing "http://" or "https://" URLs SHOULD respect
  HTTPS RRs.  For example, clients that support HTTPS RRs and implement

FP: I am not sure how the first sentence is supposed to be implemented, hence why BCP 14 SHOULD is used here. I also think "respect HTTPS RRs" might not be the clearest wording.

IANA issue identified by Ben Kaduk: I can confirm that IANA can't verify that a reference specifies how to convert the SvcParamValue's presentation format to wire format (a MUST in Section 15.3.1). If this is required for registration, the registration procedure needs to be changed from FCFS to Specification Required (which involves expert review).

[Ballot comment]
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 ?

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
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 would 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.

[Ballot discuss]
I'd like to have a (hopefully brief!) discussion about our description of
the "strict transport security" functionality the HTTPS RRtype provides,
with respect to its accuracty/completeness and how explicit vs implicit we
should be about the corresponding divergence from "pure" HTTP behavior.

It's pretty clear that at a pure HTTP protocol level (which as far as I
can tell is the scope of applicability that we claim) that resources
accessed with "http" scheme and resources accessed with "https" scheme
have no intrinsic relationship -- §4.2.2 of
draft-ietf-httpbis-semantics-19 says:

  Resources made available via the "https" scheme have no shared
  identity with the "http" scheme.  They are distinct origins with
  separate namespaces.  [...]

But the procedures in this document (e.g., §9.5, §9) seem pretty clear
that, when an HTTPS record is published, accesses for "http" scheme
resources should be converted to "https" scheme accesses, with implication
that the client should expect to get the same resource back from the
modified query compared to the unmodified "http"-scheme one.

While there is a caution in §9.5 that:

  If this redirection would result in a loss of functionality (e.g.
  important resources that are only available on the "http" origin),
  the operator MUST NOT publish an HTTPS RR.

but in my reading it leaves some important details as only implicit!
We need to care not only about resources only available on one vs the
other origin, but also about whether the translation would change the
semantics of the client's request/response exchange.  That is, whether the
resources accessible by the different schemes are actually analogous
(which, per the above, is not required by HTTP and is subject to the site
administrator's control or in some cases other application protocols on
top of HTTP used by that origin).

This (mostly implicit) requirement is a potential barrier for adoption of
the HTTPS RRtype, and while the precondition is very often going to be
satisfied, I wanted to get a sense for whether we should make the
requirement more explicit, and possibly more prominent in the document
(e.g., mention it in the Introduction).  I don't know what the right
answer is, but it seems important enough to ensure that the topic receives
deliberate consideration.

[Ballot comment]
First off, thanks for this well-written document!  It was pretty clear and
easy to read despite covering some fairly complex logic.

I made a github pull request with some hopefully boring editorial
suggestions: https://github.com/MikeBishop/dns-alt-svc/pull/365

I did have a few high-ish-level thoughts that I either wasn't sure where
to put in the section-by-section comments or wanted to make a bit more
prominent.

The first is a bit hard for me to describe, but basically, when we
construct a QNAME for an SVCB or HTTPS query, we include information
reflecting URI scheme and port, but when we get a TargetName back, that's
been flattened to a single name, in some sense "using up more" of the DNS
hostname namespace under the control of the alternative endpoint then in
the authority's namespace.  That is, if I wanted to provide service for
both "foo" and "bar" schemes on two ports each, in order to serve all
four combinations for a single service name, I would need to allocate four
hostnames for alternative endpoints.  We do mention this property as it
relates to URI schemes, in §11.1 where we say that "zone owners SHOULD
choose alias target names that indicate the scheme in use", but I didn't
see much discussion of the port-related aspects.  I know that the
ServiceMode response can include a port to use in the parameters, so it's
not really a concern about losing flexibility of what ports to use.  It
just seems "unbalanced" in some sense that I can't really put my finger
on.  On the other hand, it's not like hostnames are a particularly limited
resource, so I don't really see any practical consequences of this setup;
I'm just curious if this is a topic that the WG gave much consideration
to.

I was also struck by the procedure near the end of §3 where we append to
the very end of the priority list an endpoint specified by the final value
of $QNAME combined with the port number from the (original) authority
endpoint.  This seems a strange combination, since the authority port
number is chosen by the origin but the final QNAME will potentially be a
service operator rather far removed from the origin.  Making provision
for what essentially requires a tight coupling between these entities
(when non-default ports are used, at least) feels somewhat at odds with
the stated goal of allowing delegation of operational authority that I
take to imply a more "hands-off" or independently operated approach.
While I understand the utility in picking a single port to use for this
last-ditch entry on the priority list, it doesn't seem like the port from
the original authority is the only choice.  One might imagine using the
default port for the scheme, or the last 'port' SvcParam encountered in
alias chasing, or probably other things as well.  I suspect there are some
subtleties here, but I don't think I can think about it in much depth at
the moment, so I hope that the WG has already undertaken such
consideration.

I found it a bit surprising (though well described and in that sense well
justified) that we limit ourselves to using ALPN values for which the ALPN
value uniquely identifies the suite of protocols to use, most notably
relating to whether TLS or DTLS is used.  That is not something I
typically associate as being a property that ALPN provides, though as I
look through the registry, almost all of the existing entries (that I know
much about) do seem to provide that property.  Do we know of any ALPN
values that are unusable as a result of this restriction?  I'm somewhat
curious what the TLS DEs would say if faced with registration requests
designed to "split" an existing ALPN registration so that it would be
usable with SVCB.

The registration procedure for the new Service Parameters registry
(Section 15.3.1) starts off saying that it's FCFS, but accompanies that
with a MUST-level requirement for "MUST specify how to convert the
SvcParamValue's presentation format to wire format" (plus some MAYs as
well).  I'm somewhat surprised that IANA is willing to accept
responsibility for assessing whether the "MUST specify..." has been met.
Perhaps a policy of Expert Review with directions to the experts that
allocations are "shall issue" provided the MUST is satisfied would be more
appropriate?

Section 1.2

  In ServiceMode, the SvcParams of the SVCB RR provide an extensible
  data model for describing alternative endpoints that are
  authoritative for the origin, along with parameters associated with
  each of these alternative endpoints.

(editorial) Since the term "origin" has a specific meaning in the HTTP
context, and this document covers both the generic SVCB and the
HTTP-specific HTTPS records, but this section is supposed to be the
"generic" one, I wonder if we can come up with a different term than
"origin" to use here.  Would "service" or a derived term be consistent
with our definitions?

Section 2.1

  The presentation format of the record is:

  Name TTL IN SVCB SvcPriority TargetName SvcParams

  The SVCB record is defined specifically within the Internet ("IN")
  Class ([RFC1035]).

Should we say something about how "Name" and "TTL" have the same meaning
as in RFC 1035?

  alpha-lc      = %x61-7A  ;  a-z
  SvcParamKey  = 1*63(alpha-lc / DIGIT / "-")
  SvcParam      = SvcParamKey ["=" SvcParamValue]
  SvcParamValue = char-string
  value        = *OCTET

I'd suggest putting some comments in the ABNF that  is
defined in Appendix A and that  and  are related as
described in the prose.

  Arbitrary keys can be represented using the unknown-key presentation
  format "keyNNNNN" where NNNNN is the numeric value of the key type
  without leading zeros.  A SvcParam in this form SHALL be parsed as
  specified above, and the decoded value SHALL be used as its wire
  format encoding.

Being SEC AD makes me think about edge cases a lot; do we want to say
anything about whether a parser is required to be able to handle
"keyNNNNN" for key types defined in this document?  (Not that parsing DNS
presentation format is the best thing to do in the first place, but it
surely happens...)

Section 2.4.2

  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.

Why is this not a "MUST NOT"?  Does it ever make sense to cause such a
loop?

  Using AliasMode maintains a separation of concerns: the owner of
  foosvc.example.net can add or remove ServiceMode SVCB records without
  requiring a corresponding change to example.com.  Note that if
  foosvc.example.net promises to always publish a SVCB record, this
  AliasMode record can be replaced by a CNAME, which would likely
  improve performance.

So this would be "_8080._foo.example.com CNAME foosvc.example.net" rather
than "example.com CNAME foosvc.example.net"?  I wonder if clarifying that
it's not "example.com CNAME foosvc.example.net" is worthwhile.

Section 3.1

For a section titled "Handling resolution failures", perhaps we should
also give guidance on how resolution failures should be handled when DNS
responses are not cryptographically protected?  (I assume "proceed to the
fallback", but for completeness' sake...)

Section 4.3

                                    For complex value types whose
  interpretation might differ between implementations or have
  additional future allowed values added (e.g.  URIs or "alpn"),
  resolvers SHOULD limit validation to specified constraints.

I'm not entirely sure what "specified constraints" is intended to mean,
here.  Would it be those constrains specified as always suitable for
validation in the document that defines the SvcParam in question, or
something else?

Section 5.2

                                      As a performance optimization, if
  some of the SVCB records in the response can be used without
  requiring additional DNS queries, the client MAY prefer those
  records, regardless of their priorities.

This might be a performance optimization for the initial connection setup
while being a performance de-optimization for the actual application
traffic that goes over the connection (i.e., the authoritative's
priority values might be assumed to provide actual value to the user).
Did the WG discuss whether or not to go into such subtleties here?

Section 7.1.2

  Clients SHOULD NOT attempt connection to a service endpoint whose
  SVCB ALPN set does not contain any supported protocols.  To ensure
  consistency of behavior, clients MAY reject the entire SVCB RRSet and
  fall back to basic connection establishment if all of the RRs
  indicate "no-default-alpn", even if connection could have succeeded
  using a non-default alpn.

(editorial) Just to confirm: these two directives are only related in that
they cover client ALPN handling, and there is no expectation that the "MAY
reject" is preconditioned on "SVCB ALPN set does not contain any supported
protocols"?  I might consider splitting into two paragraphs, even though
my general preference is to avoid single-sentence paragraphs.

Section 7.2

  The "port" SvcParamKey defines the TCP or UDP port that should be
  used to reach this alternative endpoint.  [...]

Is this intentionally excluding SCTP/DCCP/etc?

Section 9.3

  Origins that publish an "ech" SvcParam in their HTTPS record SHOULD
  also publish an "ech" SvcParam for any alt-authorities.  [...]

Just to confirm I'm understanding this properly: this is saying that if an
origin publishes an HTTPS RR with an "ech" SvcParam (any single RR in the
RRset suffices to trigger the condition), then the origin should also
publish HTTPS records for any alt-authorities that it would send in an
Alt-Svc header field, and those other HTTPS records should all include an
"ech" SvcParam as well?  I'm a little confused at why the RFC 7838
"alt-authorities" keyword is used here without any specific reference to
Alt-Svc itself.  (There are only three instances of the string
"alt-authorit" in this document, two of which are in this paragraph; the
third is clearly marked as applying to the Alt-Svc usage.)

Section 9.4

  Clients MUST NOT use an HTTPS RR response unless the client supports
  TLS Server Name Indication (SNI) and indicates the origin name when
  negotiating TLS.  This supports the conservation of IP addresses.

I could sort-of see a misreading of this that says you have to put the
real origin in the SNI extension and not use ECH with a separate fronting
origin.  Maybe we want to say something about "uses SNI (possibly in
conjunction with ECH) to indicate the origin name"?

Section 11.2

  queries for TargetName in advance (see Section 5).  Unless otherwise
  specified, the convention is to set TargetName to the service name
  for an initial ServiceMode record, or to "." if it is reached via an
  alias.  For foo://foo.example.com:8080, this might look like:

I think it would be helpful to show an example of the "set TargetName to the
service name for an initial ServiceMode record" in addition to the alias
example that is shown.

Section 11.3.3

  Suppose that svc.example's default server pool supports HTTP/2, and
  it has deployed HTTP/3 on a new server pool with a different
  configuration.  This can be expressed in the following form:

  $ORIGIN svc.example. ; A hosting provider.
  pool  7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..."

The prose suggests that perhaps the new pool is h3-only and doesn't support
HTTP/2, but the actual example lists both alpn values.  I guess it also omits
no-default-alpn, so the new pool actually supports all three http versions...

Section 11.3.4

  *  The A, AAAA, and HTTPS resolutions are independent lookups, so
      clients may observe and follow different CNAMEs to different CDNs.
      Clients may thus find a TargetName pointing to a name other than
      the one which returned along with the A and AAAA lookups and will
      need to do an additional resolution for them.  [...]

(editorial) I think something went awry near "the one which returned along
with", as it's not even clear whether there are separate queries vs
additional-section responses in the intended scenario.

Section 13

Do we want to mention the discussion in §3.2 about using caution in
resolving SVCB when using a proxy?

I note that draft-ietf-tls-esni has a note (its §10.2) explaining that
DNSSEC or other protection is not really needed for ECH config, since an
attacker that controls DNS can already defeat ECH protections.  Do we want
to include similar discussion or otherwise mention this topic (e.g., by
reference)?

Section 15.3.2

  | 65535      | N/A            | Reserved      | (This document) |
  |            |                | ("Invalid      |                |
  |            |                | key")          |                |

Do we care that 'I' is not a lowercase letter?

Section 15.4

I always worry somewhat when we propose a new mechanism with no worked
examples for it (in this case, protocols using SVCB per the "MUST have an
entry for its scheme" requirement in §12).  Perhaps the HTTPS example is
close enough that my worries are groundless.

Section 17.1

Why is [DNAME] classified as normative?  I only see one reference to it,
in a list of examples of possible ways that resolvers might follow
aliases, which does not seem like a "protocol feature" of this document.

I could also perhaps see an argument that references to [HSTS] are just by
way of analogy or indicating that we provide equivalent behavior, which
would not seem to require the reader to understand [HSTS] in order to
implement this specification.

RFC 6147 is referenced only as part of a "MUST NOT perform DNS64"
construction, which seems to indicate that it is *not* a normative
reference.

Appendix D.2

[I did not carefully review the examples for internal consistency,
trusting that this document has received ample review already.]

[Ballot comment]
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?

[Ballot comment]
Two things I found confusing:

(Sec 2.4.2) "Note that if foosvc.example.net promises to always publish a SVCB record, this AliasMode record can be replaced by a CNAME..."

I'm not following the logic here. Why would it be insufficient for foosvc.example.net to always publish A and/or AAAA records? Put another way, how does AliasMode improve on CNAME for non-apex domains?

(Sec 3) I found this paragraph confusing:

"Once SVCB resolution has concluded, whether successful or not, SVCB-optional clients SHALL append to the priority list an endpoint consisting of the final value of $QNAME, the authority endpoint's port number, and no SvcParams. (This endpoint will be attempted before falling back to non-SVCB connection modes. This ensures that SVCB-optional clients will make use of an AliasMode record whose TargetName has A and/or AAAA records but no SVCB records.)"

There are three resolution outcomes AFAICT:

(a) A successful resolution in ServiceMode, in which case there is indeed an existing "priority list" but there is no AliasMode record to leverage. So what does the parenthetical refer to?

(b) A successful resolution in AliasMode, in which case the client has no priority list to work through, and should just connect to $QNAME.

(c) Unsuccessful resolution, in which case $QNAME is the original service name, which would then have to use a non-SVCB connection mode.

Editorially, this paragraph seems to unhelpfully combine three quite distinct outcomes into a single model. Or perhaps I've totally misunderstood it, which is maybe worse?

[Ballot comment]
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.

[Ballot comment]
Thanks to Kyle Rose for the security feedback in the TSVART review.

** Section 2.1.  Per the ABNF (with the caveat that my manually 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.

[Ballot comment]
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.

For some reason this was stuck in IESG Eval state for a long time:
"2021-10-13 13:33:45 -0700 -08 Warren Kumari IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead".

I've done a bunch of archeology to see if I can figure out what, if anything, it was waiting on, but have had no luck finding anything, so ¯\_(ツ)_/¯. I'm poking all of the buttons and twiddling all the knobs to see if I can make it move...

Changed action holders to Erik Nygren, Mike Bishop, Benjamin Schwartz (Waiting on update from authors. Ben (Aug 23rd): "FYI, we've received good feedback from area reviews, and are planning a -08 to incorporate those improvements.  We probably shouldn't proceed to IESG review until after those changes are published.")

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnsop-svcb-https-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

We understand that, upon approval of this document, there are three actions which we must complete.

First, in the Resource Record (RR) TYPEs registry on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

two existing registrations will be changed as follows:

TYPE: SVCB
Value: 64
Meaning: General Purpose Service Endpoints
Reference: [ RFC-to-be ]

TYPE: HTTPS
Value: 65
Meaning: HTTPS Specific Service Endpoints
Reference: [ RFC-to-be ]

The YANG module [iana-dns-class-rr-type] must be updated as defined in [RFC-ietf-dnsop-iana-class-type-yang-05].

IANA Question --> The entries in Section 14.4 (Table 2) appear to have the same "TYPE" and registry as sections 14.1 and 14.2. Are these duplicates, or are they supposed to be new registrations? If these are duplicates, how should we update the "Meaning" field?

Second, a new registry is to be created called the Service Binding (SVCB) Parameter Registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The registry is managed via First Come, First Served as defined in RFC8126 for values between 0 and 65279. Values from 65280 to 65534 are used for Private Use as defined in RFC8126. Value 65535 is reserved. There are initial registrations in the new registry as follows:

+=============+=================+================+=================+
| Number | Name | Meaning | Format |
| | | | Reference |
+=============+=================+================+=================+
| 0 | mandatory | Mandatory keys | [ RFC-to-be ] |
| | | in this RR | Section 7 |
+-------------+-----------------+----------------+-----------------+
| 1 | alpn | Additional | [ RFC-to-be ] |
| | | supported | Section 6.1 |
| | | protocols | |
+-------------+-----------------+----------------+-----------------+
| 2 | no-default-alpn | No support for | [ RFC-to-be ] |
| | | default | Section 6.1 |
| | | protocol | |
+-------------+-----------------+----------------+-----------------+
| 3 | port | Port for | [ RFC-to-be ] |
| | | alternative | Section 6.2 |
| | | endpoint | |
+-------------+-----------------+----------------+-----------------+
| 4 | ipv4hint | IPv4 address | [ RFC-to-be ] |
| | | hints | Section 6.4 |
+-------------+-----------------+----------------+-----------------+
| 5 | ech | Encrypted | [ RFC-to-be ] |
| | | ClientHello | Section 6.3 |
| | | info | |
+-------------+-----------------+----------------+-----------------+
| 6 | ipv6hint | IPv6 address | [ RFC-to-be ] |
| | | hints | Section 6.4 |
+-------------+-----------------+----------------+-----------------+
| 65280-65534 | N/A | Private Use | [ RFC-to-be ] |
+-------------+-----------------+----------------+-----------------+
| 65535 | N/A | Reserved | [ RFC-to-be ] |
| | | ("Invalid | |
| | | key") | |
+-------------+-----------------+----------------+-----------------+

Third, in the Underscored and Globally Scoped DNS Node Names registry also on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

a new registration is to be made as follows:

RR Type: HTTPS
NODE NAME: _https
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-08-19):

From: The IESG
To: IETF-Announce
CC: Tim Wicinski , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-svcb-https@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Service binding and parameter
specification via the DNS (DNS SVCB and
  HTTPS RRs)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-08-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies the "SVCB" and "HTTPS" DNS resource record
  (RR) types to facilitate the lookup of information needed to make
  connections to network services, such as for HTTPS origins.  SVCB
  records allow a service to be provided from multiple alternative
  endpoints, each with associated parameters (such as transport
  protocol configuration and keys for encrypting the TLS ClientHello).
  They also enable aliasing of apex domains, which is not possible with
  CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
  origins.  By providing more information to the client before it
  attempts to establish a connection, these records offer potential
  benefits to both performance and privacy.

  TO BE REMOVED: This document is being collaborated on in Github at:
  https://github.com/MikeBishop/dns-alt-svc
  (https://github.com/MikeBishop/dns-alt-svc).  The most recent working
  version of the document, open issues, etc. should all be available
  there.  The authors (gratefully) accept pull requests.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7871: Client Subnet in DNS Queries (Informational - Internet Engineering Task Force (IETF))
    draft-ietf-tls-esni: TLS Encrypted Client Hello (None - Internet Engineering Task Force (IETF))

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

This document specifies the "SVCB" and "HTTPS" DNS resource record
(RR) types to facilitate the lookup of information needed to make
connections to network services, such as for HTTPS origins.  SVCB
records allow a service to be provided from multiple alternative
endpoints, each with associated parameters (such as transport
protocol configuration and keys for encrypting the TLS ClientHello).
They also enable aliasing of apex domains, which is not possible with
CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
origins.  By providing more information to the client before it
attempts to establish a connection, these records offer potential
benefits to both performance and privacy.


Working Group Summary:

Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records.  The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule.

Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/

WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/

Document Quality:

While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this.

Document Shepherd:  Tim Wicinski

Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR


(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11)

  == Outdated reference: A later version (-12) exists of
    draft-ietf-tls-esni-11

  ** Downref: Normative reference to an Informational RFC: RFC 7871

  -- Obsolete informational reference (is this intentional?): RFC 3513
    (Obsoleted by RFC 4291)

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) There is one normative reference for draft-ietf-tls-esni, that is not ready for advancement.

(15) There is one downward normative reference to  RFC 7871, which has one existing downward reference.

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews.

(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

This document specifies the "SVCB" and "HTTPS" DNS resource record
(RR) types to facilitate the lookup of information needed to make
connections to network services, such as for HTTPS origins.  SVCB
records allow a service to be provided from multiple alternative
endpoints, each with associated parameters (such as transport
protocol configuration and keys for encrypting the TLS ClientHello).
They also enable aliasing of apex domains, which is not possible with
CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
origins.  By providing more information to the client before it
attempts to establish a connection, these records offer potential
benefits to both performance and privacy.


Working Group Summary:

Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records.  The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule.

Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/

WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/

Document Quality:

While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this.

Document Shepherd:  Tim Wicinski

Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR


(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11)

  == Outdated reference: A later version (-12) exists of
    draft-ietf-tls-esni-11

  ** Downref: Normative reference to an Informational RFC: RFC 7871

  -- Obsolete informational reference (is this intentional?): RFC 3513
    (Obsoleted by RFC 4291)

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) There is one normative reference for draft-ietf-tls-esni, that is not ready for advancement.

(15) There is one downward normative reference to  RFC 7871, which has one existing downward reference.

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews.

(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

This document specifies the "SVCB" and "HTTPS" DNS resource record
(RR) types to facilitate the lookup of information needed to make
connections to network services, such as for HTTPS origins.  SVCB
records allow a service to be provided from multiple alternative
endpoints, each with associated parameters (such as transport
protocol configuration and keys for encrypting the TLS ClientHello).
They also enable aliasing of apex domains, which is not possible with
CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
origins.  By providing more information to the client before it
attempts to establish a connection, these records offer potential
benefits to both performance and privacy.


Working Group Summary:

Working group consensus was strong.

Document Quality:

While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this.

Document Shepherd:  Tim Wicinski

Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR


(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11)

  == Outdated reference: A later version (-12) exists of
    draft-ietf-tls-esni-11

  ** Downref: Normative reference to an Informational RFC: RFC 7871

  -- Obsolete informational reference (is this intentional?): RFC 3513
    (Obsoleted by RFC 4291)

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) There is one normative reference for draft-ietf-tls-esni, that is not ready for advancement.

(15) There is one downward normative reference to  RFC 7871, which has one existing downward reference.

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews.

(19) N/A

(20) No Yang Necessary