RE: A slight flaw in the order of operations in USM

> Your approach requires the header processing sections to look into the
> PDU and interpret the contents/format to determine the operations type.
> That means the header processing must know just which type of PDU is
> encapsulated in the message, and that is not desirable for snmpv3.

Yes, this is true (well, my approach "suggests" looking into the PDU to
interpret...), although it's true anyway, with or without the approach.
The MPD document requires that the PDU type, if it is known/has been
determined, overrides the state of the 'reportable' flag.  ie.:

   The reportableFlag is a secondary aid in determining whether a Report
   PDU MUST be sent.  It is only used in cases where the PDU portion of
   a message cannot be decoded, due to, for example, an incorrect
   encryption key.  If the PDU can be decoded, the PDU type forms the
   basis for decisions on sending Report PDUs. [RFC 3412, $6.4]

So basically what I'm saying is, since the PDU portion of the message can
in fact be decoded if you just decrypt it before timeliness checking, then
you may as well go ahead and do so, even though you are not required to do
so by the literal order of operations.

--
Michael Kirkham
www.muonics.com