Subject: [MIB-DOCTORS] AD review of draft-ietf-ipfix-mib-05.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 17 Feb 2009 17:27:17 +0100

Please find below the AD (and MIB doctor) review of
draft-ietf-ipfix-mib-05.txt. This I-D is not ready yet for IETF Last
Call. Please address the issues below and issue a new I-D. 

Part of the comments were contributed by Bert Wijnen. 

I have divided the comments into Technical and Editorial. 

Thanks and Regards,

Dan

T1. INET-ADDRESS-MIB is IMPORT-ed from RFC 4001and not from RFC 3291

T2. There is no real justification for defining a new TC for
IpfixFunctionAvailability. As per RFC 4181, use TruthValue instead. 

T3. The top level structure of the MIB does not follow the
recommendation in Appendix D of RFC 4181 concerning the OID layout: 

  xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)

T4. The object iffixTransportSessionProtocol uses only 3 out of the 255
possible values in the range (6, 17, 132). A better SYNTAX would be just
INTEGER and then enumerate the three values in the MODULE-COMPLIANCE
clause. This would allow future changes by just another
MODULE-COMPLIANCE if there is a need to add a new protocol. If you
believe that another transport will be never added the appropriate
SYNTAX would be INTEGER (6|17|132). Also provide
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
as REFERENCE.

T5. There is only one InetAddressType object for both source and
destination addresses. Does this mean that an IPFIX session is only IPv4
to IPv4 or IPv6 to IPv6? This is a question, I apologize if it is a
layman one. In any case, it would be good to write an explanation, as
users of the RFC 4001 addresses TCs are used to always encounter pairs
of type-address objects. 

T6. Why are the address type and addresses objects only valid for UDP
and TCP, and not for SCTP? Are not STCP session also conducted between
IP hosts that can be described by IP addresses? 

T7. What does 'this object is only valid' mean for the address type and
addresses objects? What is returned by the agent in this case on a Get
operation on these objects? 

T8. The InetPort TC IMPORT-ed from RFC 4001 looks like a more
appropriate SYNTAX for the ipfixTransportSessionSourcePort and
ipfixTransportSessionDestinationPort objects

T9. I cannot figure out what is the role of all the DEFVAL clauses in
this MIB module. All the MIB is read-only and there is no dynamic row
creation. Why are they needed? 

T10. Many of the objects in the MIB modules - especially counters and
gauges - would benefit from defining UNITS clauses. In some places they
are mentioned in the DESCRIPTION clauses, but using explicit UNITS
clauses wherever possible is better. 

T11. Some object names in table do not respect the naming conventions
that recommends that table names and objects have an identical suffix -
ipfixObservationDomainId,  ipfixObservationPointGroupReference,
ipfixPhysicalEntity, ipfixPhysicalEntityDirection

T12. Some objects are completely missing REFERENCE clauses - especially
in the first tables o the MIB. Some other clauses could benefit from
more exact referencing, saying just [RFC5101] without mentioning the
exact section is not very useful. 

T13. Why is the range of ipfixTemplateDefinitionLength 1..2147483547)?
According to RFC 5101, section 7, page 31 it looks like it should be
(0..65535)

T14. Give http://www.iana.org/assignments/enterprise-numbers/ as
REFERENCE for ipfixTemplateDefinitionEnterprise

T15. Use hex notations for describing values in the DESCRIPTION clause
of ipfixTemplateDefintionFlags - the decimal values do not correspond to
the bits positions

T16. ipfixExportEntry leads to a warning in the smicng compilation 

W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a
consistent indexing scheme - index items from current table must come
after index items from other tables

T17. A couple of enumerated objects start to value 0 which is not
recommended unless special cases. Are there special cases here for
ipfixExportMemberType and ipfixPhysicalEntityDirection

T18. Unsigned32 seems to be a better SYNTAX than Integer32 (see RFC
4181) for the following objects: ipfixMeteringProcessId,
ipfixObservationPointGroupReference, ipfixObservationPointIndex,
ipfixTransportSessionRate

T19. I cannot understand what useful information carries
ipfixmeteringProcessId - it is not an index and its value is
implementation dependent. 

T20. Does it make sense for the ipfixSelectorFunction to point to a
function that is not available? 

T21. I assume that selection functions will be added in the future. If I
am wrong please delete all mention of extensibility and take out the
ipfixSelectorFunctions group. If I am right, I suggest to put
ipfixSelectorFunctions in a separate MIB module that will be IANA
maintained, so that new functions can be added in the future without the
need to revise the MIB module and the RFC. The separate MIB module will
become the initial version of the IANA maintained module, and new
selector functions will be added using for example Expert Review policy.

T22. it looks like Gauge32 would be a better SYNTAX for the following
objects: ipfixTransportSessionRate,
ipfixMeteringProcessCacheActiveFlows, ipfixMetering
ProcessCacheInactiveFlows

T23. How is ipfixTransportSessionRate computed? Every second? Every T
seconds? T=?

T24. I am wondering whether more counters in this MIB module need to be
Counter64 rather than Counter32 - especially the bytes and packets
counters

T25. There is no definition of the discontinuity behavior of all the
counter objects or definition of discontinuity objects.  

T26. It looks like Counter32 (or Counter64) with the appropriate
discontinuity objects are better SYNTAX for
ipfixSelectorStatsPacketsObserved and ipfixSelectorStatspacketsDropped. 

T27. Some of the DESCRIPTION clauses of the OBJECT-GROUPs contain
statements about the mandatory or optional characteristics of the
objects. This is inappropriate, such statements must be made in
MODULE-COMPLIANCE definitions, not in OBJECT-GROUP. 

T.28. Security Consideration sections - The description of the
vulnerability of objects in the tables should be more precise than
'contains configuration data that might be sensitive'. 

E1. Section 5.1 s/is defined in the MIB/is defined in the MIB module/

E2. The language in the sub-section of section 5 may be polished - for
example in section 5.3 and 5.4 s/may want to export/is configured to
export/

E3. Section 5.6 s/consists of a set of function/consists of a set of
functions/

E4. Section 5.6 - 'the Metering Process table (ipfixMetering
ProcessTable) is grouped by maintained by ...' - this phrase needs to be
fixed. 

E5. Section 6.1 - s/they should also implement the ENTITY MIB/they
SHOULD also implement the ENTITY MIB/

E6. Section 6.1 s/all entries in the Observation Point Table contain an
ipfixPhysicalEntity of zero(0)/all values of the ipfixPhysicalEntity
columns in the ipfixObservationPointTable are 0 and the values of the
ipfixPhysicalEntityDirection columns are none(0). 

E7. The DESCRIPTION clause and the name of the object
ipfixTransportSessionMode seem mis-leading. I think that this object
describes the device role in a session, not the mode of the session in
other words it's an attribute of the device that runs the agent and not
of the session. 

E8. The DESCRIPTION clause of the ipfixTemplateAccessTime object is
confusing. The second and third paragraph seem to duplicate the content
of the first paragraph. The last phrase of the clause seems to belong
rather in the DESCRIPTION clause of the table than here. 

E9. DESCRIPTION clause of ipfixObservationPointIndex - is this
'management system' or rather 'management agent'? 

E10. DESCRIPTION clause of ipfixPhysicalEntity s/the object contains
0/the value of the object is 0/

E11. What does 'a direction is not applicable' mean in the DESCRIPTION
clause of ipfixPhysicalEntityDirection?