Subject: [Hubmib] Response to comments on OAM doc

From: "David T. Perkins" <[email-masked]>
Date: Fri, 20 Jan 2006 16:28:26 -0800 (PST)

HI,

It looks like much progress, and maybe with the comments
below incorroprated, the document will be ready for
a new WG last call and IESG submission.

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

Response to OAM comments (email from Matt Squire on 10-jan-2006) -
dtp:20-jan-2006 
-------------------------------------------------------------
Responses are prefixed by %%. For example:
%% This is an example
-------------------------------------------------------------
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).  

%% Yes, I suggest the following:
%%  DOT3-OAM-MIB for the module name, and
%%  dot3OamMIB for the descriptor of the MODULE-IDENTITY definition
%% I believe that the prefix of the descriptors used throughout
%% the -03 document are "dot3Oam", so no change needed for them. 

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. 

%% The question is whether the text is useful or distracting, or
%% even confusing.
%% I suggest that OAM PDU be defined in the explanatory text
%% (the text before the MIB module) with a reference to the
%% section in the appropriate IEEE document. And also duplicate
%% that definition an put it in the DESCRIPTION clause of
%% the MODULE-IDENTITY. Then, just say "OAM PDU" without
%% defining what is an OAM PDU.

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, 

%% Here is a summary of my suggestion:
%% Table dot3OamTable - entries are in this table if OAM is
%%     supported on this dot3 interface. These entries
%%     are not added or deleted via SNMP operations, but
%%     and present if the OAM function is supported.
%%  (NOTE: on rereading the DESCRIPTION of object dot3OamConfigRevision,
%%         I was confused. Shouldn't the description simply be
%%           "The local value of the OAM configuration revision."
%%         I don't understand the reference to local_statisfied
%%         in 802.3ah 57.3.1.2. Also, can there be different
%%         versions on different interfaces? And given that
%%         the GMDO attribute is aOAMLocalRevision, why not
%%         call this dot3OamLocalConfigRevision?)
%% Table dot3OamPeerTable - presently, an entry is in this table
%%         for each entry in table dot3OamTable, and object
%%         dot3OamPeerStatus indicates if the values of other
%%         columns in the table are "valid". The point that I
%%         was making was to either a) remove object dot3OamPeerStatus
%%         and only put rows in the table that have "valid values",
%%         or b) define values that should be returned when
%%         the value of object dot3OamPeerStatus is 'inactive(2)'.
%% Table dot3OamLoopbackTable - an entry exists in this table
%%         for each entry in table dot3OamTable where object
%%         dot3OamFunctionsSupported has bit 'loopbackSupported(1)'
%%         with value 1. 
%%         NOTE: what happens if a loopback is started, and then
%%         the value of dot3OamOperStatus changes to some value
%%         from 'operational(9)', and then cycles back to 
%%         'operational(9)'. Is the loopback lost?
%% Table dot3OamStatsTable - an entry exists in this table
%%         for each entry in table dot3OamTable. The counts
%%         are not "reset" due to changes in dot3OamOperStatus.
%% Table dot3EventConfigTable -  an entry exists in this table
%%         for each entry in table dot3OamTable where object
%%         dot3OamFunctionsSupported has bit ??
%%         with value 1. The values are not affected by 
%%         changes in dot3OamOperStatus or dot3OamAdminStatus.
%% Table dot3OamEventLogTable - an entry exists in this table
%%         for each event that has occurred up to the max
%%         supported by the implementation. When the implementation
%%         max is present, the addition of a new event result in
%%         the deletion of one or more of the oldest events. The
%%         value of the index object dot3OamEvetLogIndex increase
%%         in value for each new entry, and when the max is reached
%%         then the value restarts at zero. 

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

