RE: [Hubmib] Working Group Last Call

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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)=3D=3D1,

]] 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 &n= bsp; &nb= sp; Matt = Squire

= Document: draft-ietf-hubmib-efm-mib-03.txt = ; Hatteras Networks

= Expires: September 2005 &nb= sp; &nbs= p; March, 2005

&n= bsp; 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 <=3D N <=3D 32) physical layers into a single = Ethernet

interface.

M. Squire Expires - September 2005 = [Page 5]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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]

]] 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]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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 ::=3D 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:

&n= bsp; http://www.ietf.org/html.charters/hubmib-charter.html =

Mailing lists:

M. Squire Expires - September 2005 = [Page 8]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; March 2005

&n= bsp; General Discussion: hubmib@ietf.org

&n= bsp; To Subscribe: hubmib-requests@ietf.org

&n= bsp; In Body: subscribe your_email_address

Chair: = Dan Romascanu, Avaya

&n= bsp; Tel: +972-3-645-8414

&n= bsp; Email: = dromasca at avaya dot com

Editor: Matt Squire =

&n= bsp; Hatteras Networks

&n= bsp; Tel: +1-919-991-5460

&n= bsp; Fax: +1-919-991-0743

&n= bsp; 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]." =

::=3D { 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]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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 = }

::=3D { 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 ::=3D

SEQUENCE {

dot3OamAdminState &n= bsp; &nb= sp; INTEGER,

dot3OamOperStatus &n= bsp; INTEGER,

dot3OamMode &n= bsp; &nb= sp; INTEGER,

dot3OamMaxOamPduSize = ; Integer32,

dot3OamConfigRevision &nbs= p; Unsigned32,

dot3OamFunctionsSupported = BITS

}

&n= bsp;

dot3OamAdminState OBJECT-TYPE

SYNTAX INTEGER = {

&n= bsp; disabled(1),

&n= bsp; enabled(2)

&n= bsp; }

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"

::=3D { 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 = {

&n= bsp; disabled(1),

&n= bsp; linkfault(2),

&n= bsp; passiveWait(3),

&n= bsp; activeSendLocal(4),<= /span>

&n= bsp; sendLocalAndRemote(5),

&n= bsp; sendLocalAndRemoteOk(6),

M. Squire Expires - September 2005 = [Page 11]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; March 2005

= &= nbsp; oamPeeringLocallyRejected(7),

&n= bsp; oamPeeringRemotelyRejected(8),

&n= bsp; operational(9)

&n= bsp; }

]] 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"<= /p>

MAX-ACCESS read-only

STATUS current =

M. Squire Expires - September 2005 = [Page 13]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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"

::=3D { dot3OamEntry 4 }

&n= bsp;

<< Text deleted >>

------------------------------------------------------------------

-- Ethernet OAM Peer group

M. Squire Expires - September 2005 = [Page 14]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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. " =

::=3D { 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 = }

