Current Meeting Report
Jabber Logs

2.4.6 Evolution of SNMP (eos)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at: -- Additional EOS Web Page
NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 06/24/2002

Glenn Waters <>
Dale Francisco <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Bert Wijnen <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: (un)subscribe
Description of Working Group:
A small number of enhancements to the SNMP protocol would provide a substantial improvement to the protocol in terms of utility and efficiency. The enhancements must fall within the existing SNMP architecture as defined in RFC 2571. The intent of the working group is to focus on enhancements that may be easily defined and implemented which should then promote rapid acceptance and deployment. New protocol operations are within the realm of acceptable enhancements that may be defined.

The initial work items include:

- A standards-track document defining the mechanism by which the capabilities of a SNMP entity may be determined. This document should also define the interoperability requirements of the SNMP protocol when extensions are present and when they are absent;

- A standards-track document defining a mechanism for efficient retrieval, creation, and deletion of rows in tables;

- A standards-track document defining a mechanism used to delete an entire subtree of managed object instances. This could, for example, be used to remove all information related to a particular username in the SNMP administrative framework;

- A standards-track document defining a mechanism to provide for compression of object identifiers to remove as much redundant information as possible in the payload of the SNMP message; and,

- A standards-track document defining a mechanism for bulk transfer of SNMP data.

Some of the documents may be combined if the working group so decides.

No additional work items may be taken on by the working group until this initial set of work is close to completion. Additional work will have to be approved by the IESG and the IAB.

Goals and Milestones:
FEB 01  Working group chartered
FEB 01  First revisions of the documents
APR 01  Second revisions of the documents
JUN 01  Third revisions of the documents
SEP 01  Last set of revisions of all documents
SEP 01  WG Last Call for all documents and submit then to AD for consideration as Proposed Standard
OCT 01  Shutdown or re-charter
  • - draft-ietf-eos-snmpxproto-mib-02.txt
  • - draft-ietf-eos-snmp-bulkdata-01.txt
  • No Request For Comments

    Current Meeting Report

    Minutes of the EOS WG meeting
    IETF-55, Atlanta, Georgia, Wednesday November 20, 9:00 - 11:30
    Minutes by: Glenn Waters
    Minutes edited by: Glenn Waters
    Meeting chaired by: Glenn Waters
    A presentation on the status of the current draft was given by Wes 
    Hardaker. See presentation for details. The minutes just note the 
    questions and responses. No other items were on the agenda.
    The current draft is moving forward. Here are some specifics:
    - ASN.1 defined
    - much of the formal text is in place
    - feedback needed on write support
    - SMIv3 almost supported
    - Cursor field added to GO(R)Ps
    - Search-criteria now support AND/OR/NOT
    - Errors are now SEQUENCE OFs such that
      o Multiple errors can be returned for a given request
      o No errors is only a 2 byte empty SEQUENCE OF tag
    - Does this need to support SMIv3?
      - Yes, this needs to coupled this to SMIv3
    - support for large amount of data is very important
      o large sparse tables, augmented tables, millions of rows need support for
    - Bob Moore: want to see support in this draft for SMIv2 not just SMIv3
    - notification support - should we do it?
      o Yes so that we could have a stand alone document
    - return search-criteria field:
      o Only one opinion offered: no
      o Wes will not do this unless some compelling reason comes alone
    - desire for complex operations such as "get foo when columnX > columnY + 
      o Expression MIB could do this; don't do in protocol
      o Too much to put into the agent
    - augmentation retrieving
      o issue is that joins are hard in the agent
      o biggest issue is when different augments support different rows
      o one opinion is to put this in the agent
      o is ACL an issue? - need to be considered
      o we should do joins of augmented tables was the general consensus of the 
    - augmentation searching
      o Yes!
    - comment: want to make sure that the new write operations can store
      a complete configuration
      o this is one of the design goals
      o how could we "get" all the data from the agent that is the config and is 
    not the other stuff such as stats, counters, etc - want to be able to do a 
    system level backup of the configuration
    - there is customer interest in this work
      o this was stated by a 3 vendors (not all stack vendors)
      o there is implementer interest in this work
      o one person said that their company is not interested in this work 
    unless they see direct customer value


    EOS Object Oriented PDUs for SNMP