My apologies for getting this review in late. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I do not have security concerns with this document. See comments below. This document describes "signature" and "time" building blocks for constructing messages/packets as described in RFC 5444. There is actually noticeable overlap with Section 7.1 of RFC 5444, enough that I am inclined to say that this draft should indicate the it Updates 5444. The Security Considerations Section says "... has the same security considerations as [RFC5444]." In turn, RFC 5444 says "This specification does not describe a protocol; it describes a packet format. As such, it does not specify any security considerations; these are matters for a protocol using this specification." :-) But, in fact, the Security Considerations Section of 5444 continues with design suggestions for authentication/integrity and confidentiality. Arguably, this draft provides a more detailed syntax with some processing rules for authentication/integrity with signatures extending 5444. But it still defers much to any specific MANET protocol making use of RFC 5444, this draft, and probably additional "building block" drafts or RFCs. It appears that the MANET WG is approaching all this through a series of overlapping documents each of which is of limited content but provides more details. For example, this draft sets up hash function and cryptographic function IANA registries but provides only the identity function as initial content for these registries. Presumably additional documents will request allocations from these registries for other functions. There is nothing inherently wrong with this approach and trying to produce large monolithic documents can have problems. But a swarm of smaller inter-related and partly overlapping documents can be confusing. Section 8.1 and 9.1: These sections provide that when adding a packet or message signature TLV, respectively, any pre-existing packet or messages signature "MUST" be removed, etc., before signature calculation but only "SHOULD" be restored afterwards. I would have guessed that "SHOULD" would be a "MUST". In any case, it might be good to say when you don't need to restore a signature TLV, which I would assume would be if that signature TLV is not needed by the recipient. Thanks, Donald =============================  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)  155 Beaver Street, Milford, MA 01757 USA  d3e3e3 at gmail.com