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

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

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

 Regards,

-- 
    Miek Gieben

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

Attachment: signature.asc