Last Call Review of draft-ietf-dnsop-dnssec-roadblock-avoidance-04
review-ietf-dnsop-dnssec-roadblock-avoidance-04-opsdir-lc-vyncke-2016-07-11-00

Hi,



I have reviewed draft-ietf-dnsop-dnssec-roadblock-avoidance-04 as part of the
Operational directorate's ongoing effort to review all IETF documents being
processed by the IESG.  These comments were written with the intent of
improving the operational aspects
 of the IETF drafts. Comments that are not addressed in last call may be
 included in AD reviews during the IESG review.  Document editors and WG chairs
 should treat these comments just like any other last call comments.



From the abstract:

This document describes problems
 that a DNSSEC aware resolver/

application might run into within a non-compliant infrastructure.  It

 outline
 (SIC) potential detection and mitigation techniques. It provides a way for
 DNSSEC validator to check whether DNSSEC is not blocked on the path.

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

-éric