Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-09.txt

Ben Schwartz <bemasc@google.com> Mon, 09 May 2022 22:12 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF82C14F74B for <dnsop@ietfa.amsl.com>; Mon, 9 May 2022 15:12:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw3aHk6w70dJ for <dnsop@ietfa.amsl.com>; Mon, 9 May 2022 15:12:40 -0700 (PDT)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EEAC157B5D for <dnsop@ietf.org>; Mon, 9 May 2022 15:12:40 -0700 (PDT)
Received: by mail-ua1-x92e.google.com with SMTP id s1so5985623uac.6 for <dnsop@ietf.org>; Mon, 09 May 2022 15:12:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ZC+mYjjtCHG/BrBbUDils/i91Oljv7VLFO6aiJiS2Q=; b=liieb2Sw7fggjG7Z9xZls+m6nvZXhRJ/nwgw2qQEdKwFiRS02wma4Nl5/eKGh40fgO WsXpYEtvAekrOrUp9jF5IPPxDbTlqmNsCRh0SI1MRsNRpPK0b3N5A8CNr6xPQBKazqRZ +JncsW4nOsAONvoT05Ja2YqlHHUam/jayIsRsUtPouwk225Mq9rpjwLTt1koLRBuvjWU orlEmpxzajzOGLsiBm9t1+tIyCrujCY/YUUhsmJg31BL2fDeLzQxiqC7CjsRv5Er8MHE PBoENKlAO4bO14kI+LoPPIPuqXoUJx0Sbo0nO0EpLyXn5Aqp6RkdEo7gXNEDtOGkdmeI Yd0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3ZC+mYjjtCHG/BrBbUDils/i91Oljv7VLFO6aiJiS2Q=; b=mrws48lYh0twXkhR8q5GcuFvrrQJg40jcVQzIoBM+mg6/97RH280JXWMdu1UCKlAqf pqb44suufj6IabBIUGPTFyJtSAAnh6GERaFdJTsgTYsVz3vqHzW4g7EgVd+0nxxpQMih w8J24BThiZBbXOlXU+z9SZRuBF6mKeWlj5H32a+3161Jqtl0c220FeuxRmUeBC/eHFc9 fmXDrFKw2yvRL5sibeS/Y/5LdvZvRqTswFRuvRI1SVsi84C5O0E6OrQXujfV5aNR8eSg QPlDuaVQmTV/wxuMeAMPLYkUD/yqFdjh2GT7ht1fPEv0vqet1OwcvAAElOyKh8nlb0UQ Jv0w==
X-Gm-Message-State: AOAM531AYZsARMC7KlwULykvPdeStotOT15onCr12XeaEd1Ei2tA3kgO WTKOC0IJwJHlyLhnhfyUKDv457zvGkdDTijKeIQyag==
X-Google-Smtp-Source: ABdhPJw0SilLTU6xqck5khze96ndHTzO/zb7CvtbNmu8dIiGtH3HrAKJ1T2yWX+Es7LBC4WWw1wLSkl2FpOzbt6bGWU=
X-Received: by 2002:a9f:3193:0:b0:35d:21ec:4ae1 with SMTP id v19-20020a9f3193000000b0035d21ec4ae1mr9917252uad.100.1652134358640; Mon, 09 May 2022 15:12:38 -0700 (PDT)
MIME-Version: 1.0
References: <165186412363.20906.19748361087239400@ietfa.amsl.com> <CAL0qLwbbP=WV=gh6uT8icRGgFRL6h20N86HX2nFJr5jo+hNO1w@mail.gmail.com>
In-Reply-To: <CAL0qLwbbP=WV=gh6uT8icRGgFRL6h20N86HX2nFJr5jo+hNO1w@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 09 May 2022 18:12:27 -0400
Message-ID: <CAHbrMsBvDbb2ExnoVBzC+m5QOJUjifmaRGVCmj2=7dDdh9eXAA@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000097028305de9b812f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iSarDRRFLrTgPzSWFUVayAfM3eA>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-09.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2022 22:12:44 -0000

Yes, that's covered in the description:

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. The Format Reference
MAY be any individual's Internet-Draft, or a document from any other source
with similar assurances of stability and availability.

On Mon, May 9, 2022, 5:29 PM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> On Fri, May 6, 2022 at 12:09 PM <internet-drafts@ietf.org> wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations WG of the
>> IETF.
>>
>>         Title           : Service binding and parameter specification via
>> the DNS (DNS SVCB and HTTPS RRs)
>>         Authors         : Ben Schwartz
>>                           Mike Bishop
>>                           Erik Nygren
>>         Filename        : draft-ietf-dnsop-svcb-https-09.txt
>>         Pages           : 62
>>         Date            : 2022-05-06
>>
>> 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 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.
>>
>
> I see the change to Expert Review, which looks good.  Are we going with
> the idea of allowing an I-D to be a valid format reference, even though
> they expire, to enable things that are in development or experimental?
>
> -MSK
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>