[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Support for XXX OID value
While agree that the error should be there by default,
I do like David's proposal for a option to ignore it, as long as the
option is never on by default. Today before submitting an I-D with a
MIB, some folks hand replace XXX with a number and verify it checks
clean,
before submitting the I-D. Having such an option would reduce such
manual labor.
Dave
-----Original Message-----
From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org] On
Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, April 25, 2006 11:36 PM
To: C. M. Heard; mreview@ops.ietf.org
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