[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call: Remote Network Monitoring Management Information Basefor High Capacity Networks to Proposed Standard
- To: MIBS Mailing List <mibs@ops.ietf.org>
- Subject: RE: Last Call: Remote Network Monitoring Management Information Basefor High Capacity Networks to Proposed Standard
- From: "C. M. Heard" <heard@pobox.com>
- Date: Tue, 9 Oct 2001 14:53:30 -0700 (PDT)
- cc: RMONMIB Mailing List <rmonmib@ietf.org>
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:
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 }