Subject: [Hubmib] RE: Resolution to comments from David Perkins

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 11 Jan 2006 03:56:26 +0200

Thanks Matt, for addressing Dave's comments. 
 
Dave, can you please look at the responses submitted by Lior and Matt to
your comments and let us know if your principal concerns have been
answered? We would like to issue revised versions of the I-Ds, but it
would be useful to make sure that the issues that you raised found an
appropriate resolutions. 
 
Thanks and Regards,
 
Dan

  _____  

	From: Matt Squire [mailto:[email-masked]] 
	Sent: Wednesday, January 11, 2006 3:43 AM
	To: Romascanu, Dan (Dan); Lior khermosh
	Cc: David T. Perkins; Hub MIB
	Subject: RE: Resolution to comments from David Perkins

	Hi David, Dan  - 

	Below are my responses to the various comments.  

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

---

From: "Matt Squire" <[email-masked]>
Date: Tue, 10 Jan 2006 20:43:15 -0500

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, [email-masked]

]]

]] 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: [email-masked] 

           To Subscribe: [email-masked] 

           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:[email-masked]] 
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