Benoit Claise has entered the following ballot position for draft-ietf-dnsop-dnssec-roadblock-avoidance-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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Here is Eric Vyncke's (pretty knowledgeable security expert) OPS DIR review (you'll see that it's in line with Terry's DISCUSS point): Based on my operational experience, I have seen multiple DNSSEC packets dropped by firewalls because they try to use EDNS0 rather than fragmenting. Does your I-D also address this issue? I am a little puzzled by the hand waving "we also assume that the path is clear of "DNS interfering" crap-ware/middle-boxes, like stupid firewalls, proxies, forwarders." (I would avoid the use of "stupid") This restriction does not appear as realistic to me in the current deployment. In the wave of IPv6 deployment and IPv4 sunset, I would suggest that examples (such as in 3.1.1) uses AAAA RR and not A. It is a little unclear to me WHEN the host should run those test? At boot time? At every network attach? When it resumes operation after a sleep period? Or a periodic test (such as hourly) ? This could cause a scalability problem in vast WiFi deployment. I am also a little puzzled by another hand waving "The goal of this document is to tie the above tests and aggregations to avoidance practices; however the document does not specify exactly how to do that." and later "Else return an useful error code" which will make interoperation (API portability) complex. With a little improvement for some unclear (to me) text, this document could be useful. Especially if either the mitigation part is improved or removed completely. I hope the above will help to improve a very useful document _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
