[DNSOP] On some terminology in draft-ietf-dnsop-respsize (truncation)

Stephane Bortzmeyer <bortzmeyer@nic.fr> Mon, 03 March 2014 10:53 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178CE1A0DF0 for <dnsop@ietfa.amsl.com>; Mon, 3 Mar 2014 02:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 xDSa_uZ9apod for <dnsop@ietfa.amsl.com>; Mon, 3 Mar 2014 02:53:26 -0800 (PST)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) by ietfa.amsl.com (Postfix) with ESMTP id E2D611A0E33 for <dnsop@ietf.org>; Mon, 3 Mar 2014 02:53:24 -0800 (PST)
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 30E4E3B989; Mon, 3 Mar 2014 10:53:19 +0000 (UTC)
Received: by tyrion (Postfix, from userid 1000) id D6039F00A5E; Mon, 3 Mar 2014 11:51:38 +0100 (CET)
Date: Mon, 3 Mar 2014 10:51:38 +0000
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: dnsop@ietf.org
Message-ID: <20140303105138.GA3875@laperouse.bortzmeyer.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Transport: UUCP rules
X-Operating-System: Ubuntu 13.10 (saucy)
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/Tgg4nal8sxYfoRVXYOdIW6pAME0
Subject: [DNSOP] On some terminology in draft-ietf-dnsop-respsize (truncation)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 03 Mar 2014 10:53:28 -0000

draft-ietf-dnsop-respsize-15.txt says:

> Note that truncation of the additional data section might not be
> signaled via the TC bit since additional data is often optional

Using the word "truncation" here is dangerous. By definition, there is
truncation only when the TC bit is set. "Optimizing" the answer by
dropping non-necessary RRsets is *not* truncation. To quote RFC 2181,
"The TC bit should not be set merely because some extra information
could have been included, but there was insufficient room."

> will automatically requery for RRSets that are possibly truncated

I don't think that a RRset can be "possibly truncated". Either it is
truncated (not sent in its entirety) and the TC bit is set, the
resolver does not have to guess, or it is not truncated. There is
never an ambiguity. (Unless you use "truncation" in the sloppy sense I
criticized above.)

Editorial :

> RRSets are are never sent partially

One are too many :-)