[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Support for XXX OID value
HI,
Tools - I'm talking about smilint and SMICopen.
I'm thinking about a modification to the following....
> MIB parser not to generate an error message? For example,
> mymibparser MY-EXAMPLE-MIB
> might generate error
> E: f(MY-EXAMPLE-MIB), (74,21) Sub-Id for item "myExampleMIB"
> must be a "number" or "name(number)"
>
> But, with command line option, say, "--type=ID", such as:
> mymibparser --type=ID MY-EXAMPLE-MIB would not output an error
Something like:
mymibparser --type=ID --val=XXX:200606112 MY-EXAMPLE-MIB
which would result in "2006060112" being substituted
for "XXX" above.
The high level issue is how to increase the productivety
in work flow of creating and verifying MIB modules
(and especially those in I-Ds).
We had a little discussion of this last fall with DBH
putting together a template for I-Ds that include
MIB modules. Such work, I believe, is a great benefit
to the SNMP community.
On Wed, 26 Apr 2006, David B Harrington wrote:
> I concur we should not require tools to recognize XXX.
> But that isn't to say that tools couldn't make this an option if they
> chose.
> I think it would be counter-productive to offer such a switch.
>
> dbh
>
> > -----Original Message-----
> > From: owner-mreview@ops.ietf.org
> > [mailto:owner-mreview@ops.ietf.org] On Behalf Of Randy Presuhn
> > Sent: Wednesday, April 26, 2006 1:36 PM
> > To: mreview@ops.ietf.org
> > Subject: Re: Support for XXX OID value
> >
> >
> > Hi -
> >
> > Could you put a few more negatives in the question? :-)
> >
> > I think that requiring tools to recognize "XXX" would be a mistake.
> >
> > Randy
> >
> > ----- Original Message -----
> > From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
> > To: "C. M. Heard" <heard@pobox.com>; <mreview@ops.ietf.org>
> > Sent: Tuesday, April 25, 2006 11:35 PM
> > Subject: RE: Support for XXX OID value
> >
> >
> > Better, let us 'last call' this conclusion.
> >
> > Does anybody have a problem with considering that errors generated
> by
> >
> > myExampleMIB MODULE-IDENTITY
> > ...
> > ::= { mib-2 XXX }
> > -- RFC Ed.: replace XXX with IANA-assigned number & remove this
> note
> >
> > should be considered a feature and not a bug and need not be fixed
> in
> > tools and compilers recommended for MIB Reviews?
> >
> > Please answer until May 2nd.
> >
> > Dan
> >
> >
> >
> > > -----Original Message-----
> > > From: owner-mreview@ops.ietf.org
> > > [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> > > Sent: Tuesday, April 25, 2006 11:17 PM
> > > To: mreview@ops.ietf.org
> > > Subject: Re: Support for XXX OID value
> > >
> > > My recollection was that we concluded that the compile errors
> > > from the XXX oid was a feature, not a bug. If anyone wants
> > > me to I'll try to dig up the relevant stuff in the archive.
> > >
> > > //cmh
> > >
> > > On Tue, 25 Apr 2006, David T. Perkins wrote:
> > > > HI,
> > > >
> > > > We talked about in the past how to support a "temporary OID
> > > value" for
> > > > use in I-Ds. Consider:
> > > >
> > > > ---------------------------------------------------------
> > > > myExampleMIB MODULE-IDENTITY
> > > > LAST-UPDATED "200604130000Z" -- April 13, 2006
> > > > ORGANIZATION "IETF MIB Example Working Group"
> > > > CONTACT-INFO
> > > > "WG charter:
> > > > http://www.ietf.org/html.charters/mibexmpl.html
> > > > Mailing Lists:
> > > > General Discussion: mibexmpl@ietf.org
> > > > To Subscribe: mibexmpl-request@ietf.org
> > > > In Body: subscribe your_email_address
> > > > Chair: Dan Romascanu
> > > > Postal: Avaya
> > > > Atidim Technology Park, Bldg. 3
> > > > Tel Aviv 61131
> > > > Israel
> > > > Tel: +972-3-645-8414
> > > > E-mail: dromasca@avaya.com
> > > >
> > > > Editor: David T. Perkins
> > > > Postal: SNMPinfo
> > > > 548 QuailBrook Ct
> > > > San Jose, CA 95110
> > > > USA
> > > > Tel: +1-408-394-8702
> > > > E-mail: dperkins@snmpinfo.com"
> > > > DESCRIPTION
> > > > "The definitions in this MIB module are examples.
> > > >
> > > > Copyright (C) The Internet Society (2005). This version
> > > > of this MIB module is part of yyyy see the RFC itself
> for
> > > > full legal notices.
> > > > "
> > > > -- RFC Ed.: replace yyyy with actual RFC number & remove this
> note
> > > >
> > > > REVISION "200604130000Z" -- April 13, 2006
> > > > DESCRIPTION "Initial version, published as RFC yyyy."
> > > > -- RFC Ed.: replace yyyy with actual RFC number & remove this
> note
> > > >
> > > > ::= { mib-2 XXX }
> > > > -- RFC Ed.: replace XXX with IANA-assigned number &
> > remove this note
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > In the above, the RFC editor notes were taken directly from
> > > RFC 4181
> > > > ("Guidelines for Authors and Reviewers of MIB Documents").
> > > >
> > > > Did we decide whether or not that there should be a special
> value
> > > > (such as the XXX above) that with a command line switch
> > > would cause a
> > > > MIB parser not to generate an error message? For example,
> > > > mymibparser MY-EXAMPLE-MIB
> > > > might generate error
> > > > E: f(MY-EXAMPLE-MIB), (74,21) Sub-Id for item "myExampleMIB"
> > > > must be a "number" or "name(number)"
> > > >
> > > > But, with command line option, say, "--type=ID", such as:
> > > > mymibparser --type=ID MY-EXAMPLE-MIB would not output an error
>
> > > > message.
> > > >
> > > > Regards,
> > > > /david t. perkins