Subject: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future?

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Fri, 11 Jun 2004 15:36:59 -0400

After reading Paul's Vixie -ter proposal
http://psg.com/lists/namedroppers/namedroppers.2004/msg00967.html
and  Jakob, Peter and Roy's -trans list of approaches
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt

Please speak up on this question to help chairs gauge consensus.

thanks	
	Olafur & Olaf. 

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Jun 2004 23:58:22 +0200

> Please speak up on this question to help chairs gauge consensus.

Advancing DNSSECbis to IESG does not prevent _anything_ in the future,
as specifying a backwards incompatible DNSSECter with NSEC-alt will be
possible.

Whether advancing the current documents to IESG will allow smooth
transition to a NSEC-alt solution is a different question, and to it I
would answer no.

The recommendation in dnssec-trans does not meet initial expected
DNSSEC design criteria -- online key, secure channel between master
and slave, per-query private key operations, etc.  People looking into
transitioning might find it cheaper to provide bogus NSEC responses
and specify their own solution, instead of adopting the
recommendation.  E.g., NSEC2.

Thanks,
Simon

---

From: [email-masked]
Date: Sat, 12 Jun 2004 03:41:58 +0000

> Please speak up on this question to help chairs gauge consensus.

	presuming "radio-silence" - this is short.

A: No.

--bill

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Mon, 14 Jun 2004 14:53:30 +0200

> Please speak up on this question to help chairs gauge consensus.

dnssec-trans recommends "dynamic NSEC synthesis" as a temporary solution 
to the walking problem. If I've gotten it right, some people have recently 
outspoken their preference for the "NSEC white lies" approach.

However either way (cf sections 2.1.1.5 and 2.1.5.3 of dnsec-trans) 
requires (slight) updates to DNSSECbis. Thus my question back to the 
chairs:

Does advancing DNSSECbis to IESG prevent incorporating these updates in 
the final form of DNSSECbis?

I just wouldn't like to be in the position of having to deploy a temporary 
solution which isn't conform to IETF specifications.

Regards,
Marcos