Last Call Review of draft-iab-crypto-alg-agility-06
review-iab-crypto-alg-agility-06-genart-lc-krishnan-2015-08-17-00

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