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

Brian Dickson <> Wed, 19 May 2021 22:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D71763A20C1 for <>; Wed, 19 May 2021 15:01:04 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RtfFhnHdAMv8 for <>; Wed, 19 May 2021 15:01:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EC683A20BF for <>; Wed, 19 May 2021 15:00:59 -0700 (PDT)
Received: by with SMTP id x19so21396029lfa.2 for <>; Wed, 19 May 2021 15:00:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/ewNgwLhsQsfBrcDyhqB1opJ2xWXv+Nzu7rtcSBL83o=; b=CTiDpep+cuWASeHoxV1au+ZkxAqy5oOwOKFEucCUWR4J89iQjs9SsP4Dg1zijlz83I 3csZZcGiOKF5r/OCR8TFpQFiKa9Pfk7XB2vdBu2q+on4x9Hn18u8L0fcOddOYnqInppm DEtIZdUFya9bIM983AE/Rd8RWchEMOcQBP656XsaC1jywivDFa3l1UqG0BeNFSurQe15 uwaUGbvoHHL3C9+nD7aZllhUWqLuL8ZC/W70Z0GLLqNmnpgu4TJ3Y+sOLUxzv+TTMbSm 3p1h588qMomhn8MAJBeC3e4z7VI6g6JT3VHx1l/92nI0CuGXqGmlPFRgu/IX5BGKdRvV CGzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/ewNgwLhsQsfBrcDyhqB1opJ2xWXv+Nzu7rtcSBL83o=; b=JnpgAnw47EZPj+co39RgWsd4o/Ok9MX1LTf8wBQUwfDxcbAkeA1uzAteKgsFjcVRQz CrZCn6way4pE268NICA5FV1Ok1LXEK3heEtPBdA5Y1fU3vIHdrVFJMXRlaF/5IpIC3sn VQEDY/L4PVGuiCdED6quUKlEGXn/dJ+DHyDLXiLXrW4PbOGI4XP6gNdtDEWNfFwZRx4G b+0uS7plcr8NbUKar+ZsdxxAq1Die669UpA9y2uKj2E+HTmlrZEvDBMtLp0Eng9rZI60 kzh9DCu6/fDiHVm/DLWYH2hB9jFWYopax7XQ3QJW/5VAjWw1Dy0Zhek7roo/NoLuxRsM /E8g==
X-Gm-Message-State: AOAM533wy8AvAaH0gXw87m9nTAkxUT6z9lMnDghQT8Z5YVeaf7QQQnpp ZhgSIpe5TCgLKOX9iHyGyr+W4JUj3dfiLmg/LfY=
X-Google-Smtp-Source: ABdhPJznODYwIjFCJR/2ZfjpYbLBcJx+kQbCUS8rgmesXVHaMKhEI86mFrivBOFdocA4TM3c+Ojm/hAhGKlgS7iIaTM=
X-Received: by 2002:a05:6512:3f04:: with SMTP id y4mr1131988lfa.458.1621461657552; Wed, 19 May 2021 15:00:57 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 19 May 2021 15:00:45 -0700
Message-ID: <>
To: Paul Hoffman <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="0000000000001d8b4805c2b5f6de"
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: Wed, 19 May 2021 22:01:05 -0000

On Wed, May 19, 2021 at 2:50 PM Paul Hoffman <> wrote:

> Are these still just idle ideas you are tossing out (as you indicated
> earlier), or meant to be serious proposals? If the latter, what is the
> significant improvement over the current draft? I ask because it feels like
> you are suggesting moving the inherent complexity of the semantics of SCVB
> around, but not noticeably reducing it overall. Unless there is a
> significant reduction in complexity, I don't see the value of grinding on
> this further. (I say this as someone who is not happy with the current
> level of complexity of the semantics, but don't see a way to reduce it.)
> --Paul Hoffman

It is meant to be a serious proposal.
The improvement is in the clarity and parse-ability of the HTTPS record in
zone file format, including reducing the complexity of the HTTPS-specific
semantics, without changing the actual wire format semantics or complexity
per se.

I'm working on the details of that, but it will necessarily be its own
work-in-progress. I hope to get something stable based on feedback... I
don't expect to get it 100% right on the first pass.

The first pass should hopefully illustrate the benefits at least, and
justify keeping list activity ongoing.