Current Meeting Report

2.3.7 Evolution of SNMP (eos)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 19-Feb-02
Glenn Waters <>
Dale Francisco <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Bert Wijnen <>
Mailing Lists:
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
No Request For Comments

Current Meeting Report

IETF 53, Minneapolis, MN.
Minutes from the EOS WG Meeting -- March 18, 2002

Meeting was chaired by Glenn Waters.
Co-chair for the meeting, Dale Franciso, was not present.

Minutes taken by Randy Preshun and Glenn Waters; edited and submitted by Glenn Waters.

Introduction -- Glenn Waters

Other ideas and WGs around the IETF are causing an impact on the EOS work. When the work started out around 18 months ago SMIng had a direction that was more around changing syntax and the Operators draft did not exist (draft-xxx). These items are causing grief for EOS since these other items are taking mindshare and desire away from the current EOS charter. Discussion of this topic will take place after the presentations.

MO Aggregation: Programming MIBs -- Glenn Keeni

Presentation given (slides included in minutes).

Q: what about PDU size?
A: application sets limit of variable binding value's maximum size.

Q: can value be retrieved in pieces?
A: mib defined puts the values into rows.

Q: How does access control work since there is third party access to the objects?
A: Needs some work.

Q: How is this different from other MIBs?
A: The behavior is governed by application.

Q: Other MIBs such as disman, rmon, esp. expression have similar functionality.
A: This MIB has a narrower focus.

Q: What about looking at "entire" table, which raises questions of how to deal with row creation and deletion?
A: This proposal doesn't address issues of monitoring an entire table, since it must be explicitly configured with all the instances to be monitored.

Q: What happens when specific instance being monitored disappears?
A: Need to look at this issue.

Observation: Looks like the user history table in RMON, except this packs values into a variable binding. Sampling begins when MIB configured, so nothing special about the get/response sequence. We may want to look at a more generic solution to this problem.

Resolution: No action to accept this work at this point in time. Further discussion to be taken to the mailing list.

SNMP Extended protocol MIB -- Sharon Chisholm

Presentation given (slides included in minutes).

Open issues:
- no enriched error checking, thinking that this would go into a potential revision of RFC 1905
- currently no extended protocol operations making this work unnecessary until new protocol operations exist.

Bulk data retrieval -- Bryan Levin

Presentation given (slides included in minutes).

Q: When do snapshots go away?

A: requires NMS to do it. The transferred file? may need more config to manage these.

Discussion arose around whether the transfer table could be normalized. Some thought optimizations could be made, others thought what was there was fine. Further discussion on table design on the to occur on the list.

Comment: should there be a wall clock timestamp on the data?

Discussion: The need for this feature was thought to be low, more discussion to take place on the list.

Comment: symbolic names cannot be required since agents in general do not have access to the symbolic names. Must be able to use OIDs.

Comment: There are security issues since the data is collected as "root" and the VACM privileges are ignored. Discussion: this issue must be addressed.

Comment: The MIB requires storing userids/passwords in the agent so that data can be pushed to a FTP server. This is a security concern that will be sufficent to block this MIB at the IESG. We can request that a security advisor be assigned to help with the security aspects of the MIB design. It was noted that the DISMAN MIB has similar issues and they have been solved there.

Discussion around atomicity of the snapshots. The draft should comment on the what can be expected in the snapshots; for example are the snapshots better than just querying from the manager to get the data.

Open Discussion

Comments from the chair:

Status of the group was posted to the list about 2 weeks before the meeting. There have been no responses to the queries on the list.

The work that is that furthest along is the Bulk Transfer MIB. All other work does not have any traction. The "RowOps" proposal should be tied to the work in SMIng as the decisions there may change the types of RowOps that the EOS group may define. The other development in the IETF that has occurred since the EOS group was chartered is that the Operators draft has been published. It is not clear if the EOS group should do anything to accomodate their draft.

So, what *should* the next steps for this WG be? In particular what should be done with RowOps?

Jeff Case commented that he could revive some work that he has done with Steve Moulton and Sandra. The work would line up with the SMI-DS work being done in the SMIng WG.

General consensus was that we would try to get that work going and if there is no significant progress by the next IETF meeting then the group should consider dropping RowOps from the charter.

Some discussion around the bulk and MO proposals that exist and that there is some overlap in what they accomplish.

Glenn will summarize the issues to the list so that we can elicit the direction that this WG should take.

Comments from the Area Director:

The AD does not want this WG to linger much longer without progress. The AD also does not want this group to become an extension that works on follow up work as a result of any SMIng or Operators work. If that is needed we can form appropriate WGs when we get to that point. The AD would want this WG to try and complete the limited work items that are in the WG charter. If you want to drop some, fine. But either complete or remove the current workitems, or run the risk to be shot down as a WG.


SNMP Extended Protocol MIB
Bulk Data Retrieval Implemented as MIB extensions
MO Aggregation: Programming MIBs