Re: Opt-in wg last call

Paul Vixie <vixie@vix.com> Tue, 02 April 2002 08:12 UTC

Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09509 for <dnsext-archive@lists.ietf.org>; Tue, 2 Apr 2002 03:12:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sJEk-0003BG-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 00:01:50 -0800
Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16sJEj-0003BA-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 00:01:49 -0800
Received: by as.vix.com (Postfix, from userid 716) id D079D28DC4; Tue, 2 Apr 2002 00:01:48 -0800 (PST)
To: namedroppers@ops.ietf.org
Subject: Re: Opt-in wg last call
References: <20020401012215.M7955-100000@padda.telia.net>
From: Paul Vixie <vixie@vix.com>
Date: Tue, 02 Apr 2002 00:01:48 -0800
In-Reply-To: <20020401012215.M7955-100000@padda.telia.net>
Message-ID: <g3hemufs0j.fsf@as.vix.com>
Lines: 25
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Mats Dufberg <dufberg@telia.net> writes:

> The only arguments in favor of limited opt-in I have seen have been on
> some kind of moral ground. Are there any technical arguments that I cannot
> see in favor of limiting opt-in?

I have seen no such technical arguments.

> When administrating DNS you are focused on the zone as a unit. DNSsec has
> also focused on that unit. But queries are not based on zone, and they can
> happily skip zones when parent and child resides on the same server, or
> some server happens to do resolving. Queries are based on names and its
> data, and opt-in refocus on names as being secured or not.

Agreed.  (And: "well put.")

> ... until I see good technical grounds for limiting opt-in, I propose
> full opt-in.

Echoed.

The document can recommend an operational practice of only opting in/out
one's delegations.  But implementations (of either server or client) should
not be required to enforce this practice, since at the wire level, it is
arbitrary, and only adds complexity without removing any carrying cost.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>