RE: Review of EFM-04 I-D (fwd)

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

David, when I see something like this:
     dot3OamLoopbackStatus OBJECT-TYPE
       SYNTAX      INTEGER {
                     -- all values, except where noted, can be read
                     -- but cannot be written
                     noLoopback (1),

                     -- initiatingLoopback can be read or written
                     initiatingLoopback (2),
                     remoteLoopback (3),

                     -- terminatingLoopback can be read or written
                     terminatingLoopback (4),
                     localLoopback (5),
                     unknown (6)
                   }

Then I wonder if it would be wise to put in the MODULE-COMPLIANCE 
something aka 

   OBJECT dot3OamLoopbackStatus 
   WRITE-SYNTAX {  initiatingLoopback (2),
                   terminatingLoopback (4)
                }
   DESCRIPTION "Only these 2 values are writable. The other values are read-only
                values."

Do people agree that such would make sense?

Bert

> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of David T. Perkins
> Sent: Thursday, May 11, 2006 01:08
> To: mreview@ops.ietf.org
> Subject: Review of EFM-04 I-D (fwd)
> 
> 
> HI,
> 
> My review of the OAM MIB is below.
> 
> It includes the TC Dot3Oui, which is general
> in applicability. 
> Is there such a TC already defined? If not,
> should this go in the collection of IEEE TCs?
> 
> Regards,
> /david t. perkins
> 
> ---------- Forwarded message ----------
> Date: Wed, 10 May 2006 16:03:26 -0700 (PDT)
> From: David T. Perkins <dperkins@dsperkins.com>
> To: hubmib@ietf.org
> Cc: msquire@hatterasnetworks.com, dromasca@avaya.com
> Subject: Review of EFM-04 I-D
> 
> HI,
> 
> I finished reviewing I-D draft-ietf-hubmib-efm-mib-04.txt.
> My notes are below.
> 
> General comments:
>  The updated document looks very clean. 
>  It runs through both SMICng and smilint with no problems.
>  I read through the document fairly quickly, and didn't
>  try to verify all the references to other documents.
>  (Even if there are a typo or two, a reader should be
>  able to sort this out.)
> 
> 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."
> 
> 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.)
>     
> 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
>          
> 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)
> 
> In summary, great job Matt and others that worked on the
> document.
> 
> Regards,
> /david t. perkins
> 
> 
> 
> 
>