Robert Wilton has entered the following ballot position for draft-ietf-dnsop-nsec-ttl-04: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document. Regarding: 3.4. Updates to RFC8198 [RFC8198] section 5.4 (Consideration on TTL) is completely replaced by the following text: | The TTL value of negative information is especially important, | because newly added domain names cannot be used while the negative | information is effective. | | Section 5 of [RFC2308] suggests a maximum default negative cache | TTL value of 3 hours (10800). It is RECOMMENDED that validating | resolvers limit the maximum effective TTL value of negative | responses (NSEC/NSEC3 RRs) to this same value. | | A resolver that supports aggressive use of NSEC and NSEC3 MAY | limit the TTL of NSEC and NSEC3 records to the lesser of the | SOA.MINIMUM field and the TTL of the SOA in a response, if | present. It MAY also use a previously cached SOA for a zone to | find these values. I'm not a DNS expert, and this is just a non binding comment, but I was wondering why it is only "MAY" limit the TTL on NSEC and NSEC3 records to the lesser of the SOA.MINIMUM field and the TTL of the SOA in a response rather than a "SHOULD". Regards, Rob _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