%% (I'm going to ignore the potential "degraded operation" while
%% in half-duplex.)
%% I just don't like the sentence "Note that the value is
%% ignored..."
%% Let's back up. I believe that an implementation will choose
%% which dot3 interfaces that it will support the OAM function.
%% A management app will be able to read the instances in table
%% dot3OamTable to determine this. Some dot3 interfaces will
%% support negotiation, and if the peer negotiates half-duplex,
%% then the OAM function will not operate. Likewise, if there
%% is no peer attached or the peer's interface is down the
%% OAM function will not operate. Likewise, if the peer doesn't
%% support the OAM function (it may not have code, or it may
%% be administratively disabled), the OAM function will not
%% operate.
%% Thus, I'm suggesting that you remove the sentence, and
%% add a new value for dot3OperStatus, such as
%% 'nonOperInHalfDuplex()', which would be returned
%% if dot3OamAdminState is 'enabled(2)', and the link is
%% in half duplex mode.
%% Also, dot3OperStatus needs a value when ifAdminStatus
%% is 'down(2)' or 'testing(3)', and when ifOperStatus
%% has a value other than 'up(1)'.

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.   
%% Having one object or two is somewhat subjective. There are
%% plenty of examples of action/status objects. For example,
%% all RowStatus objects are action/status objects. Here are
%% the enum values from RFC 2579:
%%    -- the following two values are states:
%%    -- these values may be read or written
%%    active(1),
%%    notInService(2),
%%
%%    -- the following value is a state:
%%    -- this value may be read, but not written
%%    notReady(3),
%%
%%    -- the following three values are
%%    -- actions: these values may be written,
%%    --   but are never read
%%    createAndGo(4),
%%    createAndWait(5),
%%    destroy(6)

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'm checking into options.

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?  

%% See above.

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]

%% The I-D is now RFC 4181

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 >>
%% I hope that you are changing this to the following:
%%   Definitions of Managed Objects for OAM Functions for
%%   Ethernet-Like Interfaces 

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

%% Please drop the MIB-2 [RFC1213] reference, since it is obsoleted
%% or updated by other documents. 

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.  

  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.  
  
%% I don't believe that "EFM interface types" need any special
%% mention. The key point is that the OAM function can function
%% on any etherLike interface and (if I understand you correctly) 
%% any aggregated interface that uses an aggregation of etherLike
%% 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
%% See, for example section 5 in RFC 4188

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

  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.

  <<text deleted>>

     efmOamMIB MODULE-IDENTITY 

]] Not sure if should be efmOamMIB or dot3OamMIB

MBS: Changed to dot3OamMIB

   <<text deleted>>

       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].  
      "
%% looks good
 
<< 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 

%% Just to be sure, if an aggregation interface is created using
%% members that are etherLike, can the aggregation have OAM
%% applied, or is it only for the base links. For example,
%% I can create an aggregation interface from, say 4 1Gig Ethernet
%% interfaces. In this case is the aggregation interface
%% supported by OAM? 

     dot3OamEntry OBJECT-TYPE
       SYNTAX     Dot3OamEntry
       MAX-ACCESS not-accessible
       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.
%% Don't need a RowStatus column for this table. Just need to say
%% that entries are not created or deleted via SNMP operations.

     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.  
%% see above

     dot3OamOperStatus OBJECT-TYPE
       SYNTAX      INTEGER {
                     disabled(1),
                     linkfault(2),
                     passiveWait(3),
                     activeSendLocal(4),
                     sendLocalAndRemote(5),
                     sendLocalAndRemoteOk(6),
                     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.  
%% See above. Please state this in the DESCRIPTION. However
%% oper and admin work in the IETF management model is DIFFERENT
%% from the ITU module. Don't know the IEEE model.
%% In IETF oper "follows" admin. That is, when admin is down,
%% then oper is down. In ITU, oper is independent from admin.
%% That is, when admin is down (ITU calls this locked), then
%% oper is suppose to tell you if the interface can still
%% work, and would normally be "up".

<< 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"
%% octets please
       MAX-ACCESS  read-only
       STATUS      current 
       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
     --

     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.
%% see above.
%% You either have a one-to-one relationship with rows in the
%% control table (dot3OamTable) (and you have object dot3OamPeerStatus),
%% or you have a subset of the rows (and you don't need object
%% dot3OamPeerStatus).

     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
       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.  
%% Please add the above in the DESCRIPTION
 
     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.  

%% see above

       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

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

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

 <<text deleted>>

     dot3OamLoopbackCommand OBJECT-TYPE
       SYNTAX      INTEGER { 
                     noLoopback (1),
                     startRemoteLoopback (2),
                     stopRemoteLoopback (3)
                   } 
       MAX-ACCESS  read-write
       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 >>

     ------------------------------------------------------------------
     --
     -- 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.  
%% Does the other end tell you that you have sent an unsupported
%% op-code?

 << 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.  
%% I'm not sure I could figure that out the above. Why not put it
%% in the DESCRIPTION 
       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.  
%% Sorry, you are correct
 
<< 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 }

     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).  
%% so why not include that in the DESCRIPTION

 << 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.  
%% see above

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

%% The descriptions specify dependencies.   

       GROUP       dot3OamNotificationGroup
       DESCRIPTION 
         "This group is optional for all IEEE 802.3 OAM
         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.

