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

[[e-mail]]

On Sat, Jul 10, 2010 at 11:05:19AM -0400, Olafur Gudmundsson wrote:
> On 09/07/2010 6:04 PM, [e-mail] 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

	hum... this kind of makes the IETF WG process subject to capture,
	don't you think?  According to you, a design team of one can make
	a statement about failure to reach conclusion...  Thats a pretty 
	low bar.

	that being said, this work was the result of just four people.
	

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

	except Andrew, as spokesperson for the design team cast a 
	bias - not just the presentation of options with a request
	to the WG to come to consensus.  To compound influence, there
	was an inferance that the WG chairs would close this topic
	by the next IETF... just 14 days.  Is there a reason for the
	short suspense on this item and not with the other items on
	the WG agenda?

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

	Yup.. I really liked the flow graph.

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

	'Cept the intent to  close discussion in 14 days... :)

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


	Well, for what its worth, I can see use cases for at least two
	of the options that the DT produced.  I would be sad if in its
	haste, the WG allowed a single option to be "fast-tracked" through.
	

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


	Unfortunately, I will not be at the meeting on Monday - I'll be 
	in transit.  So good luck and I hope the DT picked correctly.

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