[Hubmib] RE: Resolution to comments from David Perkins
"Matt Squire" <MSquire@HatterasNetworks.com> Wed, 11 January 2006 03:26 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwWd3-000516-Kp; Tue, 10 Jan 2006 22:26:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwV25-0008PR-IQ for hubmib@megatron.ietf.org; Tue, 10 Jan 2006 20:44:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29843 for <hubmib@ietf.org>; Tue, 10 Jan 2006 20:42:50 -0500 (EST)
Received: from [72.15.200.20] (helo=mailserv.hatterasnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwV8e-0000QV-28 for hubmib@ietf.org; Tue, 10 Jan 2006 20:51:14 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 10 Jan 2006 20:43:15 -0500
Message-ID: <8052E2EA753D144EB906B7A7AA39971403F40294@mailserv.hatteras.com>
Thread-Topic: Resolution to comments from David Perkins
Thread-Index: AcX03f2h619QtlE5T2CtfEVssU+WmwhWdKlg
From: Matt Squire <MSquire@HatterasNetworks.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, Lior khermosh <lior.khermosh@passave.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 5b5d984330980e5b896a3a77a3695f69
X-Mailman-Approved-At: Tue, 10 Jan 2006 22:26:26 -0500
Cc: Hub MIB <hubmib@ietf.org>
Subject: [Hubmib] RE: Resolution to comments from David Perkins
X-BeenThere: hubmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Ethernet Interfaces an Hub MIB WG <hubmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:hubmib@ietf.org>
List-Help: <mailto:hubmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1689550718=="
Sender: hubmib-bounces@ietf.org
Errors-To: hubmib-bounces@ietf.org
Hi David, Dan - Below are my responses to the various comments. Many of the editorial problems (spelling error, etc.) won't be listed here as they don't really require discussion. I separated out what I consider the biggest issues and talk about them first, then include responses to your individual comments in the parts that follow. - Matt ======================== Bigger issues: a) "dot3" vs "efm". There were multiple comments related to whether various names in the MIB should be "efm..." or "dot3...". Admittedly, the reviewed version of the MIB had a mix of the two as it historically went from "EFM OAM" to "EFM Common" to "OAM" to whatever. To be clear, the OAM functionality of 802.3 is applicable to any Ethernet interface, not just those defined in 802.3ah, so it applies to 1000BASE-X, 10/100BASE-T, etc. For that reason, I'd suggest we move everything to a "dot3..." prefix rather than an "efm..." prefix, and to use "Ethernet OAM" as a description rather than "EFM OAM" (which appears in a few places). b) Improving description clauses. You commented that all description clauses for tables need to contain XYZ, similarly for rows. I've attempted to improve the description clauses based on your feedback. c) Removing frame reception conditions in MIB descriptions. You had multiple comments related to certain sections of the MIB (the OAM peer objects) where the descriptions included detailed information on what the values of various frame fields had to be in order to process the frame. As an example, the MIB had: An OAMPDU is indicated by a valid frame with (1) destination MAC address equal to that of the reserved MAC address for Slow Protocols (See 43B of [802.3ah]), (2) a lengthOrType field equal to the reserved type for Slow Protocols, (3) and a Slow Protocols subtype equal to that of the subtype reserved for OAM. You basically indicated that such details weren't needed in those sections. I'm more than fine with removing it. It was added several revisions ago when someone asked for more details about "when exactly does this value get updated?" At that point I added descriptions like the above to spell out as much as possible what has to be received for this field to be updated. I'd personally love to remove it, as it's just a bunch of extra words to me, but more than that I don't want to add it back again later. d) You found a couple of problems with my RTF-RFC conversion process. In what was Section 4.3, there was a mapping of SNMP to 802.3 attributes, and you rightfully pointed out there should be a section header and introduction sentence or two. At some point when going from the word RTF file to the text RFC, those were deleted. In the next rev, there will be a Section 4.4 just for the SNMP/802.3 attribute mappings. e) You pointed out some inconsistencies (and potential improvements) on explaining when entries are created/deleted from various tables. My suggestion going forward is to detail when entries are created in the primary control table (dot3OamTable), indicating they are automatically created for every Ethernet interface that supports OAM. And then say that other tables have entries automatically created for every entry in that primary table. The way things were written, - dot3OamPeerTable didn't always have an entry - it was written so that you could add an entry once you learned the peer, then leave it in there, but an entry wasn't required even if you were running OAM. I suggest changing that so that an entry is always required, and the various objects have mechanisms to indicate whether their values validly reflect an actual OAM peer, or whether there is no peer. This reflects several of your comments - dot3OamLoopbackTable didn't require an entry if the implementation didn't support loopback (there was a condition "if loopback is supported" in the description). Likewise, the dot3EventConfigTable didn't always require an entry (it's an optional function as well). Given the optional nature of certain functions (loopback, events, etc), I wasn't sure whether the tables should always have an entry (with some kind of 'not supported' indicator), or whether the tables should only have entries if the function is supported, or if there was some other approach. I'm open to suggestions. f) In the dot3OamAdminState, I had a description that included: Note that the value of this object is ignored when the interface is not operating in full-duplex mode. OAM is not supported on half-duplex links. ]] I'm not sure what "ignored" means here. ]] I don't believe that "ignored" is the right term. ]] Shouldn't whether the interface is in half or full-duplex ]] show up in the value of object dot3OamOperStatus? ]] I'm assuming that only interfaces that can operate ]] in full-duplex mode will be in this table. That ]] should of been said in the table DESCRIPTION clause. This is a little trickier than I originally thought. OAM was intended for full-duplex links, and some of the functions don't operate on half-duplex links. So I was trying to say that OAM shouldn't run on half-duplex links, so setting the admin state doesn't matter (hence the ignored). I'm open to finding better ways of saying that. Looking back at 802.3ah, I was unable to find the sections that indicate OAM doesn't come up on half-duplex links. So I believe what happens is that OAM would come up but some things might not work (anybody have a different interpretation)? If that's the case (as I think now), then I will probably have to rewrite that description to capture the proper behavior. I'm not sure that reflecting the duplex of the interface in the dot3OamStatus is either good or necessary. The OAM tables should exist whether the interface is full/half/auto, so the potential to be in full-duplex may be required, but you don't have to be in full-duplex mode to have an entry in the OAM table (your duplex may be auto, TBD later). g) In the loobpack object, right now there is a separate status and action attribute, so that you can set the action to start/stop loopback, then go read the status. You suggested a combined status/action object. First, I don't know what that means. Can you point me to an example in some other document? Second, the current separation of action/status was a result of discussions on either the list or at a meeting. All of the examples that I was able to find or were given to me for similar function had one attribute to initiate the action and another to return the result. h) You suggested combining dot3OamErrSymPeriodWindowHi and dot3OamErrSymPeriodWindowLo into one CounterBasedGauge64. This was discussed on the list previously and it was decided that was not possible. The discussion centered on CounterBasedGauge64s as being read-only counters. In this case, we need settable parameters as we're trying to setup a threshold. So I was told CounterBasedGauge64s were not applicable in that scenario, and that we needed to have two separate attributes with rules to combine them. i) On the dot3EventLogTable, you had questions about the maximum size and handling: ]] On this table, can it have an infinite number of entries? ]] Most likely not. In other tables, there is some indication ]] that says the max number (not always available), but ]] always something that says to either stop adding entries, ]] or delete the oldest, or some other algorithm to replace ]] the least important with a new one. I suggest saying the size of the table is implementation dependent, and that older entries are automatically replaced with newer entries when the table gets full. Is that satisfactory? j) In the event log table, you asked what were the running totals and event totals. After reading 802.3ah, you indicated you know what they mean, but a re-write of the description is in order. Here's my proposed DESCRIPTION: "Each Event Notification TLV contains a running total of the number of times an event has occurred, as well as the number of times an Event Notification for the event has been transmitted. For non-threshold crossing events, the number of events (dot3OamLogRunningTotal) and the number of resultant Event Notifications (dot3OamLogEventTotal) should be identical. For threshold crossing events, since multiple occurrences may be required to cross the threshold, these values are likely different. This value represents the total number of times one or more of these occurrences have resulted in an Event Notification (for example, 51 when 3253 symbol errors have occurred since the last reset, which has resulted in 51 symbol error threshold crossing events since the last reset). " k) You made suggestions on rearranging the hierarchy so that there is a dot3OamNotifications off dot3OamMIB, and having the notifications reference that. I'm fine with changing the tree that way so Notifications are moved up in the tree. l) In the reviewed versions, the compliance section has some unconditionally optional groups, allowing for a mix and match set of implementations. You suggested defining a minimum and maximum compliance group. I don't have a suggestion here yet. I need to think about it more, but would be interested in hearing opinions from anyone else. ================================= In the text below, I basically include the version of the draft with your comments in it as was sent to the mailing list. From that text, I removed certain sections that didn't have any comments, or had only what I considered uncontroversial editorial comments. Where text was removed, << Text deleted >> appears. Your comments are still prefixed with ]], while I put "MBS:" in front of my response. ]] Reviewed 8-sept-2005, david t. perkins, dperkins@snmpinfo.com ]] ]] Global comments: ]] Comments are inserted in-line and each comment line ]] is preceded by "]]". ]] ]]1) A line of "-"s is used as a separator. This is problematic ]] and if a separator is desired, the it should be something ]] like -- ************************************************** ]] (If the number of "-"s in a line is X, and mod(X,4)==1, ]] then a MIB compiler will report a parse error.) MBS: No problem doing the change. ]] ]]2) All the tables should have consistent info in the ]] DESCRIPTION clauses for the table and row definitions. ]] Minimally, the tables DESCRIPTION clause should describe ]] the table, and specify what determines the number of ]] entries in the table. ]] Minimally, the DESCRIPTION clause for rows should indicate ]] how rows are added and removed from tables. And if can ]] be done via direct SNMP operations, then the identification ]] of the RowStatus object. ]] Note that there is additional information that must be ]] contained in the DESCRIPTION clause as specified in ]] "Guidelines ... of MIB Documents" ]] <draft-ietf-ops-mib-review-guidelines-04.txt> ]] [MIBguidelines] MBS: I've attempted to update the objects as appropriate. They'll need to be reviewed to ensure they meet the goals. ]] ]]3) For enumerated values, each value be described in the ]] DESCRIPTION text of the object or TC definition. MBS: I found a couple instances where not every enumerated value was spelled out, and tried to correct that (you have specific comments to these at the various instances of the omission). ]] ]]5) The term "byte" should be replaced by term "octet". MBS: Changed. ]]6) The abbreviations "i.e.", and "e.g." are confused. ]] I suggest that you always write out "that is", ]] and "for example". MBS: I replaced the few occurences of "e.g." with "for example". Personally, I don't believe that it improves (or hurts) anything, but I'm more than willing to do it. The abbreviation "i.e." wasn't used in the document (that I could find). ]]7) A few typos were found by idnits script found at ]] http://ietf.levkowetz.com/tools/idnits/ MBS: I'll be sure to run the script on next revision before submission. Ethernet Interfaces and Hub MIB WG Internet Draft Matt Squire Document: draft-ietf-hubmib-efm-mib-03.txt Hatteras Networks Expires: September 2005 March, 2005 Ethernet in the First Mile (EFM) OAM MIB << Text deleted >> 3. Overview Ethernet networks have evolved over the past 30 years from simple LANs to a variety of other applications, including wide area networks. To address some of these emerging markets, the IEEE 802.3ah task force defined additional clauses for the IEEE 802.3 standard [802.3-2002] to better address Ethernet deployments in the public access network. ]] To make it clear, I'd change the above to the following: ]] To address some of these emerging markets, the IEEE ]] 802.3ah task force defined additional clauses in [802.3ah] ]] for the IEEE 802.3 standard [802.3-2002] to better address ]] Ethernet deployments in the public access network. MBS: Changed made. ]] Is 802.3ah work strictly for "public access networks"? ]] If not, then the phrase should be dropped or replaced. MBS: Access networks were the motivation for the task force, but the results can be applied for any application. So the phrase does address why the work was initiated and completed, but does not fully address applicability. Instead of the suggestion, I added a sentence; "Although Ethernet access deployments were the primary motivation for the task force work, the results of the task force are not limited to that application. " << Text deleted >> 4.1 Relation to other SNMP MIB Modules This objects defined in this document do not overlap with MIB-2 [RFC1213], the interfaces MIB [RFC2863], or the Ethernet like interfaces MIB [RFC3635]. The objects defined here are defined for Ethernet like interfaces only and use the same ifIndex as the associated Ethernet interface. Ethernet OAM can be implemented on any Ethernet like interface managed via these MIBs. ]] The "This" should be "The". ]] MIB-2 is obsolete, and I'm not sure what this section is ]] trying to say. I'm not sure that this functionality ]] can be applied on any "Ethernet-like" interfaces, ]] and not just on the interface types as specified ]] in [802.3ah]. MBS: The OAM functionality controlled by this MIB can be applied to any Ethernet interface (for example, 10/100BASE-T). This was an explicit goal of the OAM sub taskforce. This paragraph is attempting to say that this MIB does not overlap with existing MIBs used to manage Ethernet interfaces (several examples given via references). However, it is noted that the indexing scheme is the same. I can certainly try to re-write it again to make that point better. One possible wording would be: "The objects defined in this document manage OAM functionality introduced in [802.3ah] These objects do not overlap with MIB-2 [RFC1213], the interfaces MIB [RFC2863], the Ethernet like interfaces MIB [RFC3635], or any other MIB currently used to manage various aspects of an Ethernet interface. The objects defined here are defined for Ethernet like interfaces only and use the same ifIndex as the associated Ethernet interface. Ethernet OAM can be implemented on any Ethernet like interface." 4.2 Relation to other EFM MIB Modules The Ethernet OAM functionality and MIB Module is independent of the other functionality and MIB Modules derived from [802.3ah] for copper [802.3ah-copper] and EPON [802.3ah-epon]. Ethernet OAM may be implemented on point-to-multipoint EFM EPON interfaces. However, because higher layer protocols that run over Ethernet interfaces are not designed for the partial connectivity provided by a point-to-multipoint interface, EPON provides a point to-point emulation layer (see [802.3ah] and [802.3ah-epon]) whereby the single EPON interface of 1-to-N connectivity is represented by N point-to-point interfaces. Ethernet OAM, like any other protocol at the Ethernet layer or above (for example, bridging), utilizes the point-to-point emulation layer of EPON in that the EPON interface is viewed as N point-to-point Ethernet interfaces. Thus OAM, and other protocols, do not need to be altered for the EPON environment. Ethernet OAM may be implemented on the 2BASE-TL and 10PASS-TS Ethernet-over-copper interfaces defined in EFM [802.3ah]. 2BASE-TL and 10PASS-TS can be aggregated interfaces, meaning that they can use the ifStackTable of the Interfaces Group MIB [RFC2863] to manage a set of N (1 <= N <= 32) physical layers into a single Ethernet interface. M. Squire Expires - September 2005 [Page 5] EFM OAM MIB March 2005 The other Ethernet interfaces introduced in EFM [802.3ah] are simply new optical physical layers that are managed by minimal extensions to the MAU MIB [RFC3636] defining new types of Ethernet interfaces. 4.3 IANA Considerations The EFM OAM MIB requires the allocation of a single object identifier for its MODULE-IDENTITY under the MIB-2 tree. IANA has not yet allocated this object identifier. ]] This needs to be updated to follow the format as ]] specified in [MIBguidelines] MORE ]] The list that follows seems out of place. At the minimum ]] there needs to be a section header and intro. ]] ]] NOTE: I didn't check the list below for errors, such ]] as omissions and spellings. MBS: The lack of header/intro is apparently an artifact of RTF->I-D format conversion. I'll fix it in the next revision. The headers and introduction exist in my RTF file. [802.3ah] Clause 30, and managed objects defined in this document. IEEE 802.3 Managed Object Corresponding SNMP object ]] In the below, it would be useful to also show the object class ]] (the oXXX) containing each attribute. For example, the MAU MIB ]] document (draft-ietf-hubmib-rfc3636bis-01.txt) does this. MBS: Easy enough to do (there's just oOAM). .aOAMID IF-MIB ifIndex 5. MIB Structure The common EFM MIB objects of this memo focus on the OAM capabilities introduced in IEEE 802.3ah. The MIB objects are partitioned into six ]] Probably want [803.3ah] instead of just 802.3ah MBS: Done different MIB groups. The dot3OamTable group manages the primary OAM objects of the Ethernet interface. This group controls the state and status of OAM as well as the mode in which it operates. The dot3OamPeerTable maintains the current information on the status and configuration of the peer OAM entity on the Ethernet interface. Managed information includes the capabilities and function available ]] I think "capabilities" and "function" are the same, so ]] I would drop "and function". MBS: I'm not sure I agree with that. Capabilities generally refers to what the other guy can do, while functions refers to what it does. Some capabilities may be disabled or inoperable for many reasons. So I'm trying to say that the MIB covers both potential and actual functionality. on the peer OAM entity. M. Squire Expires - September 2005 [Page 7] EFM OAM MIB March 2005 The dot3OamLoopbackTable manages the loopback function introduced in EFM [802.3ah]. This table controls enabling and disabling loopback, ]] Is there a difference between "EFM [802.3af]" and "[802.3af]"? ]] If so, this needs to be reflected throughout the the ]] document. If not, then the "EFM" should be removed. MBS: No difference,so I removed EFM. The benefit of having it in there is that many people know the project as EFM, even though this function is not restricted to the physical layers of that project. as well as indicating the loopback status of Ethernet OAM on this interface. ]] Above and through the document, the terms "Ethernet OAM", ]] and "EFM OAM" are used. Are these the same, or different? ]] If different, then this needs to be explained. If the ]] same, then one should be chosen and used consistently. MBS: There's no intended difference. As the OAM functionality applies to any Ethernet interface, I will go with Ethernet OAM rather than EFM OAM. << Text deleted >> 6. MIB Definition EFM-COMMON-MIB DEFINITIONS ::= BEGIN ]] This module name doesn't follow the naming conventions ]] in the [MIBguidelines] document. However, I can't determine ]] if it should be DOT3-OAM-MIB, or "EFM-OAM-MIB". MBS: It should be DOT3-OAM-MIB to me, so that's what I'll change it to. IMPORTS MODULE-IDENTITY, mib-2, OBJECT-TYPE, Counter32, Unsigned32, Integer32, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, MacAddress, TimeStamp FROM SNMPv2-TC CounterBasedGauge64 FROM HCNUM-TC ifIndex FROM IF-MIB MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; efmOamMIB MODULE-IDENTITY ]] Not sure if should be efmOamMIB or dot3OamMIB MBS: Changed to dot3OamMIB LAST-UPDATED "200503220000Z" -- March 22, 2005" ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group" CONTACT-INFO "WG Charter: http://www.ietf.org/html.charters/hubmib-charter.html Mailing lists: M. Squire Expires - September 2005 [Page 8] EFM OAM MIB March 2005 General Discussion: hubmib@ietf.org To Subscribe: hubmib-requests@ietf.org In Body: subscribe your_email_address Chair: Dan Romascanu, Avaya Tel: +972-3-645-8414 Email: dromasca at avaya dot com Editor: Matt Squire Hatteras Networks Tel: +1-919-991-5460 Fax: +1-919-991-0743 E-mail: msquire at hatterasnetworks dot com " DESCRIPTION "The MIB module for managing the new Ethernet OAM features introduced by the Ethernet in the First Mile task force (IEEE 802.3ah). The functionality presented here is based on IEEE 802.3ah [802.3ah], released in October, 2004. In particular, this MIB focused on the changes to Clause 30 of the draft that are not specific to any physical layer. These changes are primarily reflected in the new OAM features developed under this project, that can be applied to any Ethernet like interface. The OAM features are described in Clause 57 of [802.3ah]. ]] First, is it clause 30 or 57. ]] Also, the above reads strangely. People that don't understand ]] exactly how IEEE documents are updated (which is very different ]] than how IETF documents are updated). MBS: Attempted re-wording below. Hopefully this will make more sense to you. The functionality is described in one clause, but the management attributes of that functionality are described in another. " In particular, this MIB focuses on the new OAM functions introduced in Clause 57 of [802.3ah]. The OAM functionality of Clasue 57 is controlled by new management attributes introduced in Clause 30 of [802.3ah]. The OAM functions are not specific to any particular Ethernet physical layer, and can be generically applied to any Ethernet interface of [802.3-2002]. " << Text deleted >> -- -- Ethernet OAM Control group -- dot3OamTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Primary controls and status for the OAM capabilities of an Ethernet like interface. There will be one row in this table for each Ethernet like interface in the system that supports the Ethernet OAM functions defined in [802.3ah]." ::= { dot3OamMIB 1 } ]] I'm still unclear as to exactly which interfaces will be ]] in this table. For example, if a 10baseT interface card ]] is plugged into the device, will a new row show up? ]] Or is it only for the Cu and EPON interfaces? ]] And does some other configuration (outside of SNMP) ]] configuration have to be done? ]] I believe the answer is not, but want to determine ]] if aggregated interfaces can exist in the table? MBS: Any Ethernet interface that can appear in the Ethernet like MIB table can appear here if OAM functionality is supported. So the answer to your questions are - yes, if the interfaces support Ethernet OAM (which is optional) - no, it is not only for the Cu/EPON interfaces - no, no other configuration is required dot3OamEntry OBJECT-TYPE SYNTAX Dot3OamEntry MAX-ACCESS not-accessible M. Squire Expires - September 2005 [Page 10] EFM OAM MIB March 2005 STATUS current DESCRIPTION "An entry in the table, containing information on the Ethernet OAM function for a single Ethernet like interface." INDEX { ifIndex } ::= { dot3OamTable 1 } ]] The SMI requires in the DESCRIPTION clause for a row, ]] a description of index objects that not defined in the ]] table. MBS: Added a description that says when entries created/deleted and the row status. Dot3OamEntry ::= SEQUENCE { dot3OamAdminState INTEGER, dot3OamOperStatus INTEGER, dot3OamMode INTEGER, dot3OamMaxOamPduSize Integer32, dot3OamConfigRevision Unsigned32, dot3OamFunctionsSupported BITS } dot3OamAdminState OBJECT-TYPE SYNTAX INTEGER { disabled(1), enabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to provision the default administrative OAM mode for this interface. This object represents the desired state of OAM for this interface. The dot3OamAdminState always starts in the disabled(1) state until an explicity management action or configuration ]] ^^^^^^spelling error MBS: Fixed. information retained by the system causes a transition to the enabled(2) state. Note that the value of this object is ignored when the interface is not operating in full-duplex mode. OAM is not supported on half-duplex links. " REFERENCE "[802.3ah], 30.3.6.1.2" ::= { dot3OamEntry 1 } ]] I'm not sure what "ignored" means here. ]] I don't believe that "ignored" is the right term. ]] Shouldn't whether the interface is in half or full-duplex ]] show up in the value of object dot3OamOperStatus? ]] I'm assuming that only interfaces that can operate ]] in full-duplex mode will be in this table. That ]] should of been said in the table DESCRIPTION clause. MBS: This is a little tricky. Certain functions in Ethernet OAM assume full-duplex links. So I tried to say that you should ignore the provisioned enable/disable admin state if the link comes up half-duplex, and just leave OAM disabled. Certainly a link should have the capacity to be full-duplex to appear in this table. However, if the interface hasn't negotiated duplex yet, we should still allow it in the table so that OAM can be configured in case the link comes up full-duplex. MBS: This behavior is certainly up for interpretation. We could allow OAm to operate on half-duplex links though not every function will be available. Open to suggestions. dot3OamOperStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), linkfault(2), passiveWait(3), activeSendLocal(4), sendLocalAndRemote(5), sendLocalAndRemoteOk(6), M. Squire Expires - September 2005 [Page 11] EFM OAM MIB March 2005 oamPeeringLocallyRejected(7), oamPeeringRemotelyRejected(8), operational(9) } ]] What values indicate that ifAdmin status is set down ]] or testing? ]] What are the values when ifOperStatus is not up? ]] It seems like some of these could occur concurrently. ]] Is this possible? MBS: if the physical layer is not up, OAM will be in linkfault state (regardless of whether its down, testing, or anything else). The linkFault state is the starting state for any enabled OAM implementation. There are OAM state machines in [802.3ah] that define the 9 states above, and one and only one is possible at any time. << Text deleted >> dot3OamMaxOamPduSize OBJECT-TYPE SYNTAX Integer32 (64..1522) ]] This should be Unsigned32. ]] Also, is 1522 really the max? MBS: I'll change to Unsigned32 though its not clear to me why thats better. The maximum value, as defined in [802.3ah] is equal the maximum untagged frame size (which is undergoing change in 802.3 as we speak). I'd like to put a variable in here that ties it to the maxUntaggedFrameSize, but I don't know what that variable would be. Numerically, it should currently be 1518, not 1522. UNITS "bytes" MAX-ACCESS read-only STATUS current M. Squire Expires - September 2005 [Page 13] EFM OAM MIB March 2005 DESCRIPTION "The largest OAMPDU that the OAM entity supports. OAM entities exchange maximum OAMPDU sizes and negotiate to use the smaller of the two maximum OAMPDU sizes between the peers. This value is determined by the local implementation. " REFERENCE "[802.3ah], 30.3.6.1.8" ::= { dot3OamEntry 4 } << Text deleted >> ------------------------------------------------------------------ -- -- Ethernet OAM Peer group -- M. Squire Expires - September 2005 [Page 14] EFM OAM MIB March 2005 dot3OamPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the OAM peer for a particular Ethernet like interface. OAM entities communicate with a single OAM peer entity on full-duplex Ethernet links on which OAM is enabled and operating properly. In certain states, the OAM peer information is not available. Whether peer information is available is communicated via the dot3OamPeerStatus object. When this object is inactive, all other information in the row is to be considered invalid. " ::= { dot3OamMIB 2 } ]] Fix this table DESCRIPTION as per global comments ]] The issue of communicating that when the value of dot3OamPeerStatus ]] is 'inactive(2)' that the values of the other columns is ]] unknown, is difficult. Yes, it is said in the DESCRIPTION ]] clause for the row, but I suggest that you also put ]] that in the DESCRIPTION clause for each column. Also, ]] if possible, define a value for each column that is ]] returned when dot3OamPeerStatus is 'inactive(2)', ]] which CAN NOT be a valid value with dot3OamPeerStatus ]] has value 'active(1)'. MBS: I've attempted to incorporate this comment in the next revision, and the invalid statement is repeated for every column. Its not clear how to devine unique invalid values for every column - for example a bits field or an unsigned32 where all 2^32 values are allowed. So I wasn't able to implement that part of the comment for every column. dot3OamPeerEntry OBJECT-TYPE SYNTAX Dot3OamPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information on the peer OAM entity for a single Ethernet like interface. Note that there is at most one OAM peer for each Ethernet like interface. There is exactly one row in this table for each Ethernet like interface supporting OAM. " INDEX { ifIndex } ::= { dot3OamPeerTable 1 } ]] Fix. Note, I believe it would be clearer to say ]] (in the DESCRIPTION for the table) that a row ]] exists in this table for each row in the OAM control ]] table. MBS: I'm not sure what you mean by the "OAM control table", but the intent is that there is at most one row for every entry in the dot3OamTable. There may be zero rows in this table for an entry in the dot3OamTable if the peer information has not been discovered (yet). I guess we could say there's always a row but that its information is inactive(2) - is that your point? That probably is simpler. Dot3OamPeerEntry ::= SEQUENCE { dot3OamPeerStatus INTEGER, dot3OamPeerMacAddress MacAddress, dot3OamPeerVendorOui Dot3Oui, dot3OamPeerVendorInfo Unsigned32, dot3OamPeerMode INTEGER, dot3OamPeerMaxOamPduSize Integer32, dot3OamPeerConfigRevision Unsigned32, dot3OamPeerFunctionsSupported BITS } dot3OamPeerStatus OBJECT-TYPE SYNTAX INTEGER { active(1), inactive(2) } MAX-ACCESS read-only M. Squire Expires - September 2005 [Page 15] EFM OAM MIB March 2005 STATUS current DESCRIPTION "This object indicates whether the information in this row should be considered valid. When active(1), the information is valid and represents the current peer of the OAM entity. When inactive(2), the information in this row is invalid. A value of inactive(2) is returned if the dot3OamOperStatus is disabled, passiveWait, or activeSendLocal. For all other values of dot3OamOperStatus, a value of active(1) is returned. " ::= { dot3OamPeerEntry 1 } ]] The above doesn't seem possible. Please check. ]] It seems that only when dot3OamOperStatus has the ]] value of 'operational(9)' can this have value 'active(1)' MBS: The intent is that you know about the peer entity before OAM becomes fully operational(9). As soon as you receive one frame from the peer you know their basic info (there is a multi-frame exchange required for initialization). So I believe the statement is correct as is. dot3OamPeerMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The MAC address of the peer OAM entity. The MAC address is derived from the most recently received OAMPDU. This value is initialized to all zeros (0x000000000000). This value is invalid if the dot3OamPeerStatus is inactive. ]] This seems pretty convoluted. Why not say "The MAC address ]] of the peer OAM entity. The MAC address is ]] derived from the most recently received valid OAMPDU. ]] The value is all zeros (0x000000000000) when the peer's ]] MAC address unknown, such as when the value of ]] dot3OamPeerStatus is 'inactive(2)'." ]] ]] By the way, it seems like a value could be obtained ]] even when dot3OamPeerStatus is 'inactive(2)'. ]] If so, is it useful? MBS; I didn't see any use, hence the current indications that its garbage if 'inactive'. Related to your general comment of simplification, I'll change the description to indicate zeros are returned whenever the dot3OamPeerStatus is inactive(2). An OAMPDU is indicated by a valid frame with (1) destination MAC address equal to that of the reserved MAC address for Slow Protocols (See 43B of [802.3ah]), (2) a lengthOrType field equal to the reserved type for Slow Protocols, (3) and a Slow Protocols subtype equal to that of the subtype reserved for OAM. " ]] Not sure this is needed in this definition. MBS; I don't mind removing it - in fact I prefer to. It was added because I was asked to specfically define what causes this value to change. The event that causes an update to this value is the reception of an OAMPDU, which is defined as above. I'm thrilled to be allowed to kill it. REFERENCE "[802.3ah], 30.3.6.1.5." ::= { dot3OamPeerEntry 2 } dot3OamPeerVendorOui OBJECT-TYPE SYNTAX Dot3Oui MAX-ACCESS read-only STATUS current DESCRIPTION "The OUI of the OAM peer as reflected in the latest Information OAMPDU received with a Local Information TLV. The OUI can be used to identify the vendor of the remote OAM entity. This value is initialized to all zeros (0x000000). This value is considered invalid if the dot3OamPeerStatus is inactive. ]] Can this be written to be simpler (see above) MBS; Simplification will be attempted in next revision. REFERENCE "[802.3ah], 30.3.6.1.16." ::= { dot3OamPeerEntry 3 } dot3OamPeerVendorInfo OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Vendor Info of the OAM peer as reflected in the latest Information OAMPDU received with a Local Information TLV. The vendor information field is within the Local Information TLV, and can be used to determine additional information about the peer entity. The format of the vendor information is unspecified within the 32-bit field. This value is intialized ]] spelling error^^^^^^^^^ MBS: fixed. to all zeros (0x00000000). This value is invalid if the dot3OamPeerStatus is inactive. ]] Can this be written to be simpler (see above) ]] Also, the 802.3af spec is confusing to me. From ]] it, the value seems like it should have ]] SYNTAX clause value of OCTET STRING(SIZE(4)). ]] But maybe an "Unsigned32" value is OK. If so, ]] the 0x00000000 is very strange. It should just be 0. MBS: I left this as Unsigned32 as its just a 32-bit field, non-formatted field. But I switched to 0 instead of 0x00000000. REFERENCE "[802.3ah], 30.3.6.1.17." ::= { dot3OamPeerEntry 4 } << Text deleted >> ------------------------------------------------------------------ -- M. Squire Expires - September 2005 [Page 19] EFM OAM MIB March 2005 -- Ethernet OAM Loopback group -- dot3OamLoopbackTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamLoopbackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains methods to control the loopback state of the local link as well as indicating the status of the loopback function. Loopback can be used to place the remote OAM entity in a state where every received frame (except OAMPDUs) are echoed back over the same interface on which they were received. In this state, at the remote entity, 'normal' traffic is disabled as only the looped back frames are transmitted on the interface. Loopback is thus an intrusive operation that prohibits normal data flow and should be used accordingly. " ::= { dot3OamMIB 3 } ]] See global comment about tables, and comment on table ]] dot3OamPeerTable. MBS: done ]] This table is used to put the remote end in loopback ]] and report the loopback status of the local and remote ]] ports ]] I'm confused as to whether both local and remote ports ]] can be put in loopback. And if not, then what happens ]] if the peer has put the local port in loopback and ]] an attempt is made to put the peer's port (the remote ]] port) in loopback? MBS: Simultaneous loopback on both ends is not possible - the protocol detects such an action and an election algorithm is used to determine which port enters loopback state and which does not. dot3OamLoopbackEntry OBJECT-TYPE SYNTAX Dot3OamLoopbackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information on the loopback status for a single Ethernet like interface. There is an entry in this table for every Ethernet like interface on which supports OAM and loopback function within OAM (as indicated in dot3OamFunctionsSupported). " ]] See previous comments on rows MBS: Changed to indicated automatic creation and conditions. INDEX { ifIndex } ::= { dot3OamLoopbackTable 1 } Dot3OamLoopbackEntry ::= SEQUENCE { dot3OamLoopbackCommand INTEGER, dot3OamLoopbackStatus INTEGER, dot3OamLoopbackIgnoreRx INTEGER } dot3OamLoopbackCommand OBJECT-TYPE SYNTAX INTEGER { noLoopback (1), startRemoteLoopback (2), stopRemoteLoopback (3) } MAX-ACCESS read-write M. Squire Expires - September 2005 [Page 20] EFM OAM MIB March 2005 STATUS current DESCRIPTION "This attribute initiates or terminates remote loopback with an OAM peer. Writing startRemoteLoopback(2) to this attribute cause the local OAM client to send a loopback OAMPDU to the OAM peer with the loopback enable flags set. Writing stopRemoteLoopback(3) to this attribute will cause the local OAM client to send a loopback OAMPDU to the OAM peer with the loopback enable flags cleared. Writing noLoopback to this attribute has no effect. Writes to this attribute are ignored unless the OAM status of this interface is 'operational' (dot3OamOperStatus). The attribute always returns noLoopback on a read. To determine the loopback status, use the attribute dot3OamLoopbackStatus. " REFERENCE "[802.3ah], 57.2.11" ::= { dot3OamLoopbackEntry 1 } ]] This object and the next need to be combined into a ]] action/status object. ]] The combined object support all the enum values ]] for dot3OamLoopbackStatus (which would be read-only) ]] and startRemoteLoopback and stopRemoteLoopback ]] from this object. Writes of startRemoteLoopback ]] when remote is already loopbacked (or dot3OamOperStatus ]] is not operational) cause no operation. ]] Likewise, writes of stopRemoteLoopback when remote ]] is not loopbacked (or dot3OamOperStatus ]] is not operational) cause no operation. ]] Note: just don't know what happens when ]] current value is localLoopback. MBS: I can change it, but I'd like to be pointed to an example. All of the examples I've come across had two objects, one for the actions, one for the status, which is where this model comes from. During discussion with the group, two objects were suggested as the desired approach. << Text deleted >> ------------------------------------------------------------------ M. Squire Expires - September 2005 [Page 22] EFM OAM MIB March 2005 -- -- Ethernet OAM Statistics group -- dot3OamStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for the OAM function on a particular Ethernet like interface." ::= { dot3OamMIB 4 } ]] See previous comments on tables. MBS: Done ]] Add a note in the commentary section as to why the counters ]] in this table are Counter32 instead of Counter64! MBS: Done. The size of the counters was selected to match the size of the counters as defined in 802.3. << Text deleted >> dot3OamUnsupportedCodesTx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of OAMPDUs transmitted on this interface with an unsupported op-code. ]] This is very strange. ]] Why would you send an "unsupported code"? ]] How would you know that you sent an "unsupported code"? MBS: Granted it seems a little strange. The variable is supported in the 802.3ah standard, so I decided to expose it via the MIB. Since Ethernet OAM could be supported in the HW or in the SW, the thought was someone might try to do things where the underlying layer doesn't support that thing (for example, loopback), and you might want to know about it. << Text deleted >. dot3OamFramesLostDueToOam OBJECT-TYPE ]] Strange descriptor. How about "dot3OamDroppedTxFrames" MBS: I'm trying to match the names in 802.3ah as closely as possible to make the implmeentaiton easier. In 802.3, its called FramesLostDueToOam. The reason its not "OamDroppedTxFrames" is because that might sound like OAM frames are dropped, when really any frame might be dropped because OAM took precedence. SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of frames that were dropped by the OAM multiplexer. Since the OAM mulitplexer has multiple inputs and a single output, there may be cases where frames are dropped due to transmit resource contention. This counter is incremented whenever a frame is dropped by the OAM layer. When this counter is incremented, no other counters in this MIB are incremented. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.46." ::= { dot3OamStatsEntry 17 } ------------------------------------------------------------------ -- -- Ethernet OAM Event Configuration group -- << Text deleted >> dot3OamErrSymPeriodWindowHi OBJECT-TYPE ]] This needs to be combined with the next object ]] and given syntax CounterBasedGauge64 MBS: This was discussed on the list. The discussion said that CounterBasedGauge64 is read-only and since this is a writable value, it wouldn't apply. << Text deleted >> dot3OamErrFrameWindow OBJECT-TYPE SYNTAX Unsigned32 UNITS "tenths of a second" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time (in 100ms increments) over which the ]] why not just say "in tenth of a second intervals" instead ]] of "in 100ms intervals" MBS: 100ms seems easier to say then "tenths of a second" threshold is defined. The default value is 10 (1 second). If dot3OamErrFrameThreshold frame errors occur within a window of dot3OamErrFrameWindow seconds (measured in tenths of seconds), an Event Notification OAMPDU should be generated with an Errored Frame Event TLV indicating the threshold has been crossed in this window. " REFERENCE "[802.3ah], 30.3.6.1.36" ::= { dot3OamEventConfigEntry 9 } M. Squire Expires - September 2005 [Page 37] EFM OAM MIB March 2005 dot3OamErrFrameThreshold OBJECT-TYPE SYNTAX Unsigned32 ]] What happens when the value is zero? MBS: This would result in an event notification being sent at the end of every measuring period. So if the window were 30sec, you'd get an OAMPDU every 30s saying how many errored frame there were. Some may consider this useless,but others thought it a way to get regular periodic updtes on these error counters (e.g. tell me what the values are every 30s). << Text deleted >> ------------------------------------------------------------------ -- -- Ethernet OAM Event Status group -- dot3OamEventLogTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamEventLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION ]] See comments on tables ]] On this table, can it have an infinite number of entries? ]] Most likely not. In other tables, there is some indication ]] that says the max number (not always available), but ]] always something that says to either stop adding entries, ]] or delete the oldest, or some other algorithm to replace ]] the least important with a new one. MBS: Added words to say that size is implemetnation dependent, and that older entries should be automtically deleted to make room for newer entries. "This table records a history of the events that have occurred at the Ethernet OAM level. These events can include locally detected events, which may result in locally generated OAMPDUs, and remotely detected events, which are detected by the OAM peer entity and signaled to the local entity via Ethernet OAM. Ethernet OAM events can be signaled by Event Notification OAMPDUs or by the flags field in any OAMPDU. " ]] Need to indicate that there are threshold crossing events ]] and nonthreshold events. For each, indicate the columns that ]] have meaningful values. The descriptions about the MAX values ]] didn't make sense until I read the descriptions of the ]] notifications and saw what was going on. MBS: Added words to say which columsn only apply to threshold crossing events. ::= { dot3OamMIB 6 } dot3OamEventLogEntry OBJECT-TYPE SYNTAX Dot3OamEventLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot3OamEventLogTable." ]] See previous comments on rows. MBS: Done. ]] Can selected entries in this table be deleted by ]] management operations? MBS: The thought was no,that the table reflects what happened (to the extent that it can). INDEX { ifIndex, dot3OamEventLogIndex } ::= { dot3OamEventLogTable 1 } << Text deleted >> dot3OamEventLogType OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The type of event that generated this entry in the event log. When the OUI is the IEEE 802.3 OUI of 0x0180C2, the following event types are defined: erroredSymbolEvent(1), erroredFramePeriodEvent (2), erroredFrameEvent(3), erroredFrameSecondsEvent(4), linkFault(256), dyingGaspEvent(257), criticalLinkEvent(258) The first four are considered threshold crossing events as they are generated when a metric exceeds a given value within a specified window. The other three are not threshold crossing events. When the OUI is not 0x0180C2, then some other organization has defined the event space. If event subtyping is known to the implementation, it may be reflected here. Otherwise, this value should return all Fs (0xFFFFFFFF). " ]] If this is an Unsigned32, then say this in numeric ]] terms and not in terminology used for octet strings. MBS: added decimal value in addition to all Fs. REFERENCE "[802.3ah], 30.3.6.1.10 and 57.5.3." ::= { dot3OamEventLogEntry 4 } << Text deleted >> ]] I'm not sure that I understand the objects ]] dot3OamEventLogRunningTotal and ]] dot3OamEventLogEventTotal. It ]] seems like dot3OamEventLogRunningTotal is the ]] value of a counter that is being thresholded, ]] and dot3OamEventLogEventTotal is the count of ]] the event crossings. ]] These counts seem possibly expensive to do. ]] Ok - after reading 802.3af, I see what is going on. ]] The descriptions below are really difficult to ]] understand. They need a rewrite. MBS: Rewrite will be attempted. << Text deleted >> ------------------------------------------------------------------ -- -- Ethernet OAM Notifications -- dot3OamNotifs OBJECT IDENTIFIER ::= { dot3OamMIB 7 } dot3OamNotifsPrefix OBJECT IDENTIFIER ::= {dot3OamNotifs 0} ]] remove these, and update OID values for notifications MBS: I will delete these and replace the dot3OamNotifsPrefix in the object below with dot3OamNotifications that you added earlier in the MIB. << Text deleted >> ------------------------------------------------------------------ -- -- Ethernet OAM Compliance group -- dot3OamGroups OBJECT IDENTIFIER ::= { dot3OamConformance 1 } dot3OamCompliances OBJECT IDENTIFIER ::= { dot3OamConformance 2 } -- Compliance statements dot3OamCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for managed entities M. Squire Expires - September 2005 [Page 46] EFM OAM MIB March 2005 supporting OAM on Ethernet like interfaces. " MODULE -- this module MANDATORY-GROUPS { dot3OamControlGroup, dot3OamPeerGroup, dot3OamStatsBaseGroup } GROUP dot3OamLoopbackGroup DESCRIPTION "This group is mandatory for all IEEE 802.3 OAM implementations that support loopback functionality. " GROUP dot3OamErrSymbolPeriodEventGroup DESCRIPTION "This group is mandatory for all IEEE 802.3 OAM implementations that support event functionality. " GROUP dot3OamErrFramePeriodEventGroup DESCRIPTION "This group is mandatory for all IEEE 802.3 OAM implementations that support event functionality. " GROUP dot3OamErrFrameEventGroup DESCRIPTION "This group is mandatory for all IEEE 802.3 OAM implementations that support event functionality. " GROUP dot3OamErrFrameSecsSummaryEventGroup DESCRIPTION "This group is mandatory for all IEEE 802.3 OAM implementations that support event functionality. " GROUP dot3OamFlagEventGroup DESCRIPTION "This group is optional for all IEEE 802.3 OAM implementations. The ability to send critical events or dying gasp events is not required in any system." GROUP dot3OamEventLogGroup DESCRIPTION "This group is optional for all IEEE 802.3 OAM implementations. " ]] There will not be any local events in the log table ]] unless some of the event groups are implemented. MBS: Correct. Is that a question or are you suggesting some action? GROUP dot3OamNotificationGroup DESCRIPTION "This group is optional for all IEEE 802.3 OAM M. Squire Expires - September 2005 [Page 47] EFM OAM MIB March 2005 implementations. " ]] This group requires implementation of the log table, ]] since the objects in the notifications are objects ]] in the log table! MBS: I'm not sure what to do here, will have to think about it. ::= { dot3OamCompliances 1} The way this module compliance is written, there are a couple of unconditionally optional items (like the notifications and logging). Also, there can be mix and match of optional items. This is bad for IETF standards track progression. You might consider having two module compliance specifications - a minimal and maximal. Others, like Bert, and provide better advice as to the best practices in IETF standards track MIB modules. dot3OamControlGroup OBJECT-GROUP OBJECTS { dot3OamAdminState, dot3OamOperStatus, dot3OamMode, dot3OamMaxOamPduSize, dot3OamConfigRevision, dot3OamFunctionsSupported } STATUS current DESCRIPTION "A collection of objects providing the abilities, configuration, and status of an Ethernet OAM entity. " ::= { dot3OamGroups 1 } dot3OamPeerGroup OBJECT-GROUP OBJECTS { dot3OamPeerStatus, dot3OamPeerMacAddress, dot3OamPeerVendorOui, dot3OamPeerVendorInfo, dot3OamPeerMode, dot3OamPeerFunctionsSupported, dot3OamPeerMaxOamPduSize, dot3OamPeerConfigRevision } STATUS current DESCRIPTION "A collection of objects providing the abilities, configuration, and status of a peer Ethernet OAM entity. " ::= { dot3OamGroups 2 } dot3OamStatsBaseGroup OBJECT-GROUP OBJECTS { dot3OamInformationTx, dot3OamInformationRx, dot3OamUniqueEventNotificationTx, dot3OamUniqueEventNotificationRx, dot3OamDuplicateEventNotificationTx, dot3OamDuplicateEventNotificationRx, dot3OamLoopbackControlTx, dot3OamLoopbackControlRx, dot3OamVariableRequestTx, dot3OamVariableRequestRx, dot3OamVariableResponseTx, dot3OamVariableResponseRx, dot3OamOrgSpecificTx, M. Squire Expires - September 2005 [Page 48] EFM OAM MIB March 2005 dot3OamOrgSpecificRx, dot3OamUnsupportedCodesTx, dot3OamUnsupportedCodesRx, dot3OamFramesLostDueToOam } STATUS current DESCRIPTION "A collection of objects providing the statistics for the number of various transmit and recieve events for OAM on an Ethernet like interface. Note that all of these counters must be supported even if the related function (as described in dot3OamFunctionsSupported) is not supported. " ::= { dot3OamGroups 3 } ]] The compliance is not specified in group definitions. MBS: Its one of the mandatory groups - what else are you looking for. dot3OamLoopbackGroup OBJECT-GROUP OBJECTS { dot3OamLoopbackCommand, dot3OamLoopbackStatus, dot3OamLoopbackIgnoreRx } STATUS current DESCRIPTION "A collection of objects for controlling the OAM remote loopback function. " ::= { dot3OamGroups 4 } dot3OamErrSymbolPeriodEventGroup OBJECT-GROUP OBJECTS { dot3OamErrSymPeriodWindowHi, dot3OamErrSymPeriodWindowLo, dot3OamErrSymPeriodThresholdHi, dot3OamErrSymPeriodThresholdLo, dot3OamErrSymPeriodEvNotifEnable } STATUS current DESCRIPTION "A collection of objects for configuring the thresholds for an Errored Symbol Period Event. Each [802.3ah] defined Event Notification TLV has its own conformance group because each event can be implemented independently of any other. " ::= { dot3OamGroups 5 } dot3OamErrFramePeriodEventGroup OBJECT-GROUP OBJECTS { dot3OamErrFramePeriodWindow, dot3OamErrFramePeriodThreshold, dot3OamErrFramePeriodEvNotifEnable } STATUS current DESCRIPTION M. Squire Expires - September 2005 [Page 49] EFM OAM MIB March 2005 "A collection of objects for configuring the thresholds for an Errored Frame Period Event. Each [802.3ah] defined Event Notification TLV has its own conformance group because each event can be implemented independently of any other. " ::= { dot3OamGroups 6 } dot3OamErrFrameEventGroup OBJECT-GROUP OBJECTS { dot3OamErrFrameWindow, dot3OamErrFrameThreshold, dot3OamErrFrameEvNotifEnable } STATUS current DESCRIPTION "A collection of objects for configuring the thresholds for an Errored Frame Event. Each [802.3ah] defined Event Notification TLV has its own conformance group because each event can be implemented independently of any other. " ::= { dot3OamGroups 7 } ]] Put this info about 802.3af in the commentary section MBS: Which section are you refering to exactly? dot3OamErrFrameSecsSummaryEventGroup OBJECT-GROUP OBJECTS { dot3OamErrFrameSecsSummaryWindow, dot3OamErrFrameSecsSummaryThreshold, dot3OamErrFrameSecsEvNotifEnable } STATUS current DESCRIPTION "A collection of objects for configuring the thresholds for an Errored Frame Seconds Summary Event. Each [802.3ah] defined Event Notification TLV has its own conformance group because each event can be implemented independently of any other. " ::= { dot3OamGroups 8 } dot3OamFlagEventGroup OBJECT-GROUP OBJECTS { dot3OamDyingGaspEnable, dot3OamCriticalEventEnable } STATUS current DESCRIPTION "A collection of objects for configuring the sending OAMPDUs with the critical event flag or dying gasp flag enabled. " ::= { dot3OamGroups 9 } dot3OamEventLogGroup OBJECT-GROUP M. Squire Expires - September 2005 [Page 50] EFM OAM MIB March 2005 OBJECTS { dot3OamEventLogTimestamp, dot3OamEventLogOui, dot3OamEventLogType, dot3OamEventLogLocation, dot3OamEventLogWindowHi, dot3OamEventLogWindowLo, dot3OamEventLogThresholdHi, dot3OamEventLogThresholdLo, dot3OamEventLogValue, dot3OamEventLogRunningTotal, dot3OamEventLogEventTotal } STATUS current DESCRIPTION "A collection of objects for configuring the thresholds for an Errored Frame Seconds Summary Event and maintaining the event information. " ::= { dot3OamGroups 10 } dot3OamNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { dot3OamThresholdEvent, dot3OamNonThresholdEvent } STATUS current DESCRIPTION "A collection of notifications used by Ethernet OAM to signal to a management entity that local or remote events have occured on a specified Ethernet link." ::= { dot3OamGroups 11 } END _____ From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, November 29, 2005 7:11 AM To: Matt Squire; Lior khermosh Cc: David T. Perkins; Hub MIB Subject: Resolution to comments from David Perkins Matt, Lior, a.k.a. Hub-MIB Editors When will you be able to address the comments submitted by David Perkins in his review and propose resolutions? Please do it on the WG list, so that the proposals for resolution is open for discussion. Thanks and Regards, Dan
_______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib
- [Hubmib] Resolution to comments from David Perkins Romascanu, Dan (Dan)
- [Hubmib] RE: Resolution to comments from David Pe… Lior Khermosh
- [Hubmib] RE: Resolution to comments from David Pe… Romascanu, Dan (Dan)
- [Hubmib] RE: Resolution to comments from David Pe… Matt Squire