I agree that we need to give more thought to how sig expirations interact with the several SOA timing parameters. A short zone refresh time isn't a problem per se when the network is healthy, since resetting the zone expiration timer is a two-packet exchange under ideal conditions when the zone hasn't changed. So the tradeoff is between data availability and verifiability (is that a word? probably shouldn't be...) when the refresh cycle isn't completing, and the zone's expected churn rate may also be a factor.
Since the resolver's decision about what to do when sig validation fails is ultimately a "local policy" issue, one can make a case either way on how the zone should be configured to make the end users least unhappy, depending on what one thinks the local policy might be. Or perhaps I just need more coffee, or beer -- it is getting towards the end of an IETF week.... #---------------------------------------------------------------------- # To unsubscribe, send a message to <[EMAIL PROTECTED]>.
