I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the General Area director. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: The draft is almost ready for publication as a BCP but I do have some comments you may wish to address. Minor ===== * Section 1 Not sure what becomes more feasible in this sentence. I am assuming that it is an attack becoming more feasible. If so, suggest rewording to something like. OLD: As new cryptanalysis techniques are developed and computing capabilities improve, the work factor to break a particular cryptographic algorithm will reduce, becoming more feasible for more attackers. NEW: As new cryptanalysis techniques are developed and computing capabilities improve, the work factor to break a particular cryptographic algorithm will reduce, thus making it more susceptible to attackers. * Section 2.6 Would it be useful to put in a recommendation here to use strongest possible algorithms/suites and longest possible keys for such long lived trust anchor certificates? * Section 3.4 The default server or responder configuration SHOULD disable such algorithms * Security considerations The reference to RFC5166 seems to be wrong and talks about evaluation of congestion control mechanisms. Just randomly searching through the RFC index led to me to RFC5116 that seems to be about authentication encryption algorithms. If this is the correct reference, it needs to be fixed in both this section and in the references section. Editorial ========= * The document is missing a Table of contents. The ID guidelines recommends a Table of Contents for drafts that are longer than 15 pages. * Section 1 s/one or more algorithm identifier/one or more algorithm identifiers/ * Section 2 OLD: one or more algorithm or suite identifier NEW: one or more algorithm or suite identifiers * Section 2.2 OLD: one or more strong mandatory-to-implement algorithm or suite NEW: one or more strong mandatory-to-implement algorithm or suites * Section 3.1 s/The IETF has alway/The IETF has always/ s/as well as meeting/and should also meet/ s/depending of the population/depending on the population/ Thanks Suresh