<<text deleted>>

    dot3OamStatsBaseGroup OBJECT-GROUP
       OBJECTS     {   dot3OamInformationTx,
                       dot3OamInformationRx,
                       dot3OamUniqueEventNotificationTx,
                       dot3OamUniqueEventNotificationRx,
                       dot3OamDuplicateEventNotificationTx,
                       dot3OamDuplicateEventNotificationRx,
                       dot3OamLoopbackControlTx,
                       dot3OamLoopbackControlRx,
                       dot3OamVariableRequestTx,
                       dot3OamVariableRequestRx,
                       dot3OamVariableResponseTx,
                       dot3OamVariableResponseRx,
                       dot3OamOrgSpecificTx,
                       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. 
%% Oops, overlooked it, sorry.

<<text deleted>>

    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?  
%% Put it in the section before the MIB module, that describes
%% the organization of the objects in the MIB module.

<<text deleted>>

     END

Regards,
/david t. perkins

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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 22 Jan 2006 20:35:57 +0200

(speaking as a contributor) 

Grrrrr ... I did not want to enter into a naming discussion at this
stage, but it looks like we got into one anyway. 

There is no overall convention for names of hubmib MIB modules to be
prefixed by DOT3. If there is a consistency to be reached, I would
rather aim all EFM MIB module names to be prefixed by EFM. 

Thus, the module names I would recommend to be used in the four
documents are:

EFM-OAM-MIB 
EFM-CU-MIB
EFM-EPON-MIB
EFM-EPON-DEVICE-MIB

The descriptors associated with the module identity and the other
descriptors of MIB objects within the MIB modules should be a lower case
version of the module name prefix without hyphenation of course, as
recommended in Annex C of RFC 4181.

Regards,

Dan

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> 
> 6.   MIB Definition
>

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 22 Jan 2006 20:47:29 +0200

> Numerically, it should currently be 1518, not 1522.  

See RFC 4181, Section 4.6.1.1 for the reason of using Unsigned32.

Concerning the new max PDU size. It is true that IEEE 802.3as is working
at a frame extension that would take the max frame size to a new value,
around 2k I believe. We should be able to liaison with them and
determine if they already can tell us what is this value. 

However, my question is whether EFM OAM is supposed to use the new max
size. It was designed by the time a non-tagged frame was (actually still
is by today) 1518. Is there any text that says what the max size of a
OAM PDU can be - 1518, or the max size of the day?

Thanks,

Dan

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 22 Jan 2006 20:55:59 +0200

Thanks to David for reviewing the comments. It looks like we have
agreement on the majority of the items, and I would suggest that Matt
performs the necessary edits as soon as possible, so that we can submit
a revised version ready to go through a WGLC and then IESG submission.

Regards,

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David T. Perkins
> Sent: Saturday, January 21, 2006 2:28 AM
> To: [email-masked]
> Cc: Romascanu, Dan (Dan); [email-masked]
> Subject: [Hubmib] Response to comments on OAM doc
> 
> HI,
>

---

From: "Matt Squire" <[email-masked]>
Date: Mon, 23 Jan 2006 09:26:41 -0500

> OAM PDU can be - 1518, or the max size of the day?

The text in .3 says that the maximum size of an OAMPDU is the
maxUntaggedFrameSize (see Table 57-9).  As I think about it more, the
maximum size of an untagged frame is not changing, just the name.
According to the latest draft of 802.3as, Table 57-9 changes
maxUntaggedFrameSize to maxBasicFrameSize, which is still defined as
1518.  

I don't think a liaison is necessary - the 802.3as draft is pretty
clear.  

- Matt

---

From: "Matt Squire" <[email-masked]>
Date: Mon, 23 Jan 2006 09:32:07 -0500

I would personally prefer to have the OAM MIB name be DOT3 rather than
EFM, for two reasons:

1) The other non-PHY specific functions seem to be named this way.  
2) I already made the change in a working draft:)

Not a strong feeling by any means, but it seems more appropriate.  

- Matt

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Sunday, January 22, 2006 1:36 PM
> To: David T. Perkins; [email-masked]
> Cc: Matt Squire
> Subject: RE: Response to comments on OAM doc
>

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 23 Jan 2006 16:38:28 +0200

I have no stronger feelings either. Please go ahead as your non-strong
feelings dictate :-)

Regards,

Dan

> From: Matt Squire [mailto:[email-masked]] 
> Sent: Monday, January 23, 2006 4:32 PM
> To: Romascanu, Dan (Dan); David T. Perkins; [email-masked]
> I would personally prefer to have the OAM MIB name be DOT3 
> rather than EFM, for two reasons:
> 
> ]] 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.
> > >
> > >   <<text deleted>>
> > >