Re: Support for XXX OID value

["Randy Presuhn" <randy_presuhn@mindspring.com>]

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