Re: [dnsext] Design team report on dnssec-bis-updates and CD bit

bmanning@vacation.karoshi.com Fri, 09 July 2010 22:10 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAFE83A68DC; Fri, 9 Jul 2010 15:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N67ii8XQL2qG; Fri, 9 Jul 2010 15:10:16 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFAC63A68C0; Fri, 9 Jul 2010 15:10:15 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OXLiF-0004vI-08 for namedroppers-data0@psg.com; Fri, 09 Jul 2010 22:06:27 +0000
Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <bmanning@karoshi.com>) id 1OXLi9-0004PL-7S for namedroppers@ops.ietf.org; Fri, 09 Jul 2010 22:06:24 +0000
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o69M4xV7022161; Fri, 9 Jul 2010 22:04:59 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o69M4xrA022160; Fri, 9 Jul 2010 22:04:59 GMT
Date: Fri, 09 Jul 2010 22:04:59 +0000
From: bmanning@vacation.karoshi.com
To: Andrew Sullivan <ajs@shinkuro.com>
Cc: namedroppers@ops.ietf.org
Subject: Re: [dnsext] Design team report on dnssec-bis-updates and CD bit
Message-ID: <20100709220459.GB22072@vacation.karoshi.com.>
References: <20100709142108.GA68527@shinkuro.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20100709142108.GA68527@shinkuro.com>
User-Agent: Mutt/1.4.1i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

On Fri, Jul 09, 2010 at 10:21:08AM -0400, Andrew Sullivan wrote:
> Dear colleagues,
> 
> On 2010-07-06, there was a design team meeting in Bethesda, MD, to
> address the issue of setting the CD bit in the dnssec-bis-updates
> draft.  David Blacka, Olafur Gudmundsson, Mike StJohns, and Andrew
> Sullivan attended.  
> 
> In the meeting, we concluded by describing three different models for
> how the CD bit is to be treated and used by a validating resolver
> (i.e. one that has at least one trust anchor), and what interaction
> this has with a local cache.  We based these models on RFC 4035, on
> the discussion we saw on the list on this topic, and on what we think
> people have implemented.  We want one, and only one, of these models
> to be described in the draft as the standard model.  These models are
> outlined below.


	so the We in the para above is the design team of 
	yourself, David, Olafur, and Mike.  This does not meet 
	the WG criteria of "five" reviewers.

	Perhaps the WG would like to weigh in on the recommendation
	that the design team came up with, ie that only one of the
	models be described as the "standard" model.

> Please offer your thoughts on these models and state which of them you
> think should be in the draft as the way to handle the CD bit.  We will
> devote some time in the Monday Maastricht session to this issue.  We
> want to bring it to a close at that meeting.


	I guess the questions I have, before proceeding down the selection
	process is, Are there good reasons to use different models? (I can think
	of reasons to use other interpretations, fwiw).  Is there
	a compelling reason to select only one model?  If one is standard,
	are the others still optional or will they be forbidden?  If they
	are to be forbidden, can we document why?

--bill


> 
> Best regards,
> 
> Andrew (as design team stenographer)
> 
> -- 
> Andrew Sullivan
> ajs@shinkuro.com
> Shinkuro, Inc.