Subject: [ippm] IPPM MIB: Integration of Andy comments

From: "STEPHAN Emile FTRD/DAC/LAN" <[email-masked]>
Date: Mon, 16 Feb 2004 01:49:41 +0100

Dear All,

Andy made precise comments on the IPPM MIB just before the previous meeting.

I integrated most of them in the update of the MIB I have posted today (see below). To sum up I deleted the report group, most of the notifications and added 2 thresholds in the ippmAggrMeasureTable.

Following is an important to discuss: 

	Andy comments N°20. 
		MIB, ippmNetMeasureTable

	       " The IppmNetMeasureTable is mandatory, and its content is read 
	       only. It means that the measurement software handles the table 
	       internally. The setup of the network measure is not permitted 
	       through the IPPM REPORTING MIB. As an example, OWAP provides a 
	       setup protocol to setup and tear down networks measures. 

	Andy said:
		This goes entirely against the spirit of SNMP to contain
		a configuration table that is populated in an unspecified manner, and not allowing SNMP to be used for configuration. These objects should be read-create with a MIN-ACCESS of read-only.

Regards
Emile

#############################################################################

1. General comments

Although a good job has been done documenting this MIB,
IMO it is too complex to be deployable.  The resource requirements in the agent are very large.  Some of the 
tables can get extremely large, which would lead to 
poor SNMP performance.  The resource limitation mechanisms 
do not align well with actual SNMP agent implementation 
constraints.

This MIB is way too complicated and contains too many 
features that should be provided by an EMS or NMS.  There
are likely to be many implementation difficulties due to undocumented (and unforeseen) interactions between features. The MIB should be simplified to collect metric values and provide aggregation reports which can be retrieved via SNMP.  Analysis of the reports, threshold based exception handling, sending email and pages to administrators, 
etc. should be left to the application.

-----------------------------------------------------------------
Andy comments N°17. MIB, ippmHistoryTable

This table is very complex and can get very huge, or entries will be so short-lived that the table will be unstable and very difficult to retrieve.  

Keeping a timestamp and value for every metric value collected by the probe is overkill.

Emile: 
	The only solution to avoid unstable values in the history table consists in aggregating the network measures and in filtering the aggregated results.

	Regarding the timestamp, it is mandatory to known when a measure was performed. If not the measure is unusable.

-----------------------------------------------------------------
Andy comments N°2. sec. 3) SNMP Framework

This boilerplate is out of date.
Use the new template at: http://www.ops.ietf.org/mib-boilerplate.html

34. References

Check the MIB template for update to SNMP references.

Emile: 
	The references are not updated. I will be addressed asap as the draft will be considered as stable by the chairs and the TA.

-----------------------------------------------------------------
Andy comments N°3. sec 4, para 4) RMON model

This paragraph is incorrect. RMON can collect data from 
several interfaces which are not required to be in the
same chassis.

Emile: Done, I removed it.

-----------------------------------------------------------------
Andy comments N°4. sec. 4.1.3.1) Internet addresses 

Why are special address types needed for Src and Dest?

Emile: Because of the IPPM TypeP.

-----------------------------------------------------------------
Andy comments N°5. sec. 4.1.4)   GMTTimeStamp 

Why is it important to start the timestamp from 2000
instead of 1900?  This is extra work since implementations
are likely to support the standard "seconds since 1900"
format, not this new format.

Emile:  Initial the reason was to keep a bit free to manage the accuracy of the measure. As this is mamnaged in the ippmSyncTable I change back to "seconds since 1900".

-----------------------------------------------------------------

Andy comments N°7. MIB, TypeP TC)

This design is flawed because the authoritative name
of the protocol is based on the descriptive string found
in an RMON protocol identifier.  However this text string
is not normative and not required to be globally unique
or even consistent across implementations.

Emile: RMON protocol identifiers are 'informational'. The main point is to point to a common reference to avoid encapsulation mistakes.  

-----------------------------------------------------------------

Andy comments N°9. MIB, ippmSystemTime object

There should not need to be a special object for the
system time.  Also, how does the NMS know if the probe
is in proxy mode?

Emile: in the PointOfmeasure
-----------------------------------------------------------------

