[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RMONMIB] RE: Last Call: Remote Network Monitoring Management Information Base for High Capacity Networks to Proposed Standard
- To: "C. M. Heard" <heard@pobox.com>
- Subject: Re: [RMONMIB] RE: Last Call: Remote Network Monitoring Management Information Base for High Capacity Networks to Proposed Standard
- From: Andy Bierman <abierman@cisco.com>
- Date: Wed, 10 Oct 2001 10:49:29 -0700
- Cc: MIBS Mailing List <mibs@ops.ietf.org>, RMONMIB Mailing List <rmonmib@ietf.org>
At 02:53 PM 10/9/2001 -0700, C. M. Heard wrote:
>Hello,
>
>I want to respond to a few specific items in yesterday's e-mail
>messages from Andy Bierman and Bert Wijnen. First regarding
>the process issue:
I really like the idea of an IANA repository for MIB modules, but I still
think the
RFC containing the MIB module should be the normative reference.
<sidebar>
It would help a lot of people to have an option on the RFC search page
to type in the module name instead of the RFC number and
retrieve just the extracted MIB module. The first line (above the BEGIN)
should be a comment: "-- extracted from RFC xxxx".
</sidebar>
I read all your suggested edits to the 3 MIB modules in question.
Thanks for reviewing these drafts so closely. Now the IF-MIB
references are stale :-( The important edits are the new conformance
macros. Should the status go from current to obsolete, or
current to deprecated? I guess obsolete says the compliance is
broken and being fixed right away.
Andy
>On Mon, 8 Oct 2001, Andy Bierman wrote:
>Andy> At 12:33 PM 10/8/2001 -0700, C. M. Heard wrote:
>[ ... ]
>Andy> >Once again, let me state that I think that there should always be a
>Andy> >compilable version of every IETF MIB module that is the recognized,
>Andy> >official version. I think it would be a mistake to make a MIB fragment
>Andy> >normative. Up to now the de-facto rule has been that recoginized
>Andy> >official version versions of MIB modules are published in RFCs
>Andy> >(apart from the narrow exception of registration items that are under
>Andy> >IANA control). Maybe that needs to change. Maybe we should start
>Andy> >putting all IETF MIBs in an official MIB repository. Maybe this case
>Andy> >is an exception. But if we are going to change the rules -- whether on
>Andy> >a one-time basis, or permanently -- I think it would be reasonable to
>Andy> >state in writing that we are doing so.
>Andy>
>Andy> I agree that the rules should be constrained and written down.
>
>On Tue, 9 Oct 2001, Bert Wijnen wrote:
>Bert> > -----Original Message-----
>Bert> > From: C. M. Heard [mailto:heard@pobox.com]
>Bert> > Sent: Monday, October 08, 2001 9:33 PM
>[ ... ]
>Bert> > Up to now the de-facto rule has been that recoginized
>Bert> > official version versions of MIB modules are published in RFCs
>Bert> > (apart from the narrow exception of registration items that are under
>Bert> > IANA control). Maybe that needs to change. Maybe we should start
>Bert> > putting all IETF MIBs in an official MIB repository.
>Bert> >
>Bert> That is in fact being considered.
>Bert>
>Bert> > Maybe this case is an exception. But if we are going to change the
>Bert> > rules -- whether on a one-time basis, or permanently -- I think it
>Bert> > would be reasonable to state in writing that we are doing so.
>Bert> >
>Bert> I find the word "rules" a bit strong here. We have been discussion this
>Bert> approach for a while with various people. This is the first document to
>Bert> which we apply this approach. While we do this we get comments like
>yours.
>Bert> This is good. We need to understand all the implications and we need
>Bert> to be able to convince everyone (or better we need (rough) consensus)
>Bert> that this is the right (or an acceptable/pragmatic) approach.
>Bert> I think it is. Are we getting closer to convince you?
>
>I'm still not convinced that it is a good idea to update MIB modules by
>publishing MIB module fragments as normative text. The fact that there
>is a cut-and-paste process to make a compilable updated MIB module leaves
>room for error, and I'm not completely comfortable with that. As I will
>discuss below, it is also possible for a change to an object definition
>(such as extending the range of allowed enumerations) to silently change
>the meaning of conformance statements; thus, it seems to me that a reviwer
>needs to examine an updated MIB module as a whole in order to be sure
>that the updates are correct and complete.
>
>I like better the idea of migrating normative versions of standards-track
>IETF MIB modules from RFCs to an official on-line MIB repository. At
>present people need to maintain their own repositories by extracting MIB
>modules from the latest RFCs. A possible downside is that unless the
>MIB module repository is maintained with something like CVS we'd stand
>to lose the version history -- something that the RFC archival series now
>provides.
>
>That said, my main concern (as I stated in my first message on this topic)
>is that we codify in writing whatever procedures we adopt. This should
>take the form of a BCP.
>
>Publishing a BCP is a consensus process which takes time. It would
>not be fair to hold up the publication of HCRMON while that takes
>place. So my suggestion the the IESG would be:
>
>- first, quickly decide whether to proceed with the publication as
>announced in the last call, or whether to revert instead to the
>traditional procedure and publish updated versions of the RMON-MIB
>and RMON2-MIB in new RFCs (which I think was the WG's original plan).
>
>- then, if the decision is to proceed as announced in the last call,
>issue a temporary guideline (analogous to the one that was recently
>issued regarding the use of formal languages in IETF specifications)
>on when and how it is permitted to publish incremental updates to a
>MIB module. This temporary guideline should then be put into an
>internet-draft and debated. If rough consensus is achieved, the
>result would be the publication of a BCP.
>
>Does that seem reasonable?
>
>Now for some clarification on the technical and editorial matters:
>
>Bert> > -----Original Message-----
>Bert> > From: C. M. Heard [mailto:heard@pobox.com]
>Bert> > Sent: Monday, October 08, 2001 9:33 PM
>[ ... ]
>Bert> > [It] seems to me that
>Bert> >
>Bert> > http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-
>Bert> > 07-rmon.mib
>Bert> >
>Bert> > and
>Bert> >
>Bert> > http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-
>Bert> > 07-rmon2.mib
>Bert> >
>Bert> > represent updated versions of RMON1 and RMON2 with new capabilities
>Bert> > but which are fully backward compatible with the current versions --
>Bert> > or rather, which would be, if the conformance statements in them were
>Bert> > amended to point out that the enhancements are optional.
>Bert> >
>Bert> So is the proposal here to update the DESCRIPTION clause of the
>Bert> conformance statements to point that out? Any proposed text that
>Bert> we could consider/evaluate?
>
>That's a fair request. What I had in mind were updated conformance
>statements that make explicit -- via OBJECT clauses for hostTopNRateBase,
>nlMatrixTopNControlRateBase, and alMatrixTopNControlRateBase -- that the
>new enumeration values for those objects don't need to be supported
>if the HC-RMON-MIB is not implemented. The current draft versions have
>no such OBJECT clauses, which I think implies -- because these are
>read-create objects -- that all the enumerations (both old and new) need
>to be supported by a conformant implementation.
>
>Since I also brought up some editorial issues in my first message on
>this topic, let me take care of those as well by supplying context
>diffs with the suggested changes to the updated MIB files and the I-D.
>Actually the diffs include more changes than were initially suggested,
>mostly to references, but also to the ControlString TC which in RFC 2021
>used DisplayString as its SYNTAX (which RFC 2579 does not allow). Note
>that I did not update references to RFC 2819 because I'm not sure what
>to put in its place.
>
>Here are the suggested changes to the updated RMON-MIB module:
>
>*** draft-ietf-rmonmib-hcrmon-07-rmon.mib Tue Sep 25 15:52:37 2001
>--- fixed-draft-ietf-rmonmib-hcrmon-07-rmon.mib Tue Oct 9 13:03:25 2001
>***************
>*** 123,129 ****
>
> - examples of proper instance naming for each table"
>
>! REVISION "199110010000Z" -- 1 Nov, 1991
> DESCRIPTION
> "The original version of this MIB, published as RFC1271."
> ::= { rmonConformance 8 }
>--- 123,129 ----
>
> - examples of proper instance naming for each table"
>
>! REVISION "199111010000Z" -- 1 Nov, 1991
> DESCRIPTION
> "The original version of this MIB, published as RFC1271."
> ::= { rmonConformance 8 }
>***************
>*** 332,338 ****
> source can be any ethernet interface on this device.
> In order to identify a particular interface, this object
> shall identify the instance of the ifIndex object,
>! defined in RFC 2233 [17], for the desired interface.
> For example, if an entry were to receive data from
> interface #1, this object would be set to ifIndex.1.
>
>--- 332,338 ----
> source can be any ethernet interface on this device.
> In order to identify a particular interface, this object
> shall identify the instance of the ifIndex object,
>! defined in RFC 2863, for the desired interface.
> For example, if an entry were to receive data from
> interface #1, this object would be set to ifIndex.1.
>
>***************
>*** 713,719 ****
> interface on this device. In order to identify
> a particular interface, this object shall identify
> the instance of the ifIndex object, defined
>! in RFC 2233 [17], for the desired interface.
> For example, if an entry were to receive data from
> interface #1, this object would be set to ifIndex.1.
>
>--- 713,719 ----
> interface on this device. In order to identify
> a particular interface, this object shall identify
> the instance of the ifIndex object, defined
>! in RFC 2863, for the desired interface.
> For example, if an entry were to receive data from
> interface #1, this object would be set to ifIndex.1.
>
>***************
>*** 1543,1549 ****
> can be any interface on this device. In order
> to identify a particular interface, this object shall
> identify the instance of the ifIndex object, defined
>! in RFC 2233 [17], for the desired interface.
> For example, if an entry were to receive data from
> interface #1, this object would be set to ifIndex.1.
>
>--- 1543,1549 ----
> can be any interface on this device. In order
> to identify a particular interface, this object shall
> identify the instance of the ifIndex object, defined
>! in RFC 2863, for the desired interface.
> For example, if an entry were to receive data from
> interface #1, this object would be set to ifIndex.1.
>
>***************
>*** 2037,2044 ****
> If this value is less than or equal to 7, when the report
> is prepared, entries are created in the hostTopNTable
> associated with this object.
> If this value is greater than or equal to 8, when the report
>! is prepared, entries are created in the
> hostTopNHighCapacityTable associated with this object."
> ::= { hostTopNControlEntry 3 }
>
>--- 2037,2045 ----
> If this value is less than or equal to 7, when the report
> is prepared, entries are created in the hostTopNTable
> associated with this object.
>+
> If this value is greater than or equal to 8, when the report
>! is prepared, entries are created in the HC-RMON-MIB
> hostTopNHighCapacityTable associated with this object."
> ::= { hostTopNControlEntry 3 }
>
>***************
>*** 2299,2305 ****
> This source can be any interface on this device. In
> order to identify a particular interface, this object
> shall identify the instance of the ifIndex object,
>! defined in RFC 2233 [17], for the desired
> interface. For example, if an entry were to receive data
> from interface #1, this object would be set to ifIndex.1.
>
>--- 2300,2306 ----
> This source can be any interface on this device. In
> order to identify a particular interface, this object
> shall identify the instance of the ifIndex object,
>! defined in RFC 2863, for the desired
> interface. For example, if an entry were to receive data
> from interface #1, this object would be set to ifIndex.1.
>
>***************
>*** 2910,2916 ****
> the associated filters are applied to allow data into this
> channel. The interface identified by a particular value
> of this object is the same interface as identified by the
>! same value of the ifIndex object, defined in RFC 2233 [17].
>
> The filters in this group are applied to all packets on
> the local network segment attached to the identified
>--- 2911,2917 ----
> the associated filters are applied to allow data into this
> channel. The interface identified by a particular value
> of this object is the same interface as identified by the
>! same value of the ifIndex object, defined in RFC 2863.
>
> The filters in this group are applied to all packets on
> the local network segment attached to the identified
>***************
>*** 3777,3789 ****
>
> -- Compliance Statements
> rmonCompliance MODULE-COMPLIANCE
>! STATUS current
> DESCRIPTION
> "The requirements for conformance to the RMON MIB. At least
> one of the groups in this module must be implemented to
> conform to the RMON MIB. Implementations of this MIB
>! must also implement the system group of MIB-II [16] and the
>! IF-MIB [17]."
> MODULE -- this module
>
> GROUP rmonEtherStatsGroup
>--- 3778,3790 ----
>
> -- Compliance Statements
> rmonCompliance MODULE-COMPLIANCE
>! STATUS obsolete
> DESCRIPTION
> "The requirements for conformance to the RMON MIB. At least
> one of the groups in this module must be implemented to
> conform to the RMON MIB. Implementations of this MIB
>! must also implement the system group of MIB-II [RFC 1213]
>! and the IF-MIB [RFC 2233]."
> MODULE -- this module
>
> GROUP rmonEtherStatsGroup
>***************
>*** 3829,3834 ****
>--- 3830,3905 ----
> "The RMON Event Group is mandatory when the
> rmonAlarmGroup is implemented."
> ::= { rmonCompliances 1 }
>+
>+ rmonCompliance2 MODULE-COMPLIANCE
>+ STATUS current
>+ DESCRIPTION
>+ "The requirements for conformance to the RMON MIB. At least
>+ one of the groups in this module must be implemented to
>+ conform to the RMON MIB. Implementations of this MIB
>+ must also implement the systemGroup of the SNMPv2-MIB
>+ [RFC 1905] and the IF-MIB [RFC 2863]."
>+ MODULE -- this module
>+
>+ GROUP rmonEtherStatsGroup
>+ DESCRIPTION
>+ "The RMON Ethernet Statistics Group is optional."
>+
>+ GROUP rmonHistoryControlGroup
>+ DESCRIPTION
>+ "The RMON History Control Group is optional."
>+
>+ GROUP rmonEthernetHistoryGroup
>+ DESCRIPTION
>+ "The RMON Ethernet History Group is optional."
>+
>+ GROUP rmonAlarmGroup
>+ DESCRIPTION
>+ "The RMON Alarm Group is optional."
>+
>+ GROUP rmonHostGroup
>+ DESCRIPTION
>+ "The RMON Host Group is mandatory when the
>+ rmonHostTopNGroup is implemented."
>+
>+ GROUP rmonHostTopNGroup
>+ DESCRIPTION
>+ "The RMON Host Top N Group is optional."
>+
>+ GROUP rmonMatrixGroup
>+ DESCRIPTION
>+ "The RMON Matrix Group is optional."
>+
>+ GROUP rmonFilterGroup
>+ DESCRIPTION
>+ "The RMON Filter Group is mandatory when the
>+ rmonPacketCaptureGroup is implemented."
>+
>+ GROUP rmonPacketCaptureGroup
>+ DESCRIPTION
>+ "The RMON Packet Capture Group is optional."
>+
>+ GROUP rmonEventGroup
>+ DESCRIPTION
>+ "The RMON Event Group is mandatory when the
>+ rmonAlarmGroup is implemented."
>+
>+ OBJECT hostTopNRateBase
>+ SYNTAX INTEGER {
>+ hostTopNInPkts(1),
>+ hostTopNOutPkts(2),
>+ hostTopNInOctets(3),
>+ hostTopNOutOctets(4),
>+ hostTopNOutErrors(5),
>+ hostTopNOutBroadcastPkts(6),
>+ hostTopNOutMulticastPkts(7)
>+ }
>+ DESCRIPTION
>+ "Support for values greater than 7
>+ is not required when the HC-RMON-MIB
>+ hostTopNHighCapacityGroup is
>+ not implemented."
>+ ::= { rmonCompliances 2 }
>
> rmonEtherStatsGroup OBJECT-GROUP
> OBJECTS {
>
>
>Here are the suggested changes to the updated RMON2-MIB module:
>
>*** draft-ietf-rmonmib-hcrmon-07-rmon2.mib Tue Sep 25 15:52:37 2001
>--- fixed-draft-ietf-rmonmib-hcrmon-07-rmon2.mib Tue Oct 9
>14:08:14 2001
>***************
>*** 215,221 ****
>
> In order to identify a particular interface, this
> object shall identify the instance of the ifIndex
>! object, defined in [17], for the desired interface.
>
> For example, if an entry were to receive data from
> interface #1, this object would be set to ifIndex.1."
>--- 215,221 ----
>
> In order to identify a particular interface, this
> object shall identify the instance of the ifIndex
>! object, defined in [RFC2863], for the desired interface.
>
> For example, if an entry were to receive data from
> interface #1, this object would be set to ifIndex.1."
>***************
>*** 1016,1022 ****
>
> If this address mapping was discovered on an interface, this
> object shall identify the instance of the ifIndex
>! object, defined in [17], for the desired interface.
> For example, if an entry were to receive data from
> interface #1, this object would be set to ifIndex.1.
>
>--- 1016,1022 ----
>
> If this address mapping was discovered on an interface, this
> object shall identify the instance of the ifIndex
>! object, defined in [RFC2863], for the desired interface.
> For example, if an entry were to receive data from
> interface #1, this object would be set to ifIndex.1.
>
>***************
>*** 2177,2184 ****
> If this value is less than or equal to 2, when the report
> is prepared, entries are created in the nlMatrixTopNTable
> associated with this object.
> If this value is greater than or equal to 3, when the report
>! is prepared, entries are created in the
> nlMatrixTopNHighCapacityTable associated with this object."
> ::= { nlMatrixTopNControlEntry 3 }
>
>--- 2177,2185 ----
> If this value is less than or equal to 2, when the report
> is prepared, entries are created in the nlMatrixTopNTable
> associated with this object.
>+
> If this value is greater than or equal to 3, when the report
>! is prepared, entries are created in the HC-RMON-MIB
> nlMatrixTopNHighCapacityTable associated with this object."
> ::= { nlMatrixTopNControlEntry 3 }
>
>***************
>*** 3753,3759 ****
> STATUS current
> DESCRIPTION
> "This data type is used to communicate with a modem or a
>! serial data switch. A ControlString contains embedded
> commands to control how the device will interact with the
> remote device through the serial interface. Commands are
> represented as two character sequences beginning with
>--- 3754,3761 ----
> STATUS current
> DESCRIPTION
> "This data type is used to communicate with a modem or a
>! serial data switch. A ControlString is an NVT ASCII string
>! (see the DisplayString TC in [RFC2579]) containing embedded
> commands to control how the device will interact with the
> remote device through the serial interface. Commands are
> represented as two character sequences beginning with
>***************
>*** 3807,3813 ****
> ASCII characters (0-9, a-f, A-F) must follow the `^0x'
> control prefix. For example, `^0x0D^0x0A' is interpreted as a
> carriage return followed by a line feed."
>! SYNTAX DisplayString
>
> probeCapabilities OBJECT-TYPE
> SYNTAX BITS {
>--- 3809,3815 ----
> ASCII characters (0-9, a-f, A-F) must follow the `^0x'
> control prefix. For example, `^0x0D^0x0A' is interpreted as a
> carriage return followed by a line feed."
>! SYNTAX OCTET STRING (SIZE (0..255))
>
> probeCapabilities OBJECT-TYPE
> SYNTAX BITS {
>***************
>*** 5065,5072 ****
> rmon2MIBCompliances OBJECT IDENTIFIER ::= { rmonConformance 1 }
> rmon2MIBGroups OBJECT IDENTIFIER ::= { rmonConformance 2 }
>
> rmon2MIBCompliance MODULE-COMPLIANCE
>! STATUS current
> DESCRIPTION
> "Describes the requirements for conformance to
> the RMON2 MIB"
>--- 5067,5076 ----
> rmon2MIBCompliances OBJECT IDENTIFIER ::= { rmonConformance 1 }
> rmon2MIBGroups OBJECT IDENTIFIER ::= { rmonConformance 2 }
>
>+ -- obsolete compliance statements
>+
> rmon2MIBCompliance MODULE-COMPLIANCE
>! STATUS obsolete
> DESCRIPTION
> "Describes the requirements for conformance to
> the RMON2 MIB"
>***************
>*** 5086,5092 ****
> ::= { rmon2MIBCompliances 1 }
>
> rmon2MIBApplicationLayerCompliance MODULE-COMPLIANCE
>! STATUS current
> DESCRIPTION
> "Describes the requirements for conformance to
> the RMON2 MIB with Application Layer Enhancements."
>--- 5090,5096 ----
> ::= { rmon2MIBCompliances 1 }
>
> rmon2MIBApplicationLayerCompliance MODULE-COMPLIANCE
>! STATUS obsolete
> DESCRIPTION
> "Describes the requirements for conformance to
> the RMON2 MIB with Application Layer Enhancements."
>***************
>*** 5106,5111 ****
>--- 5110,5194 ----
> "The rmon1EnhancementGroup is mandatory for systems which
> implement RMON [RFC2819]"
> ::= { rmon2MIBCompliances 2 }
>+
>+ -- current compliance statements
>+
>+ rmon2MIBCompliance2 MODULE-COMPLIANCE
>+ STATUS current
>+ DESCRIPTION
>+ "Describes the requirements for conformance to
>+ the RMON2 MIB"
>+ MODULE -- this module
>+ MANDATORY-GROUPS { protocolDirectoryGroup,
>+ protocolDistributionGroup,
>+ addressMapGroup,
>+ nlHostGroup,
>+ nlMatrixGroup,
>+ usrHistoryGroup,
>+ probeInformationGroup }
>+
>+ GROUP rmon1EnhancementGroup
>+ DESCRIPTION
>+ "The rmon1EnhancementGroup is mandatory for systems which
>+ implement RMON [RFC2819]"
>+
>+ OBJECT nlMatrixTopNControlRateBase
>+ SYNTAX INTEGER {
>+ nlMatrixTopNPkts(1),
>+ nlMatrixTopNOctets(2)
>+ }
>+ DESCRIPTION
>+ "Support for values greater than 2
>+ is not required when the HC-RMON-MIB
>+ nlMatrixTopNHighCapacityGroup is
>+ not implemented."
>+ ::= { rmon2MIBCompliances 3 }
>+
>+ rmon2MIBApplicationLayerCompliance2 MODULE-COMPLIANCE
>+ STATUS current
>+ DESCRIPTION
>+ "Describes the requirements for conformance to
>+ the RMON2 MIB with Application Layer Enhancements."
>+ MODULE -- this module
>+ MANDATORY-GROUPS { protocolDirectoryGroup,
>+ protocolDistributionGroup,
>+ addressMapGroup,
>+ nlHostGroup,
>+ nlMatrixGroup,
>+ alHostGroup,
>+ alMatrixGroup,
>+ usrHistoryGroup,
>+ probeInformationGroup }
>+
>+ GROUP rmon1EnhancementGroup
>+ DESCRIPTION
>+ "The rmon1EnhancementGroup is mandatory for systems which
>+ implement RMON [RFC2819]"
>+
>+ OBJECT nlMatrixTopNControlRateBase
>+ SYNTAX INTEGER {
>+ nlMatrixTopNPkts(1),
>+ nlMatrixTopNOctets(2)
>+ }
>+ DESCRIPTION
>+ "Support for values greater than 2
>+ is not required when the HC-RMON-MIB
>+ nlMatrixTopNHighCapacityGroup is
>+ not implemented."
>+
>+ OBJECT alMatrixTopNControlRateBase
>+ SYNTAX INTEGER {
>+ alMatrixTopNTerminalsPkts(1),
>+ alMatrixTopNTerminalsOctets(2),
>+ alMatrixTopNAllPkts(3),
>+ alMatrixTopNAllOctets(4)
>+ }
>+ DESCRIPTION
>+ "Support for values greater than 4
>+ is not required when the HC-RMON-MIB
>+ alMatrixTopNHighCapacityGroup is
>+ not implemented."
>+ ::= { rmon2MIBCompliances 4 }
>
> protocolDirectoryGroup OBJECT-GROUP
> OBJECTS { protocolDirLastChange,
>
>
>Here are the corresponding changes for the hcrmon I-D itself:
>
>*** draft-ietf-rmonmib-hcrmon-09.txt Tue Sep 25 12:16:45 2001
>--- fixed-draft-ietf-rmonmib-hcrmon-09.txt Tue Oct 9 14:31:39 2001
>***************
>*** 393,400 ****
> If this value is less than or equal to 7, when the report
> is prepared, entries are created in the hostTopNTable
> associated with this object.
> If this value is greater than or equal to 8, when the report
>! is prepared, entries are created in the
> hostTopNHighCapacityTable associated with this object."
> ::= { hostTopNControlEntry 3 }
>
>--- 393,401 ----
> If this value is less than or equal to 7, when the report
> is prepared, entries are created in the hostTopNTable
> associated with this object.
>+
> If this value is greater than or equal to 8, when the report
>! is prepared, entries are created in the HC-RMON-MIB
> hostTopNHighCapacityTable associated with this object."
> ::= { hostTopNControlEntry 3 }
>
>***************
>*** 434,441 ****
> If this value is less than or equal to 2, when the report
> is prepared, entries are created in the nlMatrixTopNTable
> associated with this object.
> If this value is greater than or equal to 3, when the report
>! is prepared, entries are created in the
> nlMatrixTopNHighCapacityTable associated with this object."
> ::= { nlMatrixTopNControlEntry 3 }
>
>--- 435,443 ----
> If this value is less than or equal to 2, when the report
> is prepared, entries are created in the nlMatrixTopNTable
> associated with this object.
>+
> If this value is greater than or equal to 3, when the report
>! is prepared, entries are created in the HC-RMON-MIB
> nlMatrixTopNHighCapacityTable associated with this object."
> ::= { nlMatrixTopNControlEntry 3 }
>
>
>
>
>
>_______________________________________________
>RMONMIB mailing list
>RMONMIB@ietf.org
>http://www1.ietf.org/mailman/listinfo/rmonmib