::=3D { 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 ::=3D

SEQUENCE {

dot3OamPeerStatus &n= bsp; INTEGER,

dot3OamPeerMacAddress &nbs= p; MacAddress,

dot3OamPeerVendorOui = ; Dot3Oui,

dot3OamPeerVendorInfo &nbs= p; Unsigned32,

dot3OamPeerMode &nbs= p; INTEGER,

dot3OamPeerMaxOamPduSize &= nbsp; Integer32,

dot3OamPeerConfigRevision = Unsigned32,

dot3OamPeerFunctionsSupported = BITS

}

dot3OamPeerStatus OBJECT-TYPE

SYNTAX INTEGER = {

&n= bsp; active(1),

&n= bsp; inactive(2)

&n= bsp; }

MAX-ACCESS read-only

M. Squire Expires - September 2005 = [Page 15]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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. =

::=3D { 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." =

::=3D { 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."

::=3D { 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

]] = &= nbsp; &n= bsp; 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." =

::=3D { dot3OamPeerEntry 4 }

<< Text deleted >>

--------------------------------------------------------= ----------

M. Squire Expires - September 2005 = [Page 19]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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. " =

::=3D { 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 = }

::=3D { dot3OamLoopbackTable 1 }

Dot3OamLoopbackEntry ::=3D

SEQUENCE {

dot3OamLoopbackCommand &nb= sp; INTEGER,

dot3OamLoopbackStatus &nbs= p; INTEGER,

dot3OamLoopbackIgnoreRx &n= bsp; INTEGER

}

dot3OamLoopbackCommand OBJECT-TYPE

SYNTAX INTEGER { =

&n= bsp; noLoopback (1),

&n= bsp; startRemoteLoopback (2),

&n= bsp; stopRemoteLoopback (3)

&n= bsp; }

MAX-ACCESS read-write

M. Squire Expires - September 2005 = [Page 20]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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). =

&n= bsp; &nb= sp;

The attribute always returns noLoopback on a read. = To

determine the loopback status, use the = attribute

dot3OamLoopbackStatus. "

REFERENCE "[802.3ah], 57.2.11" =

::=3D { 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]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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."

::=3D { 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.

&n= bsp; &nb= sp;

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." =

::=3D { 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 >>

&n= bsp;

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). =

&n= bsp; &nb= sp;

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" =

::=3D { dot3OamEventConfigEntry 9 }

M. Squire Expires - September 2005 = [Page 37]

&n= bsp; &nb= sp; EFM OAM = MIB &nbs= p; 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. =

::=3D { 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 }

= ::=3D { 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:

&n= bsp; erroredSymbolEvent(1),

&n= bsp; erroredFramePeriodEvent (2),

&n= bsp; erroredFrameEvent(3),

&n= bsp; erroredFrameSecondsEvent(4),

&n= bsp; linkFault(256),

&n= bsp; dyingGaspEvent(257),

&n= bsp; 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."

::=3D { 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 ::=3D { dot3OamMIB 7 = }

dot3OamNotifsPrefix OBJECT IDENTIFIER ::=3D {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 ::=3D { dot3OamConformance 1 = }

dot3OamCompliances OBJECT IDENTIFIER ::=3D { dot3OamConformance 2 = }

-- Compliance statements

dot3OamCompliance MODULE-COMPLIANCE

STATUS = current

DESCRIPTION "The compliance statement for managed = entities

M. Squire Expires - September 2005 = [Page 46]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; March 2005

&n= bsp; supporting OAM on Ethernet like interfaces.

&n= bsp; "

MODULE -- this module

MANDATORY-GROUPS { dot3OamControlGroup,

&n= bsp; &nb= sp; dot3OamPeerGroup,

&n= bsp; &nb= sp; dot3OamStatsBaseGroup

&n= bsp; &nb= sp; }

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]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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. =

::=3D { 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,

&n= bsp; &nb= sp; dot3OamOperStatus,

&n= bsp; &nb= sp; dot3OamMode,

&n= bsp; &nb= sp; dot3OamMaxOamPduSize,

&n= bsp; &nb= sp; dot3OamConfigRevision,

&n= bsp; &nb= sp; dot3OamFunctionsSupported

&n= bsp; }

STATUS = current

DESCRIPTION

"A collection of objects providing the = abilities,

configuration, and status of an Ethernet OAM entity. = "

::=3D { dot3OamGroups 1 }

dot3OamPeerGroup OBJECT-GROUP

OBJECTS { = dot3OamPeerStatus,

&n= bsp; &nb= sp; dot3OamPeerMacAddress,

&n= bsp; &nb= sp; dot3OamPeerVendorOui,

&n= bsp; &nb= sp; dot3OamPeerVendorInfo,

&n= bsp; &nb= sp; dot3OamPeerMode,

&n= bsp; &nb= sp; dot3OamPeerFunctionsSupported,

&n= bsp; &nb= sp; dot3OamPeerMaxOamPduSize,

&n= bsp; &nb= sp; dot3OamPeerConfigRevision

&n= bsp; }

STATUS = current

DESCRIPTION

"A collection of objects providing the = abilities,

configuration, and status of a peer Ethernet OAM entity. = "

::=3D { dot3OamGroups 2 }

dot3OamStatsBaseGroup OBJECT-GROUP

OBJECTS { = dot3OamInformationTx,

&n= bsp; &nb= sp; dot3OamInformationRx,

&n= bsp; &nb= sp; dot3OamUniqueEventNotificationTx,

&n= bsp; &nb= sp; dot3OamUniqueEventNotificationRx,

&n= bsp; &nb= sp; dot3OamDuplicateEventNotificationTx,

&n= bsp; &nb= sp; dot3OamDuplicateEventNotificationRx,

&n= bsp; &nb= sp; dot3OamLoopbackControlTx,

&n= bsp; &nb= sp; dot3OamLoopbackControlRx,

&n= bsp; &nb= sp; dot3OamVariableRequestTx,

&n= bsp; &nb= sp; dot3OamVariableRequestRx,

&n= bsp; &nb= sp; dot3OamVariableResponseTx,

&n= bsp; &nb= sp; dot3OamVariableResponseRx,

&n= bsp; &nb= sp; dot3OamOrgSpecificTx,

M. Squire Expires - September 2005 = [Page 48]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; March 2005

&n= bsp; &nb= sp; dot3OamOrgSpecificRx,

&n= bsp; &nb= sp; dot3OamUnsupportedCodesTx,

&n= bsp; &nb= sp; dot3OamUnsupportedCodesRx,

&n= bsp; &nb= sp; dot3OamFramesLostDueToOam

&n= bsp; }

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. = "

::=3D { 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,

&n= bsp; &nb= sp; dot3OamLoopbackStatus,

&n= bsp; dot3OamLoopbackIgnoreRx

&n= bsp; }

STATUS = current

DESCRIPTION

"A collection of objects for controlling the OAM = remote

loopback function. "

::=3D { dot3OamGroups 4 }

dot3OamErrSymbolPeriodEventGroup = OBJECT-GROUP

OBJECTS { = dot3OamErrSymPeriodWindowHi,

&n= bsp; &nb= sp; dot3OamErrSymPeriodWindowLo,

&n= bsp; &nb= sp; dot3OamErrSymPeriodThresholdHi,

&n= bsp; &nb= sp; dot3OamErrSymPeriodThresholdLo,

&n= bsp; &nb= sp; dot3OamErrSymPeriodEvNotifEnable

&n= bsp; }

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. "

::=3D { dot3OamGroups 5 }

dot3OamErrFramePeriodEventGroup = OBJECT-GROUP

OBJECTS { = dot3OamErrFramePeriodWindow,

&n= bsp; &nb= sp; dot3OamErrFramePeriodThreshold,

&n= bsp; &nb= sp; dot3OamErrFramePeriodEvNotifEnable

&n= bsp; }

STATUS = current

DESCRIPTION

M. Squire = Expires - September 2005 = [Page 49]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; 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. "

::=3D { dot3OamGroups 6 }

dot3OamErrFrameEventGroup OBJECT-GROUP

OBJECTS { = dot3OamErrFrameWindow,

&n= bsp; &nb= sp; dot3OamErrFrameThreshold,

&n= bsp; &nb= sp; dot3OamErrFrameEvNotifEnable

&n= bsp; }

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. "

::=3D { 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,

&n= bsp; dot3OamErrFrameSecsSummaryThreshold,

&n= bsp; &nb= sp; dot3OamErrFrameSecsEvNotifEnable

&n= bsp; }

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. "

::=3D { dot3OamGroups 8 }

dot3OamFlagEventGroup OBJECT-GROUP

OBJECTS { = dot3OamDyingGaspEnable,

&n= bsp; &nb= sp; dot3OamCriticalEventEnable

&n= bsp; }

STATUS = current

DESCRIPTION

"A collection of objects for configuring the sending = OAMPDUs

with the critical event flag or dying gasp flag enabled. = "

::=3D { dot3OamGroups 9 }

dot3OamEventLogGroup OBJECT-GROUP

M. Squire Expires - September 2005 = [Page 50]

&n= bsp; &nb= sp; EFM OAM MIB &nbs= p; March 2005

OBJECTS { dot3OamEventLogTimestamp,

&n= bsp; dot3OamEventLogOui,

&n= bsp; dot3OamEventLogType,

&n= bsp; dot3OamEventLogLocation,

&n= bsp; dot3OamEventLogWindowHi,

&n= bsp; dot3OamEventLogWindowLo,<= /font>

&n= bsp; dot3OamEventLogThresholdHi,

&n= bsp; dot3OamEventLogThresholdLo,

&n= bsp; dot3OamEventLogValue,

&n= bsp; dot3OamEventLogRunningTotal,

&n= bsp; dot3OamEventLogEventTotal

&n= bsp; }

STATUS = current

DESCRIPTION

"A collection of objects for configuring the thresholds for = an

Errored Frame Seconds Summary Event and maintaining the = event

information. "

::=3D { dot3OamGroups 10 }

dot3OamNotificationGroup NOTIFICATION-GROUP

NOTIFICATIONS {

&n= bsp; dot3OamThresholdEvent,

&n= bsp; dot3OamNonThresholdEvent

&n= bsp; }

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."

::=3D { 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