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

Joe Abley <jabley@hopcount.ca> Tue, 11 May 2021 16:20 UTC

Return-Path: <jabley@hopcount.ca>
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 E77D53A1D2D for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 09:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3nbSlDdDlFR for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 09:20:04 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628AD3A1D1E for <dnsop@ietf.org>; Tue, 11 May 2021 09:20:04 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id a22so18716722qkl.10 for <dnsop@ietf.org>; Tue, 11 May 2021 09:20:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZKmkRhboseVeu2dh7vdc03RYizKkXP9WmrjckMZLTRo=; b=BCIXui1klFjnV0qyRds/HmWssWjDisdTTHblu3XKN2YXxrEZDXddjo7irmVVecpGJQ OKtV/w0pc3WXxbhPID8K/T/T7wgxATYnmuLtFKWqHPasqYgQlm+F4MThSQMre52RGnu5 CtJMoX7AYoor0x04RKTdLnNn2TQvbMx7oDiMQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZKmkRhboseVeu2dh7vdc03RYizKkXP9WmrjckMZLTRo=; b=snGntU8oSOlPVBtufac2pJOOdqGZQs4nCsYM0mYngdDGOh7rYzNZwUDeeM0vqaP0d8 DyyYMjLm0U9gTh7KHZJ5hWmCcsTAkBE34adrPohmeKMagjGc9TRQTQK3SsvosKBYPM0o IWUfJla8417o1LS949uxCfDdm1pXSTn+O4fH5S7ItEVskiED/rP1GvI7EQNiVePMimy1 6XD9S9B3X1/ItLWOcKKKrH3jzHWgwcfIwLIFNNObv+Rh1d9uHUxgAc0v24onJSSt5194 /2wx0tJfWcUBLbkNdntzHSqMzR70lyogZOz3oSYAJeEMWs2N35Jie4fZHFb/ygoZ+ygf sNRw==
X-Gm-Message-State: AOAM5304zZu4GAyCyLtS6rMHXk6cX8M2VXRZnZO+ZZ50AOm1YXX3QeMg Mh9U3+5mFYsgcjMRgRk4BTzHc57SBgr1LVoQ
X-Google-Smtp-Source: ABdhPJxq5C9TAB0/F6zusWZWFx3C/X/SoUsci+t9GwnR7SXthBcj+afI/01meb+b6UMy6xV41mGDDA==
X-Received: by 2002:a37:a54b:: with SMTP id o72mr25963619qke.261.1620750002592; Tue, 11 May 2021 09:20:02 -0700 (PDT)
Received: from smtpclient.apple ([2607:f2c0:e784:c7:40a9:8726:f5fa:24d0]) by smtp.gmail.com with ESMTPSA id m124sm14393530qkc.70.2021.05.11.09.20.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 May 2021 09:20:01 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <07FE2C2B-10C4-47B0-BFF7-AD8E980A2E26@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_338DC424-EB50-4866-BB2D-65AF002EABF8"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Tue, 11 May 2021 12:19:59 -0400
In-Reply-To: <CAHbrMsCrf8GS3N=HF53X-M0oq09yw_vKGFLU_qA6wt94-+vNXg@mail.gmail.com>
Cc: "libor.peltan" <libor.peltan@nic.cz>, dnsop <dnsop@ietf.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
References: <F4CE48A1-7AB0-45D0-97FF-158CE3A04EE1@icann.org> <3EE971EE-0777-44D6-9CD2-771B92FFE938@hopcount.ca> <1d822219-8ab9-2cb7-d0a4-9b8afc39058d@powerdns.com> <2952D408-117B-40D0-B859-7A8E4111629E@hopcount.ca> <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com> <CAH1iCirykCpqkQEizYUBYMJEXMYRGkWvnzyo-jP=XOT-4fP-EA@mail.gmail.com> <123fd984-a3e1-0d09-b745-9a7ed6260759@nic.cz> <CAHbrMsCrf8GS3N=HF53X-M0oq09yw_vKGFLU_qA6wt94-+vNXg@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sPkJ3GSJGkaIVRxCmwl9Pa3j63U>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 11 May 2021 16:20:09 -0000

Hi Ben,

On 11 May 2021, at 12:08, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:

> OK, I've proposed text documenting the reasoning here: https://github.com/MikeBishop/dns-alt-svc/pull/323/files <https://github.com/MikeBishop/dns-alt-svc/pull/323/files>.

I definitely appreciate the effort, since I think I agree that documenting the design decisions are a good idea. However, I think perhaps the reasoning needs more work (see below).

> The proposed text is:
> 
> Storing a key-value map within a single RR, rather than placing each key-value
> pair in a separate RR, provides the following advantages:
> 
> * It enables a familiar key=value zone file syntax that matches zone authors'
>   experience with command-line arguments and other typical key-value mappings.

Since zone files generally don't include any key value pairs of the kind SVCB currently specifies, I don't understand this point. Surely the unfamiliarity with how to parse this kind of syntax illustrates that this is not familiar?

> * It avoids requiring zone file authors to manage inter-pair binding IDs.

I think you will have to expand that point, since I'm not convinced I understand what you mean.

> * It makes each record independently meaningful, consistent with the usual
>   convention for DNS records (c.f. SRV, MX, AAAA, etc.).

If you think of the DNS itself as a key-value store, with keys of the form (QCLASS, QTYPE, QNAME) then the corresponding value is an RRSet, not an individual resource record. Individual RRs are not returned in responses; RRSets are (understanding that the results are not functionally different in the case of an RRSet with a single member).

Your examples of SRV, MX and AAAA, somewhat ironically, are all prime examples of why the whole RRSet matters and you can't rely on a single RR from a set in a respose.

> * It saves at least 11 bytes of overhead per parameter by avoiding repetition of
>   the name, type, class, TTL, and inter-pair binding ID.

... but it inflates response volume in the case where a separate SvcParams RRSet is able to be cached significantly longer than the SVCB RRSet.

> * It provides a wire format whose structural nesting matches the logical scope
>   of each key=value pair, and avoids requiring cross-RR reconstruction of
>   bindings by the client.

This seems like it is documenting a design choice rather than explaining it. The decision to include a list of key-value pairs in the SVCB RDATA is good because it avoids having to do something different?


Joe