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

RE: Support for XXX OID value

To: "'David T. Perkins'" <dperkins@dsperkins.com>, "'David B Harrington'" <dbharrington@comcast.net>
Subject: RE: Support for XXX OID value
From: "David Harrington" <ietfdbh@comcast.net>
Date: Wed, 26 Apr 2006 16:48:07 -0400
Cc: "'Randy Presuhn'" <randy_presuhn@mindspring.com>, <mreview@ops.ietf.org>
In-reply-to: <Pine.LNX.4.10.10604261103240.14040-100000@shell4.bayarea.net>

Hi,

The template is still in my todo queue, but my isms-chair-boss insists
I get the ISMS drafts done first ;-)

And my other bos, the one that signs my paycheck, keeps coming up with
things he wants done.

I hope to get the ISMS draft revisions done within days and then find
some time to work on the template.

I'm willing to accept help if anybody has spare cycles.

dbh

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of David T. Perkins
> Sent: Wednesday, April 26, 2006 2:16 PM
> To: David B Harrington
> Cc: 'Randy Presuhn'; mreview@ops.ietf.org
> Subject: 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
> 
>

References:
- RE: Support for XXX OID value
  - From: "David T. Perkins" <dperkins@dsperkins.com>

Prev by Date: RE: Support for XXX OID value
Next by Date: No fee SMICng license
Previous by thread: RE: Support for XXX OID value
Next by thread: RE: Support for XXX OID value
Index(es):
- Date
- Thread