Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)
draft-ietf-manet-rfc6622-bis-06

A fine document, this.  I have just two very minor comments about Section 1.1. which require no response.  If you disagree with them, feel free to just set them aside:

I found myself reading this sentence a couple of times as I tried to parse it:

   For the ICV TLV as well as repeating
   the specification of two type extensions, 0 and 1, it also specifies
   a new type extension, 2, in Section 12 of this document.

May I suggest this alternative?:

NEW
   For the ICV type, this document specifies a new type extension,
   2 (see Section 12), in addition to including the original type
   extensions (0 and 1) from RFC 6622.
END

Minor organizational comment: The subsequent paragraph, which gives some explanation and rationale for type extension 2, seems to belong in Section 12 (or a subsection), rather than in the introduction.  Maybe merge this into the last paragraph in 12.1.1, and get rid of it here?

I find myself concerned that the complexity and manageability considerations become more acute as this suite matures...

Statements like, 

  This architecture is a result of the observation that with respect to
   security in MANETs, "one size rarely fits all" and that MANET routing
   protocol deployment domains have varying security requirements
   ranging from "unbreakable" to "virtually none".  

do not give me confidence in the long term usability and interoperability of manet routing protol implementations that employ fully or partially mechanisms in 6622 or 6622-bis.

Thanks for clearing up my discuss points.

Thanks for handling my discuss about truncation. 

I didn't check the comments below vs. -06, but feel free to
follow up if needed, or not.

S

- 12.1: You say the truncation should be as specified for
the relevant function(s). I think you mean that each such
function registered in the IANA registry MUST specify if
truncation is allowed and to what length(s). Is that
right? If so, putting it that way would probably be
better. And in this case and for the -sec draft, since
you've not specified any truncation for HMAC-SHA-256 then
that means that all 256 bits must be used - right?

- section 13: I think it'd be good to say that the expert
SHOULD NOT approve registrations where ICVs can be
truncated so as to make them vulnerable given the state
of the art when the registration is requested.

- Please consider the suggestions made in the secdir
review [1] about naming and IANA. And for completeness
I'll note that I did discuss the lack of AKM here with
the authors and am ok with it, as per the justification
in the olsrv2 draft (even though the secdir reviewer
also properly noted this).

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04080.html