MIB OID assignement

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

MIB Doctors,

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

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.


Bert