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

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Well, consider RowStatus. It is also an "action-status"
object like the definition below. I don't believe
that a MODULE-COMPLIANCE specification is appropriate
to specify the semantics of object definitions.

By the way, my preference in the definition below
(and all others) is to put the text of the ASN.1
comments in the DESCRIPTION clause and write
up the DESCRIPTION to say that the object
is an "action-status", and separate the
values into a list of actions and status,
and dual purpose.

<soap>
It's way too late now, but over 10 years ago
I proposed that the syntax for ENUMs be modified
to indicate in parsable form the access for
each value, and description. I don't remember
the exact syntax, but maybe something like:
  SYNTAX ENUM {
     { act(1), wo, "an action value..." },
     { st(2), ro, "a status value..."},
     { actSt(3), rw, "an dual purpose action-status value..."}
  }
And of course, such an ENUM list could not be
modified in a revision of the definition.

This is to contrast with a "pure" enum list,
lets call it a named value list. For example:
   SYNTAX NAMEDVALUES {
      { red(1), "a description..." },
      { blue(2), "other description..."}
   }
Which could be updated in a revision of the definition.
</soap> 

On Thu, 11 May 2006, Wijnen, Bert (Bert) wrote:

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