I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-kitten-aes-cts-hmac-sha2-10 Reviewer: Vijay K. Gurbani Review Date: Jul-29-2016 IETF LC End Date: Jul-20-2016 IESG Telechat date: Unknown This document is ready as an Informational. Major: 0 Minor: 2 Nits: 1 Minor: - S3, top of page 4, while defining "context": What is the format of this optional string: is it comma separated? Or does it not matter because the byte-string in context is supposed to be an opaque label? I ask because the byte-string can contain multiple values (identities of parties, nonce, etc.); consequently, how does a receiver know where one value ended and another one began. I realize that when "context" is used for key derivation in the KDF, individual elements of the "context" does not matter; but since the text makes the point that "context" may include "identities of parties who are deriving and/or using the derived key material...", it seems appropriate that the recipient know what separates the ID from the nonce. - S3, middle of page 4: "When the encryption type is aes128-cts-hmac-sha256-128, k must be no greater than 256." 256 what? Bits (I believe). Similarly for 384. Better to be complete. Nits: - S1, second paragraph: "...but do not use the simplified profile." Any insight into why simplified profile is not used may be helpful to the reader for the sake of completeness. (Of course, if the reasons that the simplified profile is not being used are blatantly obvious to practicioners in this field, then don't worry about this comment. But if not, it may help.) Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani at nokia.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq