The Managed Object Aggregation MIB
RFC 4498

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.org
Subject: Re: Informational RFC to be: 
         draft-glenn-mo-aggr-mib-09.txt 

The IESG has no problem with the publication of 'The Managed Object 
Aggregation MIB' <draft-glenn-mo-aggr-mib-09.txt> as an Informational 
RFC. 

The IESG would also like the IRSG or RFC-Editor to review the comments in 
the datatracker 
(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8098&rfc_flag=0) 
related to this document and determine whether or not they merit 
incorporation into the document. Comments may exist in both the ballot 
and the comment log. 

The IESG contact person is Dan Romascanu.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-glenn-mo-aggr-mib-09.txt


The process for such documents is described at http://www.rfc-editor.org/indsubs.html.

Thank you,

The IESG Secretary

Technical Summary
 
  This memo defines a portion of the Management Information Base (MIB),
  the Aggregation MIB modules, for use with network management
  protocols in the Internet community. In particular, the Aggregation
  MIB modules will be used to configure a network management agent to
  aggregate the values of a (user) specified set of Managed Object
  instances and to service queries related to the aggregated Managed
  Object instances. 

Working Group Summary
 
  An earlier version of this document was discussed in the SNMPEOS
  Working group (several years back; the WG was closed in April 2003).
  The WG did not accept the document as a WG item but also seemed to
  have no problem if the author would go the "individual submission"
  route, which he has now done.

Protocol Quality
 
  This MIB modules in this memo have been checked for correct SYNTAX
  by Bert Wijnen. They have also had a high level of MIB doctor review
  by Glenn Waters (former WG chair of SNMPEOS).

  I (Bert Wijnen) am still discussing if the fact that the document
  goes for Informational while the MIB modules are registered under
  experimental is an issue or not. I think not. Will try to conclude
  before IESG telechat  on Dec 1st.

Note to RFC Editor

We had extensive discussion within the MIB doctors team about
this document w.r.t. the fact that it is requesting publication
as an Informational document while the MIB module is requested
to be registered under the IETF Experimental OID branch.

That seems to be in conflict with each other.

The MIB doctors advise that the document be published as Experimental
(and then assign the MIB module under the the Experimental OID branch.

If that is unacceptable to the RFC-Editor and/or the author, then the
MIB doctors advise that the MIB module be registered under the 
(enterprise specific) vendor OID branch of the authors employer.

Furthermore, in the MIB modules there are still two (minor) errors that 
you may want to ask the author to fix:

  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

IESG Note

     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.