2.4.9 Evolution of SNMP (eos)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

Glenn Waters <gww@nortelnetworks.com>
Dale Francisco <dfrancisco@acm.org>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Mailing Lists:

General Discussion:eos@ops.ietf.org
To Subscribe: eos-request@ops.ietf.org
In Body: (un)subscribe
Archive: ftp://ops.ietf.org/pub/lists/eos*

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

Internet-Drafts:
No Request For Comments

Current Meeting Report

Final minutes of the EOS WG meeting

IETF-51, London, England, August 7, 2001, 9:00 - 11:30

Minutes by: Dave Allan and Glenn Waters
Minutes edited by: Glenn Waters

-----

Chairs: Dale Francisco <dfrancisco@acm.org>

5 Chairs Introduction / Agenda bashing / Minute takers / Blue sheets

15 Sharon Chisholm Review the requirements email from May 24

10 Sharon Chisholm Extended Protocol MIB draft-ietf-eos-snmpxproto-mib-01.txt

15 Bryan Levin SNMP Bulk Data Transfer Extensions overview


15 Lauren Heintz Status of current Row Ops draft draft-ietf-eos-snmp-rowops-01.txt

5 Matt White Status of the OID Compression draft draft-ietf-eos-oidcompression-00.txt

15 Glenn Waters Charter review: discuss milestones and moving forward

30 All Open discussion

5 Dale Francisco Wrap up: next steps / collect blue sheets

-----

Sharon Chisholm - Requirements discussion

- slides presented

- Mike: what is the improved error reporting requirement about?

Sharon: to be further fleshed out

- Steve Moulton: list of requirements was meant as talking points for the list/meetings and not for an RFC; requirements are not prescriptive

- Jeurgen: overall efficiency is important; efficiency in terms of bits on the wire is just one aspect; reduction of latency is of similar importance

- Jeff Case: what is the compliance column for? Sharon: explained the yes/no/maybe values in the column as: Yes is there is rough consensus that we want to meet the requirement, maybe is some consensus, no is no consensus.

-----

Sharon Chisholm - Extended protocol MIB

- slides presented

- discussion of whether need to have complete rows sent in a set

o Andy Bierman: mentioned the cases where sets are hard - particularily around set split across multiple PDUs

o Dave Perkins: can put additional constraints on RowStatus; just do proper MIB design. A comment was made that PDU size limit can be a problem with large sets.

Sharon: don't completly disagree with Dave's statement

o Mike McFadden: most MIB modules don't provide enough text to provide interoperable implementations.

There's a wide variety of responses to set situations that an application needs to handle. Most MIBs do not contain enough text to describe interoperable implementations.

o Clarified the removal of traditional sets: not really removal just that they would not be supported for some of the MIBs

-----

Bryan Levin: Bulk Data Retrieval - implemented as MIB extensions

- slides presented

- discussion around returning MIB symbolic names from the agent: most agents don't have this information -- can be optional from the agent and just use the OIDs

- username/password is stored on the device: this is a security problem; don't want to stick the passwords for a file server out on a device; maybe the server can contact the agent to initiate the upload; not an easy problem; one suggestion: sign the file with a digital certificate so that the authenticity of the uploaded file can be verified (use anonymous FTP); many carriers don't mind having a configured password on the devices; take the discussion to the list

- concern around the footprint of the implementation: not necessarily for small boxes; bulk-data is what the draft is about and only larger boxes will require the features that are in this draft so foot print should not be a big issue

- file versioning as presented is overkill; find a way of making it simpler;

- suggestion for storing the files on the device and have the server request the file periodically; this solves the versioning and authentication problems; the agent knows best when the data needs to be pushed since it knows when the buffers are getting full

- Jeff Case: order of magnitude performance improvement over what? Compared with a GetBulk, using a 10K row table transferred compressed with gzip and using SCP on a 128K ISDN link; lets get some better comparisons and post to the list

-----

Lauren Heintz -- Row Operations

- slides presented

- Dave Battle: likes that can be able to interwork with subagent/proxy agent technology

- Jeurgen: interesting approach but hard to decide if the approach is good before can decide if there is concensus when the document is not complete enough

- Mike/Dave Perkins: RowStatus is sufficient as is -- just write some better text descriptions that state how the row is allowed to be manipulated.

- Glenn: the document is purposefully not complete -- trying to understand if there is enough consensus around this approach before writing lots of text and making the work complete.

-----

Matt White -- SNMP OID compression

- document is from last April, very little response. Jeurgen commented on relative efficiency of ODC vs. OPC described. Robery Story had comments on when to use OID compression.

- please post comments to the list.

-----

Glenn Waters - Current Status and Charter Discussion

We're a fair bit behind. We're one revision behind as a loose description of the status. Overriding comment is list has been extremely quiet. We need more comments and more discussion to figure out next steps. Open discussion time now.

One of the big problems is not enough to discuss. Bulk data transfer just appeared. Rowops needs detail before we put our teeth into it. Need implementation details.

Any commments on the requirements, are we hitting the mark?

I was trying to figure out what problem we're addressing. Did an implementation of the get column stuff. it was fast and dirty so CPU usage is bad, on the wire transfer is good. But this was not our day job.

Sharon, was given a rough priority on effeciency, simplicity, on the wire transparancy, but there is a priority on transition, and proxies etc. Which is the real priority. A: interoperability period... Q: who thinks being able to translated from tradops to EOSops is a high priority.

Higher level hum question, interest in rowops. Example of time invested in contributing that black holed and how hahrd it is to motivate interest in a vaccum.

Back to rowops, no hums either way.

Review of docs and 6 months of mailing list shows lots and lots of stuff....

Real problem is slight demand of the operational community, not complexity of implementation. Benefit of this work is purely to MIB implementors. (for "write MIB", substitute "implement agents").

As a participant, finding time for EOS is difficult. This is also 5 years overdue,and has lots of competition (COPS etc.). I can;t tell what is happening in the industry. The overall picture is a mystery.

Slides

Evolution of SNMP Requirements & Compliance
SNMP Extended Protocol MIB
Bulk Data Retrieval Implemented as MIB extensions
SNMP OID Compression