[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Support for XXX OID value



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