The -06 version of this draft has resolved all of the comments from the Gen-ART review of the -05 version.
Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, July 20, 2009 10:20 AM > To: 'Gen Art'; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Cc: Black, David; Acee Lindem; Abhay Roy; Ross Callon; Adrian > Farrel; [email protected] > Subject: Gen-ART review of draft-ietf-ospf-hmac-sha-05 > > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call > comments you may receive. > > Document: draft-ietf-ospf-hmac-sha-05 > Reviewer: David L. Black > Review Date: July 20, 2009 > IETF LC End Date: July 20, 2009 > > Summary: > > This draft is basically ready for publication, but has nits > that should be fixed before publication. > > Comments: > > This draft extends OSPFv2 cryptographic authentication to use > keyed HMACs based on the NIST secure hash standard family of > hashes (SHA-*). The draft is solidly written, and is a > reasonably straightforward application of HMAC and the SHA-* > hashes to OSPFv2. The draft is in good shape - all of my > comments are minor. > > I wonder whether the "SHOULD" requirement for implementation > in Section 3 ought to include HMAC-SHA-224 and HMAC-SHA-384. > I would have stated requirements for these two hashes as "MAY" > in order to encourage use of either HMAC-SHA-256 or HMAC-SHA-512 > when HMAC-SHA-1 is insufficient, but this is a judgment call. > To avoid confusion, this is a request that the authors think > about this topic; it is *not* a comment that the requirement > needs to be changed. If the authors believe that the current > "SHOULD" requirements for these two hashes are the right > approach, that is acceptable to me. > > In Section 3.2, it would be useful for the draft to say that an > OSPFv2 Security Association is not set up inband via OSPFv2, in > contrast to an IPsec Security Association created via IKE. Among > the reasons that this should be done is that the term "OSPFv2 > Security Association" is introduced in this draft - that term > does not occur in RFC 2328, even though Section D.3 of RFC 2328 > defines an abstraction for which "OSPFv2 Security Association" > is an appropriate name. I recommend stating that this term is > new to this draft. > > The mention of IP Security in the next to last paragraph of > the Security Considerations (section 4) should cite an > informative reference, RFC 4301 would be appropriate. > > idnits 2.11.12 did not find any issues. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > [email protected] Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
