[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Review of EFM-04 I-D (fwd)
Well, when we did the RowStatus TC, we did not have much experience
with it. Besides, it is a TC and not an object, which is what I am
talking about here.
I agree that maybe MODULE-COMPLIANCE is not the ideal place to state
these types of things, but I think it is (to my knowledge) the only
way how we can specify that only a few values are writable at all.
For an object that uses SYNTAX RowStatus, it might (in my view) be good to
always use an OBJECT clause in the MODULE compliance to show which
values are qiretable and which are readable. I.e. for an unrestricted
or unlimited RowStatus object one would have something aka:
OBJECT someObjec
WRITE-SYNTAX RowSTatus {
active(1),
notInService(2),
createAndGo(4),
createAndWait(5),
destroy(6)
}
SYNTAX Rowstatus {
active(1),
notInService(2),
notReady(3)
}
Oh well.. this would make the valid values for read or write machine readable.
I am not hung up on this though.
bert
> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Thursday, May 11, 2006 17:51
> To: Wijnen, Bert (Bert)
> Cc: mreview@ops.ietf.org
> Subject: RE: Review of EFM-04 I-D (fwd)
>
>
> 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
> > >
> > >
> > >
> > >
> > >
> >
>