Andy comments N°10. MIB, Clock sync objects

   ippmSystemSynchronizationType
   ippmSystemSynchronizationDesc
   ippmSystemClockResolution

These objects should be in a separate MIB module
since this is a generic problem not specific to
IPPM reporting.

Emile: 

There is a generic problem behind each MIB. Regarding IPPM measurement, he RFC2330 states that implementation should "document the sources of uncertainty/error and quantify the amounts of uncertainty/error".

Synchronization is the main cause of measure uncertainties/errors , So it have to be treated in a specific way for IPPM measurement.

-----------------------------------------------------------------

Andy comments N°11. MIB, ippmSynchronizationTable

Why is a history table of up to 64K clock sync events
needed?  This will take up a lot of memory for very questionable value.  

Emile: 64k is an arbitrary number.  It is not recommended to keep permanently an history of 64k events.
Is there a need of a scalar to indicate the duration a event stays in the table ? 
I clarified the definition.

-----------------------------------------------------------------

Andy comments N°12.a MIB, point of measure table

  IppmPointOfMeasureEntry ::= SEQUENCE { 
   ippmPointOfMeasureIndex                Unsigned32, 
   ippmPointOfMeasureMgmtAddrType         InetAddressType, 
   ippmPointOfMeasureMgmtAddress          InetAddress, 
   ippmPointOfMeasureTestAddrTypeP        TypeP, 
   ippmPointOfMeasureTestAddr             TypePaddress, 
   ippmPointOfMeasureMetrics              IppmStandardMetrics 
  } 

Why is there a management address for each test point?
How is this used?  Why does the NMS need to know this?
Doesn't the NMS just contact the IPPM SNMP agent to
retrieve data?

Emile: A MIB managing points of measure should at least known their IP addresses for the test and for the management.

-----------------------------------------------------------------

Andy comments N°12.b MIB, point of measure table

Why is the test address of the measurement point needed?
Why isn't it an InetAddress?  How is this used?

Emile: I changed ippmPointOfMeasureTestAddr and type to InetAddress

-----------------------------------------------------------------

Andy comments N°13 and 14 . MIB, ippmMetricEntry & ippmMetricCapabilities

