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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-karp-crypto-key-table-08 Reviewer: David L. Black Review Date: August 9, 2013 IETF LC End Date: April 29, 2013 IETF Telechat Date: August 15, 2013 Summary: This draft is on the right track, but has open issues described in the review. This draft describes a conceptual key database for use by protocols. It's definitely useful and valuable work, as key management is often an afterthought in protocol design, even when security functionality is actively worked on in the design process. The draft text is in good shape and reads cleanly. The draft authors have addressed most of the issues and concerns from the GenART review of the -07 version of this draft, but three issues remain. I am particularly concerned with the first issue about whether FCFS is appropriate for these security-related registries, and believe that topic deserves IESG discussion. The three issues are ([9], [A] and [C] are the issue identifiers used on the original Gen-ART review of the -07 version of this draft): Major issue: [9] I suggest Expert Review for the new IANA registries, not just First Come First Served, so that someone with a security "clue" can check that the proposed registrations are reasonable. Minor issues: [A] Overall - I would like to see a paragraph added on how this database conceptually relates to the IPsec Peer Authorization Database (PAD) - see RFC 4301, section 4.4.3. [C] (Section 3) Where does key selection occur? I would suggest that the database return all possible keys and let the protocol figure out what to use. This is particularly important for inbound traffic for obvious reasons. Nits/editorial comments: First paragraph in 8.1.2 should be at end of 8.1.1. idnits 2.12.17 found two nits - the latter one (2119 reference/boilerplate) needs attention: ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 194: '...tion of key material. The KDF MAY use...' RFC 2119 keyword, line 196: '... or received but MUST NOT depend on ot...' Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1 (508) 293-7786 david.black at emc.com        Mobile: +1 (978) 394-7754 ----------------------------------------------------