<div dir="ltr"><div><div><div><div><div>Hi, <br><br></div>Thank you for addressing the comments. It is also very convienient to have the new version and the "how comments are addressed" document. <br><br></div>I think it is pretty important to note that TTL values are not so much documented, so mayby something similar as the editor response below could be placed in the intro or in section 3. <br></div><br>"Editors’ Response: RFC 1033 has a section on TTLs, which we reference <br>toward the end. Based on my familiarity with the RFCs I do not expect <br>that we’ll find more any specific advice to DNS operators in general, nor <br>for the root zone in particular." <br><br></div><div>I agree with the responses. <br><br>My response to comments 11'response would be: I agree that the figure is clear, What I meant was a "formal" relation between TTL values woudl be helpful to implement a checkzone test to somehow validate the root zone. Here the comment 11:<br><br>11) section 6.4.1 Is there any reason the relation between the different Time is not expressed. <br>SOA_Expire + NS_TTL <= ZSK_validity <br> <br>Editors’ Response: I’m not sure I understand the question. I think Figure 7 is clear. <br><br></div><div>Hope it helps, <br><br></div>BR, <br></div>Daniel<br><div><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 7, 2015 at 10:32 PM, Steve Sheng <span dir="ltr"><<a href="mailto:steve.sheng@icann.org" target="_blank">steve.sheng@icann.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div>Dear RSSAC Caucus, </div><div><br></div><div> Thank you for your feedback on the TTL document. The editors studied all the comments received from RSSAC Caucus, RSSAC and from ICANN on this report, and addressed all of them. </div><span><div style="word-wrap:break-word;color:rgb(0,0,0)"><div><br></div><div>Attached please find a revised version of the document. The major changes in this revision are: </div><div><br></div><div> 1) moved the problem statement to the introduction to properly motivate the discussion. </div><div> 2) added a section describing lab experiment to prove the signature validity problem can really happen.</div><div> 3) explained the (rare) conditions under which signature validity problems could occur.</div><div> 4) added caucus member’s input on mitigation options. </div><div> 5) editorial changes through out the document for factual corrections. </div><div><br></div><div> Please see four documents: </div><div><br></div><div> 1) clean, REDLINE (word and PDF) version of the latest advisory. </div><div> 2) a document listing how each comments are addressed by the editors. </div><div><br></div><div> With that, thank you very much for your input. Please let us know if there are any additional feedback that you have on this document. Duane will solicit further feedback from root server operators. Our goal is to finalize this document by IETF 93 and send it to RSSAC for action. </div><div><br></div><div>Best, </div><span class="HOEnZb"><font color="#888888"><div>Steve</div></font></span></div></span></div>
<br>_______________________________________________<br>
rssac-caucus mailing list<br>
<a href="mailto:rssac-caucus@icann.org">rssac-caucus@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/rssac-caucus" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/rssac-caucus</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Daniel Migault<br></div><div>Ericsson<br>8400 boulevard Decarie<br>Montreal, QC H4P 2N2<br>Canada<br><br>Phone: +1 514-452-2160<br><br></div></div></div></div></div>
</div>