Re: MIB OID assignement

["C. M. Heard" <heard@pobox.com>]

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