Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt

On Mar 11, 2012, at 6:02 AM, Miek Gieben wrote:

> [ Quoting <internet-drafts@ietf.org> at 08:29 on Mar  6 in "[dnsext] I-D Action:..." ]
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt
> 
> I've read the draft and I support it. Below are a few things I found.
> (And I still have this question:
> http://www.ietf.org/mail-archive/web/dnsext/current/msg12286.html)
> 
> | These signaling options can be
> | used by zone administrators as a gauge to measure the successful
> | deployment of code that implements a newly deployed digital signature
> | and hash algorithm, DS hash and NSEC3 hash algorithm used with
> | DNSSEC.                      
> 
> This sentence has some funny wording.
> 
> | A validating stub resolver already (usually) sets the DO bit
> 
> already (usually), either already of usually?
> 

Yes, both are poorly written.  I'll re-write in next version.  The second should be: "A validating stub resolver already sets the DO bit..."

> | 5. Server Considerations     
> 
> What if the server can not comply to the clients wishes? Does
> it need to send back an empty DUA edns0?
> 
> | The goal of this option is these options are to signal new algorithm
> | uptake in client code to allow zone administrators to know when it is
> | possible to complete an algorithm rollover in a DNSSEC signed zone.
> 
> It this the goal? Because with this option we can also facilitate
> hash rollovers in nsec3.
> 

Correct - that was left out and should be re-added.

Thanks,
Scott

> Regards,
> 
> -- 
>    Miek Gieben
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext