Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
draft-ietf-dnsop-svcb-https-12

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-svcb-https@ietf.org, rfc-editor@rfc-editor.org, tjw.ietf@gmail.com, warren@kumari.net
Subject: Protocol Action: 'Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)' to Proposed Standard (draft-ietf-dnsop-svcb-https-12.txt)

The IESG has approved the following document:
- 'Service binding and parameter specification via the DNS (DNS SVCB and
   HTTPS RRs)'
  (draft-ietf-dnsop-svcb-https-12.txt) as Proposed Standard

This document is the product of the Domain Name System Operations Working
Group.

The IESG contact persons are Warren Kumari and Robert Wilton.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

Ballot Text

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

This was originally approved on 2022-05-25 and sent to the RFC Editor.
However, it ended up stuck in MISREF state, stuck on draft-ietf-tls-esni , which we then learnt would be many months to progress.

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, had another WGLC, and IETF LC. 

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 ballot text... 


Document Quality

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


Personnel

Document Shepherd (DS):  Tim Wicinski
Responsible Area Director (RAD!): Warren Kumari

RFC Editor Note