[IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03

Greetings, all,

I've had a quick look at the present (-03) revision of the MIB Variable
Export draft. The document still needs at least one revision before it's
complete, as noted in its Open Issues section. I'll do a full review
after the open issues are handled.

But the fundamental change in this revision -- moving to an Options
Template based mechanism for binding OIDs to templates -- looks good,
and seems to be the right way to move this work forward.

I should note I still have no real understanding of how indexing works
in SNMP, despite having made an effort a couple of times now, and this
document makes it seem even more complicated than I thought it was. That
having been said, after having how often are indexes in SNMP used to
bind values to things we'd think of as flow keys in IPFIX? Does it make
sense to try to repurpose flowKeyIndicator here? This seems to be the
case in Section 6.4, but maybe I'm latching on to irrelevant details in
the example.

I have quite a few issues with the specifics of the mechanism and the
document itself. Since the details of the mechanism are described by the
IEs used in the options templates, I started in the IANA Considerations
section:

(1) Section 11.1 doesn't make any sense and should be removed. Unless
I've missed something fundamental, nothing else in the document suggests
that new Abstract Data Types are necessary for this mechanism to work.
If I have missed something fundamental, the mechanism should be
redefined such than new Abstract Data Types are not necessary.

(2) Usage of Data Type Semantics throughout section 11.2 is not
consistent with RFC 7012; non-numeric data types do not take Data Type
Semantics, as the semantics are inherent to the Abstract Data Type.

(3) Clarifying and SNMP-naif question on 11.2.2 mibObjectIdentifier: it
seems from the examples that the intention is that the OID will be
encoded in the document as a Unicode string of digits and "."
characters? Is this the way OIDs are encoded in SNMP? The encoding of
fundamentally binary data in strings is not very IPFIXish (7013 section
4.2 para 6), and I kind of expected these to be encoded as octetarrays
of unsigned integers of a specified size, or something similar. However,
if encoding-as-string is how things are done on the wire in SNMP, it's
the right thing to do here too (7013 section 4.5). The same comment
applies to 11.2.4.

(4) In 11.2.3 mibIndexList: the underlying data type of the elements of
the list encoded in the octetArray is missing from the description - are
these unsigned8s or unsigned16s? The encoding of internal structure
which doesn't come from some external protocol in an octetArray violates
7013 section 4.2. It seems like what you really want here is an
Information Element that is an instance of a basicList ADT with a
constraint in the description that states that only
informationElementIndex IEs are allowed as content.

(5) Also on 11.2.3 and 11.2.4, see comment above on using
flowKeyIndicator instead, if indeed that suggestion makes any sense.

(6) In 11.2.7 mibObjectBaseSyntax, I think the question "should there be
11 different IEs, one of each of the above types, rather than a single
mibObjectValue?" is definitely worth considering, as it would allow
faster handling at CPs based on the base syntax without having to decode
the base syntax from the options template. Not being a SNMP geek, I
don't understand why you need 11 here. Reduced length encoding and
mappings to IPFIX ADTs and semantics suggest the following seven
mappings to IPFIX IEs would suffice:

OCTET STRING and Opaque -> octetArray
INTEGER and Integer32 -> signed64 (with RLE) / quantity
Counter32 and Counter64 -> signed64 (with RLE) / totalCounter
Gauge32 and Unsigned32 -> unsigned64 (with RLE) / quantity
IpAddress -> ipv4Address (side question: how do you do V6 with SNMP?)
TimeTicks -> dateTimeSeconds (for IPFIX Epoch)
OBJECT IDENTIFIER -> see 11.2.2

There are some mismatches between base syntaxes and IPFIX data types
which it might be necessary to address. If keeping SNMP Counter
semantics is important (it seems like it might be), it might make sense
to add an snmpCounter Data Type Semantics. The minimum and maximum
values for a gauge can be bound to the gauge with
informationElementRangeBegin and informationElementRangeEnd from RFC 5610.

Doing this would obviate the need for the mibObjectBaseSyntax, no?

(7) In 11.2.10 mibContextIdentifier: is a context identifier similar to
an object identifier? Then it should be defined similar to 11.2.2 -- it
doesn't need a new ADT.

Editorial commentary (not exhaustive -- I'll wait 'til the open issues
are fixed before doing a full review):

(8) Section 5.1.2 "Minimum Required MIB Object Fields" is hard to
visually scan -- I had to look over it several times before I understood
that the things in the list are _optional_ while the things buried in
the first paragraph are required. Suggest using list formatting for all.

Best regards,

Brian

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCgAGBQJScyRAAAoJENt3nsOmbNJcJbwH/AtRmOCzoLodIkNozaKKdQd5
FlcFu7Al2ikbLar5SOLfaNt+UevIAJSkFt1w9QC4ZygdCAN7Qhc6gSHCYmuZ+XOu
GxUKmAfa/59g0oAQpuyw/oJBk4i39lXkFbn7Ifi2GEKoipjZMkYmYlPvmx/BZ0O0
Rai9gBYkBTrXMZcO9h4AYB5lq6N2abhKc6P3fQhjpXNPkiafMMA71uUPWodlwoaK
5rheS+o9sYdlgs3jgmMS0IsF9192Twzw93uBVQNIFubmYIa/cB2dg199VCfywmO2
C1Q1wWZZtxfFaLt9mp4UQZ6HxXuEyB+e/immODhDj68zi88zAjpjr+P0H2c4fA0=
=bG7i
-----END PGP SIGNATURE-----