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

Joe Abley <> Tue, 11 May 2021 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 936323A1FB8 for <>; Tue, 11 May 2021 10:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UR4XR2xEqsJl for <>; Tue, 11 May 2021 10:32:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D50303A1FC0 for <>; Tue, 11 May 2021 10:32:57 -0700 (PDT)
Received: by with SMTP id q10so15387599qkc.5 for <>; Tue, 11 May 2021 10:32:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kaG05sGyV1ObbIfULcqTqDHLMlXC6jl+f4rAcx1Dzvo=; b=fjiQ5xLZkrPXTOtFEFwfaAf6krJM7ye4pVZj5c6e1kQ+qpPdnVc9pnVWRLCbKO0xLt zqor0mmqia62ND7z9Y92qU2eq/WGIhSP1+Fl1RZ0sYDQWXrQ2y+XbESWgbQsjs+5TxrU UKrDg/su8b+thNbjefZgczU/XJjHozn9+cR3c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kaG05sGyV1ObbIfULcqTqDHLMlXC6jl+f4rAcx1Dzvo=; b=acrbM6YpHJelSzjsd69vPttxCdobRG5BrTq6d8JPn5KQJK0b1SrS8V5onEJDkA5epk KKmLOnk1JXTfIpESNL0TcX9e6OMwXd6eFHoS87vr3tjte+7OTzfKYT2lz2VnBDd8m3ji nn+ohYrNyH5xeR49eC2P6HWs+e5gEWNon8eP2eWEnkT0TgzWARcHT1UzIXteJ7FegCqA tfdBRy2Q60VkZHfLMbrli8AmSJ1N4Fx0hjt08e0/VP99Yl+F3dXhsZpXQu2DaBMr30o+ hIvvvt4NwlIpZtlX37KCZmAcL1TkogSWp5TSkv5qLu31nx9LCtBTVVtOhkAqIE20XBNC e0Ag==
X-Gm-Message-State: AOAM530UXhv5Q5jVVcz3nsUOhgUSBIbMwk+BPGr13jJ1PhD//2vwtdFY YDO+T5zWrHYGri4jpCxgKpwzGg==
X-Google-Smtp-Source: ABdhPJxtVo8IsNUGrAZcROeJ70tE0XNfCpO5ZGotm1fRbHG+o3CjcpkuG6xB79lfnmmQmHf0Jq/5WA==
X-Received: by 2002:a05:620a:103b:: with SMTP id a27mr28834691qkk.228.1620754375867; Tue, 11 May 2021 10:32:55 -0700 (PDT)
Received: from ([2607:f2c0:e784:c7:79d1:ee37:3918:f771]) by with ESMTPSA id k124sm13171768qke.73.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 May 2021 10:32:54 -0700 (PDT)
From: Joe Abley <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_C8C7C3C8-41D5-48DB-A054-BFB0241ECAEE"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Tue, 11 May 2021 13:32:52 -0400
In-Reply-To: <>
Cc: "libor.peltan" <>, dnsop <>
To: Ben Schwartz <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 May 2021 17:33:03 -0000

On 11 May 2021, at 12:32, Ben Schwartz <> wrote:

> On Tue, May 11, 2021 at 9:20 AM Joe Abley <> wrote:
>> On 11 May 2021, at 12:08, Ben Schwartz <> wrote:
>> ..
>>> * 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 sounds like you're proposing a design in which the information in one SVCB record is not just spread across multiple records in an RRSet, but actually across multiple RRSets.

Yes, that's what I tried to sketch out before. The SvcParams in an SVCB RR becomes a pointer to a second RRSet with a different RRType. So the SvcParams information is spread across multiple records in a a different RRSet from the SVCB RRRSet. If it's still not clear what I mean, I can try again.

Note that I'm not proposing a change to the spec, just illustrating that different design choices were possible that avoid the need for delimiters or escaping.

While we're on the topic of RRSets and multiple RRTypes, the way that AliasMode and ServiceMode are distinguished is also a bit clunky; what are the implications of needing to remove all ServiceMode RRs in an RRSet in the event that one of them is found to be in AliasMode if we imagine that some consumers of these responses will get it wrong? Was there any thought given to an RR schema that prevented such ambiguities from being published?

>  That is not just a variation on SVCB, but an entirely different proposal.

I'm not sure how you think of those two things as different. Isn't every variation of something a new something?

>>> * 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?
> To restate this sentence, it is good because the concrete syntactical structure matches the abstract conceptual structure, and (relatedly) because it simplifies client implementation.

What are the concrete syntactical structure and the abstract conceptual structures? If those are terms of art I apologise; I'm not familiar with them.

What are you comparing the client implementation to in your final comment? What other design option was found to be more complex to implement on the client side?

I'm sure it feels frustrating to get all these questions at the last minute, and I apologise (as I think I said before) that I did not follow this work more closely, earlier.