NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Glenn Waters <firstname.lastname@example.org>
Dale Francisco <email@example.com>
Randy Bush <firstname.lastname@example.org>
Bert Wijnen <email@example.com>
Bert Wijnen <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: (un)subscribe
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.
Working group chartered
First revisions of the documents
Second revisions of the documents
Third revisions of the documents
Last set of revisions of all documents
WG Last Call for all documents and submit then to AD for consideration as Proposed Standard
Shutdown or re-charter
50th IETF (Minneapolis) Evolution Of SNMP (EOS) WG, 3/19/2001, 0900 CDT
Compiled by Robert Bohanek and Lauren Heintz.
Dale Francisco opened the meeting with general comments.
Glenn Waters followed with a requirements overview discussion based on 'draft-ietf-eos-requirements-00.txt', which unfortunately wasn't submitted to the IESG in time to be published before the working group meeting.
EOS deliverables must conform to rfc2571, and any new work is not intended as a replacement to existing frameworks.
Capabilities mechanism was discussed. Consensus reached that this does not need to advertise "base features" of an entity, though some debate occurred about what "base features" are, and the short answer seemed to be "whatever is in SNMPv3". It may be this is a difference between MUST vs SHOULD language. It was observed by one member that field implementations of SNMPv3 are spotty, and the assumption to add stuff is that it means new PDU's.
OID Compression was discussed. Dave Perkins suggested this was a non-issue except perhaps when retrieving large amounts of information. Clarification was sought from the audience about what specific problems OID compression was trying to solve. Bert Wijnen reminded all that the EOS charter specifies the requirements and objectives, and that any other items to be added, need to be added later, after the initial goals have been met.
Efficient row creation was discussed. Row creation semantics are currently heavyweight. This requirement is deemed to simplify the burden on agents in dealing with configuration requests. Do we do this with a new PDU type? Where does the WG want to go?
Efficient sub-tree deletion was discussed. Joel Halpern observed that sub-tree deletion is only one possible solution to an unstated or poorly formed requirement. If data synchronization is the actual requirement, then let's say that instead.
Efficient Bulk Transfer was discussed. A request was fielded for an explanation of the difference between a single protocol operation and a single "conceptual" operation. Is it a Grand PDU that causes multiple smaller PDU's? This requirement is vague, it was suggested. It was conjectured the idea is to minimize the amount of work and have it appear as if a single operation is at work. One attendee wondered if the operation needs to understand table boundaries, so that you can get to the bottom of the table and quit? Glenn Waters added that, in general, the idea is to transfer large amounts of data and figure out how to grab all, or a specified part of a table. Dave Perkins pointed out that when retrieving large information that contains counters, you may have large differences in timestamps. Does the requirement need the data to be consistent? One co-chair said this was a reasonable thing to consider and that we should add that as a requirement. We need to discuss and get guidance on it.
Efficient set, efficient row operations, efficient row creation were discussed. Someone asked if createAndGo (as opposed to createAndWait) by itself meets this requirement. What are we trying to solve? Is it to remove createAndWait? There was another request for specificity for the need of this requirement.
One attendee contended that in order to do away with createAndWait, we'd need TCP in order to remove the packet size limitation that originally motivated createAndWait. Randall Atkinson said if the goal is to remove createAndWait, we need to make that explicit. That would be a 5-6 year implementation curve. A co-chair cleared the air by saying that the goal is to create a new, simpler, more powerful row status TC. Can't make createAndWwait go away. Dave Harrington agreed that createAndWait is still needed. A question was raised whether the current RowStatus TC requires createAndWait to be supported? There were differing opinions.
Jeff Case observed that we were mixing layers in our discussion. For future MIBS, a new RowStatus TC does not need createAndWait. It could be called RowStatusLite, at least for purposes of discussion. It is a MIB issue, not a protocol issue. More concerns were raised that some future table designs and/or implementations would not be able to support RowStatusLite, but consensus seemed to indicate that was not problematic. The new TC would have to be explicit with this regard, and indicate you may have to in some cases support large PDUs in order to support RowStatusLite. That's the penalty you pay to get the benefits.
Bert Wijnen again homilized, as he would have to do so many times in the next few hours, that the EOS charter describes the issues we need to discuss. Someone offered the idea that any WG can consider a TC, but cannot mandate that it be used from then on.
Glenn finished up the requirements overview and turned the floor over to Jeff Case to talk about OID Compression issues (see associated slides).
Jeff contends that we need a third rev of protocol operations, much in the same way that the SNMP MIB and SMI have been rev'ed several times with much needed improvements.
No special problem handling the new PDU types; there's an "unknown PDU" handler now, sq would work fine under SNMPv3. It is an engine to engine communication.
Gordon Bowman asked how we would set compression for one PDU type but not another? Which of the things are we talking about are not engine specific? Row creation would be MIB specific. Jeff Case answered that it depends on what solutions we come up with. Agent implementation strategy should be transparent.
Wes Hardaker suggested that two different aspects to capabilities need to be considered: Master agents need to advertise protocol-related capabilities whilst subagents need to advertise MIB specific capabilities. A mechanism is needed to ensure that occurs properly.
Jeff discussed multiple approaches to OID compression and suppression ranging from entire message/pdu compression to applying transformations to parts of the PDU contents.
If all objects are part of the same row, then we can dispense with instance OIDs, using either an explicit naming scheme (using single numbers to indicate the column number of each varbind), or an implicit scheme in which the position of the varbind in the list corresponds to its column number.
More research into compression and suppression is needed. They may have independent applications and suppression may even eliminate need for compression.
Sandra McCleod of SNMP Research will be performing some performance studies on these different approaches to see which does indeed work better. Andy Bierman pointed out that the instance part of the OID is significant and that we have the problem of operations affecting multiple MIB groups, such that multiple sup/compressed OID anchors are needed in the op, as needed. Andy was rewarded with a shiny new dime because his comment was a perfect segue to the next slide. Andy was observed suspiciously testing the coin with his teeth.
Randy Presuhn pondered the implications of creating new PDU types. But since the VACM table in rfc2575 is sorted based on read, write and notify operations, it was felt a new PDU would fit well in those categories, thereby indicating that VACM probably would not be affected.
Another attendee made a plea to adhere to simple solutions and to try to combine solutions such as bulk transfer and OID sup/compression where possible.
Jeff Case stated a requirement for subtree deletion was questionable. Seems like a MIB thing, not a protocol thing. Must maintain statelessness and not become jailed during Packet Loss. Jeff Case acted out the "go to jail" phenomenon where connection oriented data transfers may be severely interrupted in lossy networks and have to start over.
A suggestion was raised that connection mgmt is a viable solution in cases for bulk retrieval when the net is working well. A dissenting opinion suggested that what works when the net is good must also work when the net is bad. This opinion was seconded by another who enjoined with yet another call for simplicity.
David Perkins then presented his proposal for a getCols capability (see associated slides).
getCols allows the requester to specify particular columnar objects to retrieve for every row. The advantage of this is that some information (configuration, state) changes rarely and is a waste to retrieve on every poll.
He outlined the problems with getNext and getBulk (e.g. too many operations, holes, overshoots, low packing factor) and suggested a bulk transfer mechanism is needed only when the table contains huge amounts of data. His initially proposed getCols PDU can "fit" into existing PDU structures much in the same way that getBulk "fits" into a getNext PDU.
Some questions arose about how getCols knows when to "stop" retrieving. David indicated a "stop" parameter would be included in the PDU, the details of which need to be worked out.
Someone wondered if the OID compression/suppression work might preclude the need for getCols, and David responded that the WG would have to determine if that is the case. Randy Presuhn also suggested that a "tail" function might be desirable -- to be able to retrieve only that part of a steadily increasing table (e.g. a logging or history table) that had been added since the last retrieval or from a specified instance. Another voice asked whether getCols allowed for filtering of rows from the indicated slice. The answer to this latter question was that getCols as presented does not filter, though some more discussion abounded concerning whether such a filter operated on the instance info or the object values, as well as the parameters getCols would need to support such filtering capabilities. It was also asked whether getCols was meant to retrieve only "dirty" row data or all data within the specified slice, and the answer was "all data" and that MIBs should always be designed anyway to anticipate the kinds of getCols slice retrievals most often needed so that added complexity (in the form of filters and dirty row skipping) is not needed.
Dale Francisco now requested general comments:
Concerns were raised over whether EOS and SMING WGs had overlapping efforts. A specific question was asked regarding extended data types and kerberos and RADIUS issues. Randall pleaded not to entangle Radius and SNMPv3 security issues. Just depend on SNMPv3.
Dan Romascanu suggested we don't need bigger data types, according to former lessons learned as the etherMIB WG chair, to which objections were raised to add Gauge64 and other types. Jeff Case countered that signed fixed-point int64 support was needed.
Bert again echoed the mantra that it is OK to consider such things for the future, but probably not until EOS completes initial charter. We may have charter enhanced with things later on that fall off SMING charter. SNMPv3 WG considering whether we need to extend more security models, but such issues are not part of EOS WG either.
Randy Presuhn pointed out that the EOS WG may define new PDU types, and since SNMP uses a CHOICE SYNTAX in rfc1905, syntax defs in rfc1905 must be cloned and new choices added. This may be problematic.
Glenn commenced with closing remarks: Many related issues have been identified in the charter items, so we may need to merge some of the documents, as needed. Also need to come to consensus on choices of desired approaches. Need first drafts by April 20th to IETF editor so we can have discussions on the list. Dale observed that some discussion was necessary as a precursor to getting the documents ready.
Bert encouraged the editors to sign-on to the April 20th milestone, and no objections were heard.
Evolution of SNMP (eos)