RE: MIB OID assignement

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

I agree with Mike. There seems to be a rule of thumb here about
documents defining MIB modules that seems rather trivial and there
should be some good arguments not to follow it:

- if the MIB module is aimed to be rooted under mib-2 or transmission
for the older ones, the document should be Proposed or other standards
track
- if the MIB module is aimed to be rooted under experimental, that the
document should be Experimental
- if the MIB module belongs to some other organization OID space, it
should go Informational

Regards,

Dan




 
 

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> Sent: Wednesday, November 23, 2005 4:52 PM
> To: Mreview (E-mail)
> Subject: Re: MIB OID assignement
> 
> On Wed, 23 Nov 2005, Wijnen, Bert (Bert) wrote:
> > There is a document that has gone (as we agreed in SNMPEOS 
> some years 
> > ago) the "indivudual submission to RFC-Editor" route.
> > 
> > The request is for publication as Informational RFC.
> > 
> > The MIB author requests the two MIB modules to go under the 
> > experimental OID branch.
> > 
> > Do we see an issue with that?
> > I can live with it unless anyone sees a serious problem.
> > comments (if any) ASAP please.
> > 
> > This is about document: draft-glenn-mo-aggr-mib-07.txt
> 
> I do not see any showstopper issue with this, although given 
> the nature of the subject matter in the RFC I would _suggest_ 
> to the author and the RFC Editor that Experimental would be a 
> better category than Informational.
> 
> > Glenn Waters has done MIB Doctor review for this document.
> > I trusts Glenn's review, and I have (recently) only done a compile 
> > check to ensure no SYNTAX errors. It says:
> >   C:\bwijnen\smicng\work>smicng taggr.inc
> >   E: f(aggr.mi2), (212,21) Default value for 
> "aggrCtlCompressionAlgorithm"
> >      must be a name and not a number
> >   *** 1 error and 0 warnings in parsing and
> >   C:\bwijnen\smicng\work>smicng aggr.inc
> >   E: f(aggr.mi2), (212,21) Default value for 
> "aggrCtlCompressionAlgorithm"
> >      must be a name and not a number
> >   *** 1 error and 0 warnings in parsing which I will pass to 
> > RFC-Editor.
> > Technical flaws we can always point out to RFC-Editor.
> 
> This is not really a technical flaw in the MIB module but a 
> quirk in the tool.  The MIB review guidelines Sec. 4.6.1.1. says this:
> 
>    Although the SMI allows DEFVAL clauses for integer-valued
>    enumerations to specify the default value either by label or by
>    numeric value, the label form is preferred since all the 
> examples in
>    RFC 2578 are of that form and some tools do not accept the numeric
>    form.
> 
> > It is going to be on IESG agenda for Dec 1st.
> > Basically we can only reject if it conflicts with ongoing 
> or past IETF 
> > work, but I do not think such is the case. the standard 
> IESG note (as 
> > per RFC3932):
> > 
> >      The content of this RFC was at one time considered by the IETF,
> >      and therefore it may resemble a current IETF work in 
> progress or a
> >      published IETF work.  This RFC is not a candidate for 
> any level of
> >      Internet Standard.  The IETF disclaims any knowledge of the
> >      fitness of this RFC for any purpose and in particular 
> notes that
> >      the decision to publish is not based on IETF review for such
> >      things as security, congestion control, or inappropriate
> >      interaction with deployed protocols.  The RFC Editor 
> has chosen to
> >      publish this document at its discretion.  Readers of this RFC
> >      should exercise caution in evaluating its value for 
> implementation
> >      and deployment.  See RFC 3932 for more information.
> 
> That sounds fine to me.  All I would do is in addition is to 
> _suggest_ Experimental in place of Informational.
> 
> //cmh
> 
> 
>