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/
>