Greetings, and thanks for the comments on the third round. I have incorporated most of them, including Davey's suggestion for a further research item. I have also now made the document read-only to indicate that we are done editing. The next step is for Steve Sheng to turn this into a Word document again and pass it to RSSAC for publication. However, while he is doing that, I want the Caucus to review one significant technical change that we made during this round. The definition of "node re-delegation attack" in the Terminology section assumed a definition of the "Kaminsky attack" that is not reflected in the common understanding of the "Kaminsky attack", and didn't give any external reference for "node re-delegation". The new definition is below. I believe it is technically correct, and it directs the reader to Section 7.2 which says that we are going to need to do further study to see if the attacks are feasible. Please review this definition and, if you have any comments, send them to this list (do not try to edit the document) before May 17. That will give Steve enough time to finish his conversion work before he needs to pass the document back to RSSAC. Again, thanks for all the work you all have done on reviewing the document. The recommendations make it clear that further work will need to be done after this gets published, and I hope that there will interest from this group in doing that. --Paul Hoffman Node re-delegation attack – These attacks, if found to be feasible, could possibly allow an attacker to poison the cache of a recursive resolver in a similar fashion to the well-known “Kaminsky attack”. Node re-delegation attacks* might affect the resolution of all zones in resolvers that do not validate, and all unsigned zones in validating resolvers. Section 7.2 recommends further study to determine whether these attacks are feasible and, if so, what the effects might be. *https://www.sec-consult.com/fxdata/seccons/prod/downloads/whitepaper-dns-nod...