DNSSEC Roadblock Avoidance
draft-ietf-dnsop-dnssec-roadblock-avoidance-05

I am agreeing with Terry's DISCUSS.

I think this is a useful document, but it is not entirely clear to me how well content of this document will age with time.

Nits:

In section 5:

  This will increase the likelihood that spit-view unsigned answers are found.

Should spit-view be split-view?

On page 14:
  For a stub resolver, problems with the name server MAY manifest themselves as the following types of error conditions:

This is not an implementation choice, so use of MAY is not appropriate. Change to "can" or the like.

I do agree with Terry's point.

- Agree with Terry's DISCUSS.

- Sec. 2: The last paragraph here isn't really about "goals" and seems like it belongs more appropriately in Sec 3.

- Sec 6.1: I thought recently gathered data has been pointing to the futility of popping up security warnings (e.g., http://neurosecurity.byu.edu/media/Anderson_et_al._CHI_2015.pdf). Does it really make sense to recommend warning users in a BCP? What are users expected to do as a result? Is there any evidence about the proportion of users who even know what DNSSEC is?

Just for good measure: I also agree with Terry's DISCUSS.

- I support Terry's discuss. 

- 1.2, 2nd paragraph: Is "full non-support" effectively different from "non-support" in this context?

Do we have reason to expect the github project to be maintained for the life of the RFC?

- 3.1.1 et. al. : Do we have reason to believe the dnssec-tools.org domain will be maintained for the life of the RFC?

- 5:

The first paragraph seems to say that the document does not accomplish it’s goal. Is that really the intent? (And doesn't the document at least do some of that?) 

"... we can determine what MUST be done in order..."
Spurious 2119 MUST

"short-circuit any unnecessary fallback attempts.":  Does "short circuit" mean the same as "avoid" in this context?

"problems with the name server MAY manifest": Spurious 2119 "MAY"

- 5.1, "It MAY be possible...": Spurious 2119 "MAY"

-5.1.2: s/real/really

- 6: "A newly established network connection MAY change state...": Spurious 2119 "MAY"

-8: Seems like there could be  more to say about the potential consequences about the “fail or proceed without security” decision in 6 and 6.1.

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

I support Stephen & Terry's discuss points.

1) Shouldn't/can't section 3.1.13. (UDP size limits) also specify a real test?

2) To follow up with the tsv-art review: To avoid network as well as server overload, would it be useful to provide further guidance, when and how often these tests should be performed?

3) In section 6.1.  (What To Do): maybe also list logging as an option in cases where no user is directly involved but a human might check later.

This was an entertaining read. 

I share Mirja's comments. In addition:

I'm not sure how well ESL readers will understand "crap-ware"/"crap" in this passage ("crap-ware" is probably a reasonable term of art, if it's intelligible enough to readers):

   NOTE: when performing these tests we also assume that the path is
   clear of "DNS interfering" crap-ware/middle-boxes, like stupid
   firewalls, proxies, forwarders.  Presence of such crap can easily
   make the recursive resolver look bad.  It is beyond the scope of the
   document as how to test around the interference.

I'm not sure what "ideally MUST" means, in 

   However, querying many zones will
   result in answers greater than 1220 bytes so ideally TCP MUST be
   available.

Agree with Terry's DISCUSS and COMMENTs

Thank you for addressing my DISCUSS (and other comments) in this new version.

Clearing my DISCUSS.