Fwd: Last Call: <draft-ietf-dnsop-svcb-https-07.txt> (Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)) to Proposed Standard

FYI - Just making sure folks see this.

Cheers,


> Begin forwarded message:
> 
> From: The IESG <iesg-secretary@ietf.org>
> Subject: Last Call: <draft-ietf-dnsop-svcb-https-07.txt> (Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)) to Proposed Standard
> Date: 6 August 2021 at 2:42:26 am AEST
> To: "IETF-Announce" <ietf-announce@ietf.org>
> Cc: dnsop@ietf.org, dnsop-chairs@ietf.org, draft-ietf-dnsop-svcb-https@ietf.org
> Reply-To: last-call@ietf.org
> Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/eK12koaCT4YbXCdOH6uSybDTr8w>
> 
> 
> 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)'
>  <draft-ietf-dnsop-svcb-https-07.txt> 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))
> 
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

--
Mark Nottingham   https://www.mnot.net/