Subject: Re: NSEC3, version 13

From: [email-masked] (Ted Lindgreen)
Date: Sat, 1 Dec 2007 08:40:29 +0100

[Quoting Sam Hartman, on Nov 30, 17:34, in "Re: NSEC3, version 1 ..."]

> However, since there are objections, I assume the chairs will also
> call for support;silence in the presence of objections is not rough
> consensus.

I share Sam's concern, I also think that silence does not suffice
to go forward.

NSEC3 is a very complicated protocol extention. Few people, even
in this WG, really understand the issues at hand, those who do,
should speak up and guarantee the rest of us that all issues are
now solved,

Regards,
-- ted

--
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: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Wed, 05 Dec 2007 12:44:30 -0500

>I share Sam's concern, I also think that silence does not suffice

We have IMHO a consensus on the document, what I need to know from
the working group member is if this change does affect their understanding
and expectations of the protocol.
This is a form of consensus call and should be just fine as the
explicit way to judge the consensuses is expressed.

>should speak up and guarantee the rest of us that all issues are

This is not a fair request without you saying what you mean by
"guarantee the rest of us that all issues are now solved".
Is this a guarantee that the expert has to pay penalty if she/he is wrong?
Did you mean to say "assert that he/she knows of NO issues with the 
current specification".

         Olafur

---

From: [email-masked]
Date: Wed, 5 Dec 2007 17:47:12 -0800

> should speak up and guarantee the rest of us that all issues are

I am confident all issues are now solved. Nothing has changed in the 
normative text part of the draft for a while now (not counting the 
occasional typo).

The text that changed was section 12.1.3, which had a 4 step gradual 
transition process for zone administrators to gradually introduce NSEC3 
records with a new hash algorithm. 

Without a gradual introduction of NSEC3 records, an administrator needs to 
change the hash algorithm and the signature algorithm in a single SOA 
serial version increase (i.e. an instant transition for lack of better 
terminology). That might be a bit problematic for highly volatile or very 
large zones though I do not expect that this transition would happen 
frequently.

It is possible to have a gradual transition process, other than the one we 
came up with. That one had a requirement that older hash algorithms needed 
to be supported. That requirement was, as we were told, not okay.

Since there is no hash algorithm to transition to at this point, and does 
not require a change to normative text (i.e. NSEC3 capable implementations 
do not have to be changed) we accepted Sam Weiler's alternative text to 
require a gradual transition scheme to be defined when a new NSEC3 hash 
algorithm is defined. 

I hope this helps.

Regards,

Roy Arends