Last Modifield: 06/24/2002
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.
|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|
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 + columnZ 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 room - 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