RMONMIB WG Meeting Minutes March 20, 2002 Minutes by Andy Bierman Review Material --------------- (A) draft-ietf-rmonmib-apm-mib-06.txt (B) draft-ietf-rmonmib-appverbs-03.txt (C) draft-ietf-rmonmib-hc-alarm-mib-00.txt (D) draft-ietf-rmonmib-sspm-mib-01.txt (E) draft-ietf-rmonmib-tpm-mib-05.txt Minutes ------- 1) Application Performance Measurement MIB (A) The latest version of the APM-MIB was discussed by the group. The following issues were raised, and some additional changes were approved. The RMONMIB WG contact information must be added to the CONTACT-INFO clause in the MODULE-IDENTITY macro. A clarification to the apmHttpIgnoreUnregisteredURLs description is needed to help developers properly implement this object. A new object called 'apmHttp5xxIsFailure' was discussed, which would be similar to the 'apmHttp4xxIsFailure' object for HTTP server errors. Althouth there are some corner cases which might be interesting to support, the group decided not to add this new object. A OwnerString object will be added to the apmHttpFilterTable. A new textual convention is needed, called DataSourceOrZero, because objects in the APM-MIB that currently use DataSource extend the semantics by defining semantics for the value { 0 0 }. This is illegal in the SMI, since DataSource must be a value of the form 'ifIndex.I'. The 'apmReportControlInsertsDenied' object has a syntax of Unsigned32, yet it appears to be a simple counter that can never go backward in value. The type Counter32 should be used for counters, or Gauge32 used if counter semantics are not appropriate. The type Unsigned32 is not correct. The 'apmReportControlReportNumber' object has a syntax of Unsigned32, yet when this object is copied into the aprmReportEntry as the apmReportIndex, the syntax changes to 'Integer32 (0..2147483647)'. Both these objects need the exact same syntax. Some new textual conventions are needed instead of embedding semantics in OBJECT-TYPE macros. These semantics are either needed right away in other RMON MIBs (such as TPM-MIB or SSPM-MIB) or may be needed in the future. They include: - apmAppDirectoryResponsivenessType object - apmHttpFilterMatchType - apmNameClientID - apmReportControlAggregationType 2) Transport Performance Metrics MIB (E) The latest version of the TPM-MIB was discussed by the group. The following issues were raised, and some additional changes were approved. The new indexing of the tpmExcpReportEntry will not work and will be changed back to the indexing found in the -04 version of this MIB. The MIB objects related to the clock used for TPM measurements overlap with objects found in draft-stephan-ippm-mib-01.txt (IPPM-MIB), which will soon be converted to a WG draft of the IPPM WG. The two MIBs will be examined to determine if there is enough commonality to justify a separate MIB module. Since TPM-MIB is almost done, and IPPM-MIB is just starting, this MIB module should be contained in the TPM-MIB draft. The TPM control table linkage to the APM MIB was discussed. It was decided that the TPM-MIB compliance for APM-MIB objects should state that the APM-MIB data tables associated with the APM-MIB control tables are not required for TPM-MIB conformance. There will be text added to the TPM-MIB explaining how the statistics based metric measurements in the TPM-MIB can be correlated with the bin-based measurements in the APM-MIB. The protocol classification known as 'Capital WEB' was discussed. There is currently no definition for this meta-protocol identifier. Some people think this meta-protocol should be identified in the RMON-2 protocol directory and others think it should be defined as a user application in the APM-MIB 'apmUserDefinedAppTable', since the concept only applies to APM-MIB and TPM-MIB, and not to RMON-2 functions. This meta-protocol represents the total packets and octets needed to transfer an entire WEB page and all the subordinate links embedded in that WEB page. This meta-protocol is the collection of multiple protocols (such as dns and http), and would cause protocols to be double counted in RMON-2 tables. It is also dependent on the host endpoint addresses for a given transaction, which may include multiple server addresses and one client address (e.g., some of the embedded links in the overall WEB page identify different servers in the same domain or even other domains). These properties make 'Capital WEB' inappropriate for inclusion in RMON-2 data tables. It is also possible that such data contained in APM or TPM reports will be inaccurate and misleading for the same reasons. Steve Waldbusser will post a PI macro definition for Capital WEB that will be rooted under the 'ianaAssigned' branch of the RMON protocol identifier tree. 3) Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms. (D) The latest version of the SSPM-MIB was discussed by the group. The following issues were raised, and some additional changes were approved. The 'sspmSourceFrequency' object has a granularity of MicroSeconds. There is some concern that low settings for this object will contribute to network congestion or even denial of service attacks, by flooding the network with test packets. It was decided that the granularity should not change (e.g., to milli-seconds) but instead an agent may enforce a lower bound by rejecting set requests to this object below this value. TBD: should another read-only object expressing this lower bound be added to the MIB? The 'sspmSourceSamplingDistribution' object was discussed, and the issue of additional distribution types was considered. Enumerations for 'exponential' and 'linear' have been requested on the mailing list. There was no resolution on whether these additional modes should be added, and this issue will be discussed further on the mailing list. The 'sspmSourcePacketFillType' object does not specify how often the URL specified in the 'sspmSourcePacketFillValue' object is checked if this object is set to 'url(3)'. It was decided that this URL is retrieved only once, when the associated 'sspmSourceStatus' object is set to active. The 'sspmApplLayerExtentionPassword' object was discussed and it was decided that the conformance section will reflect that this is an optional object, in order to reduce concerns in some environments about exposing real account passwords in MIB objects. The 'sspmSourceDestAddressType' object was discussed and it was decided that this object should not be limited to ipV4 only. The authors will consider if any additional objects are needed to also support ipv6. The source table parameter extension objects found in the sspmLinkLayerExtentionTable and SspmApplLayerExtentionTable were discussed. These objects can be added to the sspmSourceTable instead of being contained in additional tables with their own RowStatus objects (to reduce row creation complexity). The syntax and/or description clauses will be modified to indicate if the object is actually used for a given entry (e.g., zero-length string indicates object is not used). The structure of the MIB was discussed briefly, and an optimization for reuse was proposed. Currently, the sspmSourceTable contains the destination address and the sspmSinkTable contains a source address, requiring separate entries for every source/destination address pair. Instead, the source and sink tables should be address-pair independent, and a third table used to pair a source and sink entry, and activate the actual test traffic. This will allow individual source and sink entries to be reused when the same test trafic is sent from one source to multiple destinations. 4) Remote Monitoring MIB Extensions for High Capacity Alarms (C) The latest version of the HC-ALARM-MIB was discussed by the group. The following issues were raised, and some additional changes were approved. The MIB currently suggests that each hcAlarmEntry should be saved in non-volatile storage by the agent. The group decided a StorageType object should be added to the hcAlarmEntry instead. The hcAlarmVariable object was discussed regarding the requirement that the agent must return an error if the object is set to an object instance that cannot be accessed by the agent (e.g., the object doesn't exist or the instance doesn't exist). The group decided this restriction should be reversed. The agent must accept any well-formed OBJECT IDENTIFIER for this object. If the object is not valid at each polling interval the hcAlarmValueStatus instance will be set to valueNotAvailable(1). The group agreed to add an hcAlarmValueFailed counter to the hcAlarmEntry to let an NMS know how often the hcAlarmVariable object could not be accessed. The group decided an additional counter for the number of times the hcAlarmVariable object instance wrapped was not needed. The group decided to add an additional BITS scalar object to identify the hcAlarmTable capabilities (ala probeCapabilities found in RMON-2) supported by the agent. 5) Remote Network Monitoring MIB Protocol Identifier Reference Extensions (B) The group discussed the changes to the latest APP-VERB document. There was a suggestion for some additional clarifying text for the range of protocol verb enumeration values, but the document will not be re-issued for this additional sentence. This work item is now completed and the IESG will consider it for publication. 6) SMON, RMON-2, and RMON-PI Advancement The group was urged to complete implementation reports for RFC 2613, 2021, and 2074 as soon as possible. Survey emails were sent to the mailing list in March, which should be completed and sent to the WG Chair and/or the WG mailing list. These reports are needed to advance these documents from Proposed Standard to Draft Standard status. 7) Real-time Application Quality of Service Monitoring MIB (draft-siddiqui-rmonmib-raqmon-mib-01.txt) The RAQMON MIB was not on the agenda, but was discussed at the end of the meeting, after all official business was completed. The main issue discussed was the specification of two usage cases for conveying QoS metrics from an endpoint device to the RAQMON-MIB agent (e.g., collector). These statistics will be encoded as an OCTET STRING. For endpoints which contain an SNMP engine, the OCTET STRING should be encoded in a Notification as sent to the collector. For endpoints which support RTCP, a special application payload (type TBD) should be sent to the collector. There is a great deal of interest in the WG to get this work started as soon as possible.