Hi David, Thanks for the review! > 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.
Given that SHA-224 (and perhaps SHA-384) is not even present in all crypto libraries we could, if others don't see a problem, move this from a SHOULD to a MAY. > 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 Yup, sounds reasonable. We could add this too. > 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. > Yup, this can also be done. Cheers, Manav _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
