Re: [DNSOP] Consensus suggestion for EDE and the TC bit
Michael StJohns <msj@nthpermutation.com> Mon, 02 December 2019 19:16 UTC
Return-Path: <msj@nthpermutation.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 D147512003E for <dnsop@ietfa.amsl.com>; Mon, 2 Dec 2019 11:16:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 hJmszelSinCs for <dnsop@ietfa.amsl.com>; Mon, 2 Dec 2019 11:16:01 -0800 (PST)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 93B0B120018 for <dnsop@ietf.org>; Mon, 2 Dec 2019 11:16:01 -0800 (PST)
Received: by mail-qk1-x735.google.com with SMTP id g15so677601qka.8 for <dnsop@ietf.org>; Mon, 02 Dec 2019 11:16:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Lpo4WXEr3rYU9tIvebepNWsRi1+jkfK5crJz9I0GfdQ=; b=qAnS0XUn4rEroMvMDGizZuds1OrbwKADIJ5FWvtgbYZ8Z7RS2HNivs9/Hx8Ml+bkDU SSvc4d6iQPkOKadUglKUHUIeb+b/D8tSMFsSfgE08K0W9RBiweC5YsVjvy31AXCJpDl+ QCmDTCpTMh/uuOQzwnyrySM4Y+X1bm8kL64LYsDBqdAFIn3lO894U4O9wtHt1Ml9ZDby S5M1UFdsm+/meFyfvafuQJ9hFMvGLsyj+GK0MmQnmEIV8hX0uvLvswAGugLKIJ415RQ+ loAax0k0oe2nTmXW2V0uTUkkBRPgyUWmxfHP7YJi7QqZSbrHogbbSrTYKx1D8og4PTBB yi/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Lpo4WXEr3rYU9tIvebepNWsRi1+jkfK5crJz9I0GfdQ=; b=SjSJdbr4sFYTXmdj3Bd+vYbbfkYE8ung0Qktt7lxoocKjlMPSIE2u4+peR/o54APCQ ZLw5O4LkBnUmTMFriGIhVrK7i8HL3vDtT8boEmOsHd+ShUPGRXQ6jd/8TgQfPKQpT6/H V0S/36nlbOC0byD8jjTlqKXywDh6yp19FN1N0EiuKNfFfGY96MlNxIHW8zfZNTfcotGc ZXJ067TJrwuPIwfDQ+Wby0qXw12JmCOC3yOgzKnZwprUnRlXkYdWklzJQhL1OsBQXOT4 x1tViyqOkO7C4XvIH3SpYrppBtdz/EX6bWzlkXhK+rwrVkTqQps0dB4BHOBtyXChxP35 WUnA==
X-Gm-Message-State: APjAAAX2ySQ+K1nNirYggWCZOPJwaZdi6ISBg4cgbRCzwOowfz6c4fw3 irP9X/fbMW8PCzyNjz87XU0c56u/0Ek=
X-Google-Smtp-Source: APXvYqywRKPGXU5CwvUGTX3wgNaE5tutOQPGP5xkaxB6UKCVBEgQ22bQhEoqbHfSjiDriSAlXTbv/A==
X-Received: by 2002:a37:a806:: with SMTP id r6mr467161qke.400.1575314160413; Mon, 02 Dec 2019 11:16:00 -0800 (PST)
Received: from ?IPv6:2601:152:4400:437c:dd33:bee2:1b7f:de46? ([2601:152:4400:437c:dd33:bee2:1b7f:de46]) by smtp.gmail.com with ESMTPSA id 198sm272621qkn.70.2019.12.02.11.15.59 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 11:15:59 -0800 (PST)
To: dnsop@ietf.org
References: <yblzhgpwwit.fsf@wu.hardakers.net>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <07cdee93-eb69-9a67-65d8-ea85e82a8761@nthpermutation.com>
Date: Mon, 02 Dec 2019 14:15:58 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <yblzhgpwwit.fsf@wu.hardakers.net>
Content-Type: multipart/alternative; boundary="------------6ABCA2BF19529CF5F7467A71"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4umo3o5jACCERIhsIs65ykJN2RY>
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
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: Mon, 02 Dec 2019 19:16:04 -0000
On 11/21/2019 1:53 AM, Wes Hardaker wrote: > During the first DNSOP meeting at IETF 106 there was a discussion that > had multiple opinions about what to do with setting the TC bit for EDE > information, which is generally supplemental. During my presentation I > mentioned that an associate of Viktor suggested creating a new bit, and > during the conversation there was discrepancy about whether or not that > was a good idea. Brian Dickson then proposed that the new bit only > modify future clients that wanted to use it, thus leaving the EDE spec > setting the TC bit. A future bit could be defined that would indicate > that only supplemental information was dropped. > > My proposal for EDE is that we follow this train of thought, which seems > to be the widest idea accepted from what I could tell. TLDR for things > to do: > > 1. We have the EDE document say to set the TC bit (which it already did) > 2. We create a new document that defines an extra bit for indicating > that the dropped information was supplemental and didn't contain > operationally important information. > > If this sounds like a good compromise, great! If you would like to > propose an alternative, great! do so! From 2181: > The TC bit should be set in responses only when an RRSet is required > as a part of the response, but could not be included in its entirety. > The TC bit should not be set merely because some extra information > could have been included, but there was insufficient room. I finally got a chance to go back and do some reading and found the above. The way I read this is that setting the bit simply because you couldn't include diagnostic info is a no-no. Let's not do it. I read "required" not as "the querier (person) requires it" but as "the protocol requires it". So - 3rd (4th?) option. Include a bit in querier EDNS(0) that says "set the TC bit if I dropped EDE" and maybe "return the EDE info that was dropped instead of or in preference to the query response data". Later, Mike > > In the mean time, I threw together a quick ID for the new bit as well: > > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-drop/ >
- [DNSOP] Consensus suggestion for EDE and the TC b… Wes Hardaker
- Re: [DNSOP] Consensus suggestion for EDE and the … Ben Schwartz
- Re: [DNSOP] Consensus suggestion for EDE and the … Viktor Dukhovni
- Re: [DNSOP] Consensus suggestion for EDE and the … Wes Hardaker
- Re: [DNSOP] Consensus suggestion for EDE and the … Wes Hardaker
- Re: [DNSOP] Consensus suggestion for EDE and the … Petr Špaček
- Re: [DNSOP] Consensus suggestion for EDE and the … Bob Harold
- Re: [DNSOP] Consensus suggestion for EDE and the … Ray Bellis
- Re: [DNSOP] Consensus suggestion for EDE and the … Wes Hardaker
- Re: [DNSOP] Consensus suggestion for EDE and the … Peter van Dijk
- Re: [DNSOP] Consensus suggestion for EDE and the … Ben Schwartz
- Re: [DNSOP] Consensus suggestion for EDE and the … Eric Orth
- Re: [DNSOP] Consensus suggestion for EDE and the … Michael StJohns
- Re: [DNSOP] Consensus suggestion for EDE and the … Puneet Sood
- Re: [DNSOP] Consensus suggestion for EDE and the … Vittorio Bertola
- Re: [DNSOP] Consensus suggestion for EDE and the … Ralf Weber
- Re: [DNSOP] Consensus suggestion for EDE and the … Paul Vixie
- Re: [DNSOP] Consensus suggestion for EDE and the … Michael StJohns
- Re: [DNSOP] Consensus suggestion for EDE and the … Wes Hardaker