RE: MIB OID assignement

["David B Harrington" <dbharrington@comcast.net>]

I concur that this should be experimental if it rooted under
experimental.

dbh 

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of Romascanu, Dan
(Dan)
> Sent: Wednesday, November 23, 2005 10:13 AM
> To: C. M. Heard; Mreview (E-mail)
> Subject: RE: MIB OID assignement
> 
> 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
> > 
> > 
> > 
> 
>