Re: [dnsext] Issues in WGLC of dnssec-bis-updates

Wes Hardaker <wjhns1@hardakers.net> Fri, 09 March 2012 03:57 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A6A21E803D; Thu, 8 Mar 2012 19:57:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331265427; bh=VH1pgqYugHyA5HxMg94Y9ZUsG2fyN6eZxH/NDPlOuY4=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=doivx3qgSfbAiBg6oAYQ85cvOSeuBZOeD8KNSEYRbDbGGT2U1ZdFHnztSrBqqpOIA r4x2pcpA2k/fbhOTyEg7eLfYiXK1UAJfTc4olTos7hTzQCWiZ5vy4GgenZPe8g2JL8 6wFQUyboTWA3azM03hlRY8aX/cdxnd3RzyJPIBAM=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5821E8043 for <dnsext@ietfa.amsl.com>; Thu, 8 Mar 2012 19:57:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkSLznGpuqFf for <dnsext@ietfa.amsl.com>; Thu, 8 Mar 2012 19:57:06 -0800 (PST)
Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E1521E801C for <dnsext@ietf.org>; Thu, 8 Mar 2012 19:57:05 -0800 (PST)
Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 857DC1DA; Thu, 8 Mar 2012 19:57:04 -0800 (PST)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <20120207151820.GE9478@crankycanuck.ca> <alpine.BSF.2.00.1203081827340.31973@fledge.watson.org> <E044D96B-7642-433F-A8A6-EB123D3DC1DD@vpnc.org>
Date: Thu, 08 Mar 2012 19:57:01 -0800
In-Reply-To: <E044D96B-7642-433F-A8A6-EB123D3DC1DD@vpnc.org> (Paul Hoffman's message of "Thu, 8 Mar 2012 16:25:30 -0800")
Message-ID: <0lipieh1f6.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Cc: Samuel Weiler <weiler@watson.org>, dnsext@ietf.org
Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

>>>>> On Thu, 8 Mar 2012 16:25:30 -0800, Paul Hoffman <paul.hoffman@vpnc.org> said:

PH> When not presented with the situation that more than one trust
PH> anchor is configured, DNSSEC validators SHOULD NOT expose policy
PH> choices such as those shown in these subsections in configuration
PH> options. That is, these policy choices SHOULD only be exposed
PH> when there are multiple options.

The problem with the wording is that you're really trying to say
something that dictates software implementation practices.  And this is
nearly impossible to get right because most software stacks really can't
do what you want.  Specifically, if a software stack accepts a
configuration file as an input for policy knobs there is no way you
"SHOULD NOT expose" knobs based on the number of trust anchors defined
somewhere else in the file.

Wouldn't it be better to state your actual intentions?

  It is recommended (RECOMMENDED?) that the policy options in the
  following subsections only be configured when multiple trust anchors
  are also configured.

If someone is writing a GUI configuration set (ha ha, like those exist),
then they can actually hide things.  Otherwise it's up to the operator
to not use the knobs in the section when writing a config file.

-- 
Wes Hardaker
SPARTA, Inc.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext