HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3
draft-ietf-opsawg-hmac-sha-2-usm-snmp-06

Thanks for your work on this draft!  It's great to see the improvements in security.

This is just a comment and not critical at all… I found this sentence at the bottom of the second bullet of 4.1 a little odd:
      as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC-
      SHA-96.

Since the guideline is to truncate the size in half and have 80 or more bits for a HMAC, you are covered and already cite the appropriate RFCs.  Is this there just for history of previous solutions?  Or would it be better to just state the guidance so folks understand why you chose the truncation size?  You can do nothing with my comment, it's just a question as the text had me curious.  And I see that you have included the HMAC truncation guidance in the security considerations section already.

I'm a yes on this, but am still holding my nose:-)

The yes is because it's a fine thing to make sure that up-to-date
options for securing protocols are available.

The nose-holding is because defining multiple options that 
aren't significantly different in strength (if one assumes that 
key management is the likely weakest link) is a bad plan.

In case it helps, my main logic for not wanting all these
options is that it is overwhelmingly more likely that the
code to switch between them or react to which you've received
or to configure things will (due to bugs etc.) weaken
security much much much more than the existence of more
than one of these options could ever strengthen security.
(Put another way the probability of a security bug due
to adding N things here is far far higher than the
probability that having N things saves the day when N-1
of them are no longer considered good crypto at some
point.)

So by defining more of these you are doing worse than
if you only defined one of these. (The fact that all sha2
digests have the same internal structure is part of but
not all of this argument.)

On truncation, I'd argue that if that was a significant
benefit then it'd be used everywhere and it is not. In
fact I don't believe truncation is used anywhere else
when there's no protocol (e.g. PDU/fragmentation) issue
that causes us to want shorter MACs.

I also believe that even those who for truncation would
agree that the benefit of reasonable-length truncation is
definitely an insignificant benefit, if any, and would
also agree that that's a matter of taste when it comes
to sha2 variants of hmac (assuming the protocol can live
with full length, as in this case).

Bottom line: Discuss is cleared and I'm out of the way, but 
with a heartfelt plea that you ditch all of these but one. And
then ditch truncation too. And so end up with just adding
hmac-sha2 as many other protocols have done.