RE: Review of EFM-04 I-D

"Matt Squire" <[email protected]> Thu, 11 May 2006 13:41:47 -0400
Newsgroups gmane.ietf.hubmib
Message-ID <[email protected]>
Hi David - 

Thanks for the (re-)review.  Responses are in-line. 


> 
> Specific Comments:
> 1) The last paragraph of section 5 reads a little strange
>    to me. It seems more complex than needed. (Given that it
>    is an overview, it's Ok to leave as is. However, I suggest
>    that it be simplified to the following:
>    "There are two notifications defined to report Ethernet OAM
>    events and are contained in one conformance group."

As a recap for those that don't have the document in front of them, the
last paragraph says:

"There are also a set of notifications (dot3OamNotifications) that
define alert conditions to management.  The [802.3ah] Event
Notifications can each be implemented independently of any other, and
therefore each has their own conformance group. " 

And I agree that it's confusing.  I'd offer a slight alteration to your
proposal.

"There are two notifications defined to report Ethernet OAM events (one
for threshold crossing events, one for non-threshold crossing events).
Both notifications are contained in the same conformance group. "



> 
> 2) The TC Dot3Oui is defined in the module and has general
>    applicability to all IEEE 802 areas. It seems like this
>    should be defined elsewhere are imported into this module.
>    (This is a duplicate of the comment made in the previous
>     review, and I cannot remember the response.)

My response was that I theoretically agree, but I'm not sure how to
address it.  What MIB does it go in?  Who updates that MIB?  Do we wait
until it's updated?  

I'm just not sure what part falls on me, and what part falls on someone
else (and who that someone else would be).   

> 
> 3) Also, the TC Dot3Oui where used is specified as having
>    the value of zero. Either this should be changed to say
>    the value of 3 octets of zero, or the syntax of the
>    TC be modified to the following:
>      SYNTAX  OCTET STRING(SIZE(0 | 3))
>    I favor saying that the value is 3 octets of zero,
>    since a zero length value may break existing mgmt apps.
>    Note: objects dot3OamPeerVendorOui, and
>          dot3OamEventLogOui


Will do. 

> 
> 4) The syntax of object dot3OamMaxOamPduSize is specified
>     as "SYNTAX (0..1518)", but the text says values
>     1..63 are not allowed. So, why not
>     "SYNTAX (0 | 64..1518)

As has been discussed on the reflector and in private, there is a
difference in the syntax for dot3OamMaxOamPduSize and
dot3OamPeerMaxOamPduSize.  The former should be (64..1518) as the local
station knows its PDU size and it must be a value in the range 64-1518
octets.  The latter may have an unknown value (you may not have received
the value from the peer yet), and that is what the value of zero is for.
>From the Description of dot3OamPeerMaxOamPduSize:  

"A value of zero is returned if no Local Information TLV has been
received.  Otherwise, the value of the OAM peer's maximum OAMPDU size is
returned in this value.  Note that the values 1..63 are invalid sizes
for Ethernet frames and should never appear "

So (0 | 64..1518) is probably better then saying (0..1518) with 1..63 as
"should never appear".  So it's a good change to make.  

- Matt