The SNMPv3 working group met on Monday, July 31 at 7:30 PM during the 48th IETF. The chairs of the SNMPv3 working group (Russ Mundy and David Harrington) were both present, as was the area director (Randy Bush). The meeting was reported by Steve Moulton and Rob Frye. There were approximately 100 attendees present. The mailing list address for this working group is SNMPv3@lists.tislabs.com. The mailing list archives are available at ftp://ftp.tislabs.com/pub/ietf/snmpv3. The slides presented at this working group meeting are available at ftp://ftp.tislabs.com/pub/ietf/snmpv3/ietf48. The first major item on the agenda was the usual administrivia. The agenda was accepted as proposed. Agenda Item 2: Working Group Last Call for updates to RFC1905 (draft-ietf-snmpv3-update-proto-04.txt), RFC1906 (draft-ietf-snmpv3-update-transmap-04.txt), and RFC1907 (draft-ietf-snmpv3-update-mib-04.txt). The chairs announced that consensus has been reached on all items. This presentation was led by Randy Presuhn . The full document status material is available at ftp://amethyst.bmc.com/pub/snmpv3/update567/index.html. This presentation used the agenda slides discussed above. RFC1905 - There are no open issues. RFC1906 - One open issue. 1906-20: Should UDP transport mapping be mandatory. The current text reads: Although several mappings are defined, the mapping onto UDP over IPv4 is the preferred mapping. As such, to provide for the greatest level of interoperability, systems which choose to deploy other mappings should also provide for access via the UDP over IPv4 mapping. The consensus from the mail list was to replace the current text with the following: Although several mappings are defined, the mapping onto UDP over IPv4 is the preferred mapping for systems supporting IPv4. Systems implementing IPv4 MUST implement the mapping onto UDP over IPv4. To maximize interoperability, systems supporting other mappings SHOULD also provide for access via the UDP over IPv4 mapping. Randy asked if there were any problems with the proposed text wording, and no response was received. RFC1907 - There is one open issue, although that issue involves several changes to the conformance material. 1907-19: During working group last call, it became clear that some further clarification of the conformance material was required. . snmpBasicNotificationsGroup Description. The proposed description text reads: DESCRIPTION: "The two notifications which an SNMP entity supporting both command generator and notification originator applications is required to implement." Bert Wijnen immediately made the observation that text "command generator" should be replaced with "command responder". Immediate agreement was reached on what was a wording error. Keith McCloghrie asked about what happens if you have an entity that is just a notification originator. Randy Presuhn replied that in the original framework there was no such thing as a pure notification originator. Much discussion followed on this point, centering around the issue of whether it makes sense to specifically mention notification originator. The question was raised on whether the "and notification responder" text should be dropped. Agreement was reached that it should. . snmpAdditionalNoticationsGroup DESCRIPTION The proposed description text reads: DESCRIPTION: "The notifications which an SNMP entity supporting both command responder and notification originator applications is required to implement if it is able to reinitialize itself such that its configuration is unaltered." The question was raised on whether the "and notification originator" text be dropped? Agreement was reached that it should. . snmpBasicCompliance: adding snmpNotificationsGroup The snmpNotificationsGroup was originally included under snmpBasicCompliance in RFC1907. The statement was made that if we assume that any meaningful entity that supports this MIB will support both command responder and notification originator applications, it should probably be included, since this would be a non-change from RFC-1907. Proposed resolution of this question is to restore this item to snmpBasicCompliance MODULE-COMPLIANCE. Agreement was reached. David Perkins requested that in the future, when we specify a new notification operation, such new notifications have no impact on this. Randy Presuhn stated that restoring the snmpBasicCompliance MODULE-COMPLIANCE was a fix of an inappropriate edit. . snmpBasicCompliance: adding snmpAdditionalNotificationsGroup This group is not in the snmpBasicCompliance statement in RFC1907. The proposed change was that the snmpCompliance should refer to the snmpAdditionalNotificationsGroup. It does not currently. Keith McCloghrie stated that the conditions under which this particular notification group is required would move it into the conditional portion of the module compliance statement. David Perkins concurred. This was modified to be consistent with RFC2578. Chris Wellens asked if the module compliance statement was implemented in products in the field? There was no response. Randy Presuhn stated that his concern is narrow - what we state in the document should specify what a conforming implementation should do. What is actually done in the marketplace is not our issue. What this does is give customers a way to demand this feature works. The proposed resolution is that we will include text being written by Keith McCloghrie and David Perkins, once it has been approved in a brief comment period on the mailing list. [The wording Keith proposed makes moot some of the wording changes discussed earlier. -ed] Summary of the RFC1905/6/7 Last Call Changes . The preambles across all three documents will be made consistent. . In draft-ietf-snmpv3-update-proto-04.txt, there will be no addition of a "too complex" error code (1905-37). . In draft-ietf-snmpv3-update-transmap-04.txt . rfc1157Domain - the consensus is to deprecate (1906-6/10) . UDP/IPv4 - requirement for compliance in systems which support IPv4. Resolved as discussed above. (1906-20) . In draft-ietf-snmpv3-update-mib-04.txt the conformance text needs cleanup, and will be resolved as discussed above. Keith and David will supply text. (1907-19) Agenda Item 3: Deployment Plans and Reports. . UC Davis SNMP Project / NAI Labs test bed. Well distributed, but little feedback. Nearly 40,000 copied distributed via FTP. It is also distributed in RedHat Linux and FreeBSD. . Defense Information Systems Agency (DISA) . Keith Fuller (fullerk@ncr.disa.mil) said that DOD is very interested in SNMPv3. They will roll out SNMPv3 on a 250 node worldwide ATM structure. Big issues: How big of a pilot and how much testing before they deploy. . The next phase will be to deploy SNMPv3 on secure and unsecure data networks. . No other deployment information via the SNMPv3 mailing list or by private mail to Russ Mundy has been received. . David Harrington reports that Enterasys is putting SNMPv3 into their products. . A speaker from the floor stated that it is a requirement from Cablelabs that all cable modems that are Cablelabs certified have SNMPv3 with DES-CBC w/ 56 bit key. The reason is that there have been reports of theft of service from SNMPv1 cable modems. . Satyen Chandragiri/Lucent: Cable modem termination system are also required to implement SNMPv3. [additional comments from email: CableLabs requires that all cable modem termination systems (CMTS) must implement SNMPv3 to be "DOCSIS 1.1 Qualified". Cable operators are concerned that account/subscriber management information and configuration data collected from the CMTS may be compromised en route, and hence the need for authentication and encryption of messages.] . Others have noted requirements but are under non-disclosure agreement and cannot divulge details here. Russ reiterated the need for deployment reports. He asked the SNMP vendors to encourage customers customers to let the IETF community know that they are using SNMPv3. This is currently the single biggest issue that is holding us back from advancement. We need deployment reports for RFC2571-5. Agenda Item 4: Overview of proposed Work Items. Russ Mundy discussed the response to his request for help setting priorities on future work items sent to the mailing list. He stated that there was a roughly equal split between "go dormant" and "consider additional work items". Bert Wijnen stated that this is the best group of people to determine whether or not to do these items. He would like to prioritize top things to work on, and then decide "in this working group or somewhere else." Keith McCloghrie stated that it is a good thing to have a central working group to which new work items could be brought. Randy Bush stated that there is a concern that further perceived mucking with SNMPv3 would slow deployment. ( i.e., add FUD: Fear Uncertainty & Doubt) Dave Harrington stated that there is also concern that if we walk away from further bulk data transfer improvements, that people will walk away from SNMPv3. A commenter from the floor who is a former cable modem guy stated that the observation to make is that these things are being considered in the IRTF. Having stability in the specs will permit more inter-operating deployments. The way the specs kept changing have made it difficult to implement. Randy Bush: As an operator, I am interested in stability stability stability. If I hear bulk transfer is coming down the pipe, I am going to stay with v2, as it takes me 4 to 6 months to roll out software. Keith McCloghrie: Security must not be very important to you if you wait for bulk to implement. Randy Bush: It still costs me 4 to 6 months each time. Jeff Case: Our problem is that we have not been able to get these customers who have deployed to get here to talk about it. You are not getting operator reports because there are not very many operators in the room. Some customers are still concerned since they got burned by SNMPv2. All some vendors need is an excuse, and the perception is the excuse. Michael St. Johns: Lets get it out. No more changes. Do this in SNMPv4, NOT in SNMPv3. Rob Frye: Yes there are lots of holes we can fix and improvements we can make. Sure we need to do these, perhaps based on work in the NMRG, but we should not expand the charter of SNMPv3 beyond what is truly necessary for deployment acceptance. Jeff: I know of vendors whose revenues are up 30% over last year due to SNMPv3. Customers neither agree to speak about it nor do they come to these meetings. We did a great job on SNMPv3 documents when we started it, but it is going slow now. I can't encourage customers to invest in the SNMPv3 list. We need to find a different method to get implementation reports. We will post URLs of press releases to mailing list. Chris Wellens: Get the universities to deploy SNMPv3 - give them product via grants, get them to product reports. Make deployments happen. Russ Mundy: We need to focus on question of additional work. There are a number of people that think things need to be attacked, in particular efficiency improvements. slide: Efficiency Proposals: (from the proposed work items: Efficiency slide): Strong support, real proposals: . Standards-track TCP mapping . Bulk Transfer . get_subtree . FTP and BULK Transfer MIBS . PDU Compression . OID suppression. comment from floor: All SNMP v1,v2c,v3 are working. The only deficiency I want to see addressed is bulk transfer. This is the key to deploying SNMPv3. Dave Harrington: Due to the overhead of the security in SNMPv3, improving the efficiency will help diminish this. Rob Frye: A number of the inefficiencies have to do with management of the security. Randy Presuhn: The inefficiency really is in the CPU demands of security. Keith: In some usage scenarios, bulk transfer is important, some times not. Jeff: I have heard complaints about configuration. Not about performance. We are addressing this with a GUI. Keith: For many years, Cisco has had the complaint that when NNM reads the routing table, the CPU in the router goes to 100% for some time. Chris Elliot: The routing table does not get stored in lexicographical order. Jeff: The problem is not v1, v2c, v3. The problem is with the storage methodology. Ram Kavasseri: We have proprietary bulk PDU and compression. It helps some. slide: Documentation Proposals: no support for moving forward. slide: Security Algorithms and key size: There is support for moving forward. slide: Protocol extensions: There are no firm strong proposals but mild agreement on moving forwards. slide: Information and Data Modeling: Mild agreement that many of these topics may be reasonably examined by the Network Management Research Group of the IRTF, and some should be examined in the IETF. Keith: We should have an integrated language to describe both COPS and SNMP data structures. Other groups will benefit. David Harrington asked that if, in light of the previous comments about not expanding the working group charter, we should still discuss Bulk Transfer proposals. There was no negative response. Agenda Item 5: Proposals to Improve Efficiency. Juergen Schoenwaelder made a presentation on several bulk transfer proposals. See slide references at the beginning of these minutes. The presentation dealt with efficient handling of large amounts of data (typically hundreds of kilobytes of data) in a single logical transaction. Various approaches were proposed. The slides are complete and will not be reproduced here. Some parts of the presentation were abbreviated due to time constraints. Randy Presuhn: Did you use consider the use of compression in a SNMP over TCP using IPPCP [RFC2393 -ed] ? Juergen: That brings up interesting issues of MTU. Presentation: Bulk Transfer Proposal using Bulk File and FTP Client MIBS. Niraj Gopal. Cisco Systems. Problems: . High Latency . High network Overhead . ASN.1 BER consume agent and manager CPU Time . Table Retrieval Issues. Main components: . Bulk File creation components issue an internal get request to get the value of the MIBS object specified and creates a file containing bulk SNMP data is managed by the Bulk File MIB. . File transfer component uploads the bulk file to the NMS side using FTP and is managed by FTP Client MIB. This scheme is implemented by Cisco and they are willing to share it with the working group. There are three different file formats supported: 1. ASCII space separated instance values with row index and other tags. 2. Binary format that consists of tags and data fields. There is a tag to set a standard OID prefix, a tag for a single object, and some tags to encode tables. 3. BER Encoded that is the same as SNMP varbind list in a PDU. Presentation: Subtree Retrieval MIB. Dave Thaler (dthaler@microsoft.com) This work is based on an expired Internet Draft available at http://www.eecs.umich.edu/~thalerd/subtree.txt. This proposal does not require any changes to SNMP. The basic idea is that a single message is sent as a request, and data is carried back to the management application in a series of notifications containing sufficient serialization data to make sure all message are received. An intermediate message can be sent to terminate operation in progress. Limitations: The agent must allow sets to the MIB, the target must be configured as a trap target, and the subagent implementing the MIB must be able to walk other object with proper access controls. To be done: Need to update Internet Draft to get multiple subtrees in parallel. Presentation: GetCols Operation, David Perkins (dperkins@dsperkins.com). David Perkins gave a presentation on a proposed GetCols operation. The slides are available at the location specified in the beginning of this document. Problem: typical use of SNMP is to periodically retrieve status and statistics. . Need to get table slices (RMON2 and DISMAN) . Getnext and getbulk are not good enough . Too many network message exchanges . Getbulk: data overshoot a problem . Getbulk: how do deal with missing instances (holes) The proposed GetCols operation has problems with holes, no overshoot problems, and a higher packing factor than getbulk. Holes are plugged with noSuchInstance exceptions, and OIDs are highly compressed. Some performance numbers were presented (and are in the slides). A comparison with other approaches was presented. Presentation: Extending SNMP to Support BULK MIB Data Transfers. Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de). No attempt is made to reproduce the slides here. Several approaches were presented, but compressed due to time limitations. Approaches included: . SNMP over TCP. . Lossless SNMP Payload Compression (must compress before encryption). . Should support multiple compression algorithms . The compression algorithm can be treated as an SNMPv3 encryption method, or indicated in the msgFlags. . Data can be wrapped in a new PDU type. The Network Management Research Group (IRTF) prefers the new PDU approach. There is a running implementation of this approach. Agenda Item 6: Wrap up (Russ) ---- . There is just a little bit of work left on the documents. . Randy Presuhn reiterated that he needs text the week following IETF to get the changes to the list, otherwise it will be delayed due to vacation. . The area directors will huddle on future work items. . Please submit more deployment reports.