Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)
Note: This ballot was opened for revision 04 and is now closed.
(Adrian Farrel) Yes
(Jari Arkko) No Objection
(Richard Barnes) No Objection
(Spencer Dawkins) No Objection
(Stephen Farrell) (was Discuss, No Objection) No Objection
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  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).  http://www.ietf.org/mail-archive/web/secdir/current/msg04080.html
(Brian Haberman) No Objection
(Joel Jaeggli) No Objection
Comment (2013-08-14 for -04)
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.
Barry Leiba No Objection
Comment (2013-08-12 for -04)
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?
(Pete Resnick) No Objection
(Martin Stiemerling) No Objection
(Sean Turner) (was Discuss) No Objection
Thanks for clearing up my discuss points.