> >I am confused by your choice of names. The text uses, e.g., > >usmHMACSHA224128AuthProtocol > > > >whereas the MIB module has > > > > usmHmacSha224128Protocol > > > >Do these refer to the same identity (times six)? > > I think yes, and would suggest the following (unified) name format: > > usmHMAC128SHA224AuthProtocol
I like Uri's suggested name format. > >And then there are Security Considerations. You are replacing a simple, > >well understood choice of two values with a choice of eight, and saying > >that there is no need to implement them all. This gives great scope for > >a lack of interoperability. Should there be a mandatory to implement > >value (or negotiation - perhaps not)? > > Can we have mandatory-to-implement in an "optional" RFC? Assuming the > answer is yes, I'd recommend: > > For those who implement this RFC, usmHMAC192SHA256AuthProtocol is MUST, > usmHMAC384SHA512AuthProtocol is SHOULD, everything else is MAY. Unless > there's a preference for the "non-truncated" algorithms. > > >I would like to see some discussion of the benefits, if any, of the six > >new options. > > Do you mean "the benefits of having so many rather than just one or two", > or do you mean "the benefits of adding SHA2-based auth"? > > If it's the first - then we probably can shrink the number of the > available choices. The question is - do we select truncated ones (as the > prior standards did), or not? I would prefer shrinking the number of choices and using the truncated ones, although I don't feel strongly about that preference. > > If it's the second - I'll let others speak. :-) For me, the benefit of adding SHA2-based auth is that I have customers asking for it. (a small number of customers, but enough to justify the work since it is very low cost to implement). -David Reid _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
