Hello McTim.
I don't know why the WG is asked to comment on procedure as well as policy, but here goes:
Input on the procedure is more than welcome. Thanks!
What does "reasonable" mean in the below sentence on: http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html
"Is the signature validity period close to expiring and are the Times To Live (TTLs) a reasonable fraction of the signature validity period?"
This refers to draft-ietf-dnsop-dnssec-operational-practices-04 section 4.1.1. o We suggest the Maximum Zone TTL of your zone data to be a fraction of your signature validity period. If the TTL would be of similar order as the signature validity period, then all RRsets fetched during the validity period would be cached until the signature expiration time. Section 7.1 of [2] suggests that "the resolver may use the time remaining before expiration of the signature validity period of a signed RRset as an upper bound for the TTL". As a result query load on authoritative servers would peak at signature expiration time, as this is also the time at which records simultaneously expire from caches. To avoid query load peaks we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period. We currently test on the TTL being at least 2 times smaller than the signature validity period.
I'm confused about this para on same page:
"Web Interface Restrictions We will develop a web interface to make it easy to create domain objects with the appropriate "ds-rdata:" attributes. It will have some operational restrictions
It will use the SEP flag to select the keys for which DSRRs are needed.
It will use the "ds-rdata:" attribute of the domain object currently available in the RIPE Whois Database to select the appropriate default DNSKEY RR. It will then select a new "ds-rdata:" attribute."
How do you use the "currently available object" to create an object if this object doesn't exist until you create it?
That text applies to when a key rollover is being performed. During the initial upload the default is the DNSKEY RR with the SEP flag set.
I am clearly missing smt, but it escapes me at the moment.
I support Jim's suggestion in re: generic replacement of "DLV" mention.
On the issue of the DLV registries: the intention is that in the absence of a signed root we will try to participate in initiatives that allow for 'easy' trust anchor maintenance. Since DLV is the only technique currently under discussion so that got hard-wired into the procedure document. As soon as the root and intermediary zones are signed it is probably best to move away from these alternative key distribution mechanism. At this moment there is no working DLV implementation, nor a DLV registry to participate in. I hope this clarifies. --Olaf Kolkman