Re: [DNSOP] Consensus suggestion for EDE and the TC bit

Puneet Sood <> Tue, 03 December 2019 04:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A014D120116 for <>; Mon, 2 Dec 2019 20:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 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, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 2_soGNcw2GYL for <>; Mon, 2 Dec 2019 20:12:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AB42120113 for <>; Mon, 2 Dec 2019 20:12:47 -0800 (PST)
Received: by with SMTP id n27so1506267vsa.0 for <>; Mon, 02 Dec 2019 20:12:47 -0800 (PST)
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:content-transfer-encoding; bh=dPT2gFVZJfkVO5MwK/FVcHmba7VGjHNwAYE7k3qSfqY=; b=E3l9jrS89xMWxthXcvKlzMpjCGo6Nen4+8ZqrDNyYA2ZFS5ywUIWc2zba+oBoBl7sH FSvws0BQKwxhc2eF2ef9p7qz4QyAfPZcuOTo9MLBSFQSvWM/LNQkYuV0UxTV9pMkY8It GDE3pTEzM0uA1Nf0Hf68FnS8N6e/Qzi5wcwAQ8apg8ZThcehMkSh9j19FdmsWZ/S8+ee WXKvaA94maOGnGCm+gaXSlC5L30GEMefB45us8mTVCu30PCS3MYDZF9OQqb+XCP1C4NN /sBoHfr3AvDga3bOD5m6lZXcf/MhdPHsodsiav+tEjgIr54n6On4JgI4L2hvevGSbwwl LMjQ==
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:content-transfer-encoding; bh=dPT2gFVZJfkVO5MwK/FVcHmba7VGjHNwAYE7k3qSfqY=; b=gdNVFUVa2N8mbRSYQ0tyO249mfm8u/COJ03GxhUIMpQDZ3fL+AM3zP7egMgInRD4kp gFkmuelSQSQMdWrlx1Pflil4tdrdlML12Ty0J+U5FX3Nqo5kXdHFW8PmeDW5mvbvV5se P/iy+k8bjWqkSD1GYeK0Nxt1t4TUc9odm0zt/GnK8U4lZCUrmAKBgwECbK0c090VeOPQ 7gAi1qJPxZarO60NdGEu7AfqGOGqzQMNymqgtf/yCcYRBgRdy5wSe1ZijByl5WfB0+Mq 7wsyRMvHv2cOGuXKQJm4n4p4Bbqc3qp7BYiLgfJ06ZP4foxCZNSY0rc3Wi0uYJphDXBV Sz/A==
X-Gm-Message-State: APjAAAUeqgvviQ5DXNR0qBvhISZcBmPL6jIifYPIDisGanVmQ/r1PGNv Uu10IKwnljcCCVS7cNg1tjMn/t88FftFh56Q9c34SQ==
X-Google-Smtp-Source: APXvYqz6VDBrFZsSXyvJ22J9dIO+tFZIgeVTRhw/b3bDf7GF/Gux7+bqE6mcJul5CWqEBaUTlDuhoHeANkNQZQx88Qo=
X-Received: by 2002:a67:be13:: with SMTP id x19mr1543827vsq.20.1575346365758; Mon, 02 Dec 2019 20:12:45 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Mon, 2 Dec 2019 23:12:34 -0500
Message-ID: <>
To: Eric Orth <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
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, 03 Dec 2019 04:12:49 -0000

My preference is also to not add the DP bit as part of the EDE
feature. We should gain more experience with EDE before adding any new
bits to the protocol.

On Mon, Dec 2, 2019 at 1:55 PM Eric Orth
<>; wrote:
> I still have a soft preference (but am definitely not going to call it a hard blocker) for some way to avoid followup queries when the only thing causing truncation is EDE.
> My concern comes from the EXTRA-TEXT being an open-length field, and I imagine many operators would want to create long verbose error messages.  Seems that could lead to many cases where EDE causes common excessive truncation.
> Maybe an alternate easy solution would be to add a don't-do-that note to section 3.4 along the lines of "Long EXTRA-TEXT fields may cause truncation and bad resolve performance, which is usually undesirable for the supplemental nature of EDE. Operators setting the field SHOULD avoid setting unnecessarily long contents, especially when it can be determined that doing so will cause truncation." With something like that, I think my concerns are enough resolved that I wouldn't worry about DP unless future experience shows EDE truncation to be a significant problem.

I would support text like the above in section 3.4 to remind operators
not to put very long text in the EXTRA-TEXT field.

> But otherwise, if people don't like my suggested note, because I only have a soft preference to do something, I agree that moving TC/DP to a separate doc is a good idea.  If EDE is otherwise consensus-ready, let's get it published.
> On Thu, Nov 21, 2019 at 12:04 PM Ray Bellis <>; wrote:
>> On 21/11/2019 15:37, Ben Schwartz wrote:
>> > I would suggest adding a requirement to the EDE draft that EDE be
>> > the last option in OPT
>> And what if some other future option wants to lay claim to that requirement?
>  I agree that this would be a difficult requirement to set.  Only one thing can be last, and I would argue that EDE is not important enough to claim that distinction and take away the flexibility from future specs.
> _______________________________________________
> DNSOP mailing list