This table is broken because there is only one entry per metric.  This assumes that the collection capabilities are the same for every point of measure, which is not very likely.  The ippmPointOfMeasureIndex should be added
(first) to the INDEX clause in this table.

  ippmMetricCapabilities OBJECT-TYPE 
   SYNTAX INTEGER { 
   notImplemented(0), 
   implemented(1) 

Why is this object needed?  Why not just populate the
table for metrics that are implemented.  The other objects
in this table are irrelevant or unknown if the metric is
not implemented by the agent.

Emile: 

The Table is not broken ... but there was overlapping between pointOfMeasureTable and ippmMetricsTable:
Metrics implemented in a point of measures are listed in the field ippmPointOfMeasureMetrics (bit string) of the table ippmPointOfMeasureTable.

ippmMetricCapabilities is not at the right place: it should describe the aggretation capabilities of the SNMP agent. So I deleted it from the ippmMetricTable and added ippmSystemAggregatedMetrics in system group. ippmSystemAggregatedMetrics describes the aggreated metrics compute in the SNMP agent.

-----------------------------------------------------------------

Andy comments N°15. MIB, ippmOwnersTable

  IppmOwnersEntry ::= SEQUENCE { 
   ippmOwnersIndex              Unsigned32, 
   ippmOwnersOwner              IppmOwnerString, 

The ippmOwnerOwner object is the object that is used
to create unique index values in other tables (e.g.,
that represent history entries), yet this object is
required to be unique in this table.  The ippmOwnersIndex object has no value at all and should be removed.  This 
table should be indexed by the ippmOwnersOwner object.

Emile: I agree and removed ippmOwnersIndex

-----------------------------------------------------------------
Andy comments N°16. MIB, owner address

   ippmOwnersIpAddressType      InetAddressType, 
   ippmOwnersIpAddress          InetAddress, 

Why are these objects in the MIB?  Why does it
matter what the owner's address is in this MIB module?
If this is for sending notifications, then use the
MIBs in the SNMP Applications document, not this table.

   ippmOwnersEmail              SnmpAdminString, 
   ippmOwnersSMS                SnmpAdminString, 

These objects should be removed and the functions of
sending IPPM metric reports in email or phone messages
should be removed.  These functions are too complex for an
SNMP agent.  In addition, the format of the email
or SMS is not defined in any way.  This will not be interoperable in any way.

Emile: 
	I removed the reports functions.
	If VACM is not used there is an need to have administrative information on the owner:
   ippmOwnersIpAddressType and ippmOwnersIpAddress are needed to send SNMP Trap or Inform;
   ippmOwnersEmail is need to send fast report
   
   I removed ippmOwnersSMS

-----------------------------------------------------------------
Andy comments N°18. MIB, ippmHistorySequence

       Network metrics:  
       It's the sequence number of a measurement packet. Typically, it 
       identifies the order of the packet in the stream of packets sent 
       by the source. 
        
       Aggregated metrics: 
       It is the sequence number of the computed aggregated metric 
       result." 

Why is this object useful if the table already has an
index for the measure instance?  Why is an additional
index for the packet sequence needed?  What if the
entry is for a metric that utilizes more than one packet
in the measurement?

Emile:  As there are more that one packet per measure,ippmHistorySequence identifies each packet of the measure

-----------------------------------------------------------------
Andy comments N°19. MIB, ippmHistoryValue
   SYNTAX Integer32 

Why is this an Integer32 instead of Unsigned32?
Could it ever be a negative number?

Emile:  A metrics result can be negative

-----------------------------------------------------------------
Andy comments N°20. MIB, ippmNetMeasureTable

       " The IppmNetMeasureTable is mandatory, and its content is read 
       only. It means that the measurement software handles the table 
       internally. The setup of the network measure is not permitted 
       through the IPPM REPORTING MIB. As an example, OWAP provides a 
       setup protocol to setup and tear down networks measures. 

This goes entirely against the spirit of SNMP to contain
a configuration table that is populated in an unspecified manner, and not allowing SNMP to be used for configuration. These objects should be read-create with a MIN-ACCESS of read-only.

Also, this MIB should not include this table because this 
table indicates the configuration of test traffic generators.  
The comments in the previous paragraph apply to the MIB module 
that is eventually used for traffic generation.  The 
Synthetic Sources for Performance Measurements MIB (SSPM-MIB) 
should be used for this purpose.

The status and statistics objects in this table should
be split out and placed in another table.  That table 
may be appropriate for this MIB module.

Emile:  

-----------------------------------------------------------------
Andy comments N°21. MIB, IppmAggrMeasureEntry

   ippmAggrMeasureOwner                  IppmOwnerString, 
   ippmAggrMeasureIndex                  Unsigned32, 
   ippmAggrMeasureName                   SnmpAdminString, 
   ippmAggrMeasureMetrics                IppmStandardMetrics, 
   ippmAggrMeasureBeginTime              GMTTimeStamp, 
   ippmAggrMeasureAggrPeriodUnit         TimeUnit, 
   ippmAggrMeasureAggrPeriod             Unsigned32, 
   ippmAggrMeasureDurationUnit           TimeUnit, 
   ippmAggrMeasureDuration               Unsigned32, 
   ippmAggrMeasureHistorySize            Unsigned32, 
   ippmAggrMeasureStorageType            StorageType, 
   ippmAggrMeasureHistoryOwner           IppmOwnerString, 
   ippmAggrMeasureHistoryOwnerIndex      Unsigned32, 
   ippmAggrMeasureHistoryMetric          Unsigned32, 
   ippmAggrMeasureAdminState             INTEGER, 
   ippmAggrMeasureFastReport             OBJECT IDENTIFIER, 
   ippmAggrMeasureMap                    SnmpAdminString, 
   ippmAggrMeasureResultsMgmt            INTEGER, 
   ippmAggrMeasureLastUpdate             GMTTimeStamp, 
   ippmAggrMeasureOperState              INTEGER, 
   ippmAggrMeasureNbPktsTreated          Counter64, 
   ippmAggrMeasureStatus                 RowStatus 

This configuration table is rather complex.
The ippmAggrMeasureName object is redundant, since
this info is already available in another table.
Recording this long string in every entry is wasteful.

The ippmAggrMeasureHistoryOwner object makes this too complex. The same value for the owner in this table and the history table should be used.

The ippmAggrMeasureHistoryMetric object is confusing.  How does it relate to the ippmAggrMeasureMetrics object in this table?

It is not clear why the ippmAggrMeasureAdminState object
is needed and what it means to start or stop this entry
at any time.

The ippmAggrMeasureFastReport object is complex and
it is not clear what value it adds.  Why is this needed
and ippmReport needed?

Emile:  
	I remove all the report group.
	The fast report mode is designed to send by email results of a short and fast measure: It is not 

-----------------------------------------------------------------
Andy comments N°22. MIB, ippmAggrMeasureMap
   SYNTAX SnmpAdminString 
   MAX-ACCESS read-create 
   STATUS     current 
   DESCRIPTION 
       "This object allows for classification of the measure. It is 
       typically the name of an administrative map. 

I have no idea what this object is for.  There are no guidelines for populating this object and therefore no interoperability possible.

Emile:  I deleted ippmAggrMeasureMap and ippmNetMeasureMap 

-----------------------------------------------------------------
Andy comments 6, 8, 23-31: Report Group

Emile Correction: I deleted the group.

6. sec. 4.1.6)   Report definition 

This TC is very complex and overloads many functions
into a single bit string.  It should be broken out
into several MIB objects for simplicity and clarity.

8. MIB, IppmReportDefinition TC

This TC overloads event management, report filtering,
delivery options, and report cleanup options in a
long bit string.  This should be split into at least 
4 TCs (or MIB objects).

23. MIB, ippmReportPathToResults 

This URL object is a global scalar, which is odd since
multiple reports for multiple owners are created.
Why are results pushed off the box to a file?  What is
the format of this file?  Just SNMP access should be
provided.

24. MIB, IppmReportSetupEntry

This table sets up a report but it looks like each entry represents one metric.  This seems broken since the parameters would be the same for each metric collected in the set (IppmStandardMetrics OCTET STRING).  A different complex report configuration for each metric is too complicated.  Since some metrics are related to each other, it doesn't really make sense to have a report for each metric.  It would be much better to have one report for each set of metrics collected.

25. MIB, ippmReportSetupMeasureOwner

Why is this object needed?  This is too complex. Any type
of access control should be done by VACM, not by matching values of IppmOwnerStrings. Just the integer index pointer is needed.

26. MIB, thresholding objects in this table

This thresholding mechanism is too complex and too generic 
to be included in this table. 

27. MIB, ippmReportSetupNMS
   DESCRIPTION 
       "The recipient of the report may be provided in the setup. By 

This object is not needed.  SNMP should be used to retrieve data and other MIBs exist to determine where to send notifications.

28. MIB, ippmReportSetupNotification
   SYNTAX     OBJECT IDENTIFIER 
   MAX-ACCESS read-create 
   STATUS     current 
   DESCRIPTION 
       "Even though the notification to use is defined in the report 
       definition, the object ippmReportSetupNotification provides 
       flexibility to select another notification. " 
   DEFVAL { zeroDotZero } 

This object is too vague and there is no chance for 
interoperability.  This is also too complicated on the agent
to be told by the NMS which notification to generate
for each report.

29. MIB, ippmReportSetupMap
   DESCRIPTION 
       "An administrative name of a map to which the report belongs." 

This object is too vague and has no chance for interoperability. It should be removed.

30. MIB, ippmReportEntry

This table doesn't seem to add much value beyond the
history table.  It is also too complicated to have
separate results for every metric collected in a
report.  How are all metrics collected for a given
report correlated?  The network and aggregated features
seem too complicated and are not well defined.
A single report for all metrics collected together for
a given test should be provided instead.

31. MIB, ippmReportValue
   SYNTAX Integer32 
   MAX-ACCESS read-only 
   STATUS     current 
   DESCRIPTION 
       "The value." 

Why is this object an Integer32 instead of Unsigned32?
The description is not very useful.

Emile: Object removed

-----------------------------------------------------------------
32. MIB, Notifications

It is not very clear the exact conditions and configuration used by the agent to decide when to send each notification. It is not very clear why so many different notification types are needed.  All notifications include a lot of static info that is not really needed.

Emile: I removed most of them as they were related to the report group.
-----------------------------------------------------------------
33. Security considerations

Very good security section!

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm