Subject: Hopefully-final draft-ietf-dnsop-svcb-https-04 and nearing WGLC

From: Erik Nygren <[email-masked]>
Date: Wed, 17 Mar 2021 21:38:03 -0400

We've closed out most of the open issues on draft-ietf-dnsop-svcb-https
and it will be going to WGLC shortly.

Current version at:

      https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-04.txt

Hopefully we're done, but you can open issues against:

    https://github.com/MikeBishop/dns-alt-svc

This will likely get batched up while waiting for TLS ECH to publish due
to some cross-dependencies.

Change history for the last few versions:

   o  draft-ietf-dnsop-svcb-https-04

      *  Simplify the IANA instructions (pure First Come First Served)

      *  Recommend against publishing chains of >8 aliases

      *  Clarify requirements for using SVCB with a transport proxy

      *  Adjust guidance for Port Prefix Naming

      *  Minor editorial updates

   o  draft-ietf-dnsop-svcb-https-03

      *  Simplified escaping of comma-separated values

      *  Reorganized client requirements

      *  Added a warning about port filtering for cross-protocol attacks

      *  Clarified self-consistency rules for SvcParams

      *  Added a non-normative mapping summary table for HTTPS

   o  draft-ietf-dnsop-svcb-https-02

      *  Added a Privacy Considerations section

      *  Adjusted resolution fallback description

      *  Clarified status of SvcParams in AliasMode

      *  Improved advice on zone structuring and use with Alt-Svc

      *  Improved examples, including a new Multi-CDN example

      *  Reorganized text on value-list parsing and SvcPriority

      *  Improved phrasing and other editorial improvements throughout

   o  draft-ietf-dnsop-svcb-https-01

      *  Added a "mandatory" SvcParamKey

      *  Added the ability to indicate that a service does not exist

      *  Adjusted resolution and ALPN algorithms

      *  Major terminology revisions for "origin" and CamelCase names

      *  Revised ABNF

      *  Include allocated RR type numbers

      *  Various corrections, explanations, and recommendations

   o  draft-ietf-dnsop-svcb-https-00

      *  Rename HTTPSSVC RR to HTTPS RR

      *  Rename "an SVCB" to "a SVCB"

      *  Removed "design considerations and open issues" section and
         some other "to be removed" text

---------- Forwarded message ---------

A new version of I-D, draft-ietf-dnsop-svcb-https-04.txt
has been successfully submitted by Ben Schwartz and posted to the
IETF repository.

Name:           draft-ietf-dnsop-svcb-https
Revision:       04
Title:          Service binding and parameter specification via the DNS
(DNS SVCB and HTTPS RRs)
Document date:  2021-03-17
Group:          dnsop
Pages:          48
URL:
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-04.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https
Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-04
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04

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 [1].  The most recent
   working version of the document, open issues, etc. should all be
   available there.  The authors (gratefully) accept pull requests.