[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some more IPSEC MIB comments
Tim,
I'll second Tero's comment that the current draft generally looks
good. And I also have some comments on a few items.
Key length objects: I would prefer to show the actual key length even
when it is implied by the transform. Yes, that's not how it's encoded
in the protocol. I don't think that's relevant. Protocol encoding is
done for convenience in processing, MIB objects are designed for ease
of management. Often they match but there is no reason why they
should.
Time limit, traffic limit, traffic count: you showed those as octet
strings. You mentioned in your reply to Tero that's because they are
encoded that way. (Wow, bizarre.) But it is really nasty to use
octet strings to show integer data because it will display strangely,
and you might even get into byte order issues, and so on. Clearly
these parameters are integers (unsigned, actually). So the MIB data
type should be integer, or unsigned integer, or, in the case of
traffic count, Counter.
Traffic count and traffic limit: it might be easier to read these if
they showed the byte counts rather than the Kbyte counts.
Inbound and outbound traffic: are these the uncompressed byte counts
or the compressed counts? (For traffic limit related count, it's
compressed bytes, though it might be good to say that explicitly. For
the user level traffic counts it could be either.)
IKE SA peer cert issuer: you might mention exactly how this field is
encoded. I would guess it's the DER encoding of the X.50x DN of the
issuer.
Ipsec total traffic (page 28) -- why is this in Kbytes? Counters
normally are in bytes, and when you use Counter64 as the data type
(great!) there's no need to go to Kbytes.
Ipsec other receive errors (page 30) -- not mentioned in the
description, but presumably unknown SPI errors are also errors that
are not counted as "other".
paul