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

Olafur Gudmundsson <ogud@ogud.com> Sat, 10 July 2010 15:13 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 732733A67E7; Sat, 10 Jul 2010 08:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level:
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 GAjW77O71pP4; Sat, 10 Jul 2010 08:13:54 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74AB23A6407; Sat, 10 Jul 2010 08:13:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OXbcO-000C27-Ng for namedroppers-data0@psg.com; Sat, 10 Jul 2010 15:05:28 +0000
Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <ogud@ogud.com>) id 1OXbcL-000C1U-7R for namedroppers@ops.ietf.org; Sat, 10 Jul 2010 15:05:25 +0000
Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o6AF5LCV013843; Sat, 10 Jul 2010 11:05:21 -0400 (EDT) (envelope-from ogud@ogud.com)
Message-ID: <4C388C2F.4030608@ogud.com>
Date: Sat, 10 Jul 2010 11:05:19 -0400
From: Olafur Gudmundsson <ogud@ogud.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: bmanning@vacation.karoshi.com
CC: namedroppers@ops.ietf.org
Subject: Re: [dnsext] Design team report on dnssec-bis-updates and CD bit
References: <20100709142108.GA68527@shinkuro.com> <20100709220459.GB22072@vacation.karoshi.com.>
In-Reply-To: <20100709220459.GB22072@vacation.karoshi.com.>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
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 09/07/2010 6:04 PM, bmanning@vacation.karoshi.com wrote:
> 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.

This is orthogonal, design team can be of any size, the output of an
design team can be one of:
	a proposal of way forward
	a list of options
	a comment on a particular design.
	a statement of failure to reach conclusion

In this case we documented number of options and it is up to the working 
group to discuss which one of the options to prefer or to say
that some/all will work together.

The problem we have had in the past was that there was no concise crisp
description of polices,  MSJ as he came closest with his flow graph,
and his graph inspired the table format.
We are not making any claims that this is the complete space of policies 
and if there are other polices we hope that people put them forward in 
the same format.


>
> 	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, Please, Please.
The design team  (hopefully) worked on creating a framework for more 
productive discussion.

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


This is an excellent question,
If I rephrase it:
Will it hurt interoperability if different validators implement 
different models ?
Sub-question: will it hurt deployment if different models are in use ?

	Olafur