SNMPv3 Working Group 49th IETF San Diego, CA, USA 12 December 2000 Chairs: Russ Mundy (mundy@tislabs.com) Dave Harrington (dbh@enterasys.com) Area Advisor: Randy Bush (randy@psg.com) Notes: Shawn A. Routhier (sar@epilogue.com) Mailing Lists: General Discussion: snmpv3@lists.tislabs.com To Subscribe: snmpv3-request@lists.tislabs.com Archive: ftp://ftp.tislabs.com/pub/ietf/snmpv3 - SUMMARY: The SNMPv3 Working Group met once for one hour during the 49th IETF. There were approximately one hundred attendees. The Working Group generally followed the agenda that was published on the list and the IETF Web site. Several deployment reports were presented and discussed during the meeting. During the Review of Document Status discussion, the sense of WG members in attendance was that we have sufficient experience with the specifications which are at the Draft maturity level that the WG should finalize the remaining details and recommend to the IESG that the current Draft specifications be advanced to full Standard. The activities needed to do this will be done as quickly as possible. - DEPLOYMENT EXPERIENCE AND REPORTS (SCHEDULED FOR 20 MINUTES): -- We received several reports about deployment experiences. Carl Kalbfleisch from Verio sent in an e-mail report. The portion of Verio that Carl works in is trying to move to SNMPv3 but the going is slow. As part of this move an RFP that requires the inclusion of SNMPv3 should be appearing soon. Tom Lehman presented a report from CAIRN. They are attempting to do more effective monitoring with SNMPv3. Today they mainly use web servers with ssl to go to ssl servers which run scripts to collect and manipulate information. The current versions of the scrips use RSH to collect the information, they would like to modify the scripts to use SNMPv3. Tom presented a slide with a CAIRN diagram which gives a better illustrations of this deployment (the slide will be submitted for inclusion in the IETF proceedings). The CAIRN web site is: www.cairn.net The contact person for this deployment is: Jaroslav Flidr Wes Hardaker (hardaker@tislabs.com) presented the results of the Net-SNMP (fromerly UCD-SNMP) survey that he ran. They were attempting to get information on what people are using SNMP for and which version of SNMP is being used. Some of the results that were thought to be of particular interest to the WG were that some folks are using v2c or v3 without using v1 and that v2c is in wide use but v3 has not yet used quite as widely. He also found that the range of the number of hosts per site was much broader for v1 sites than for v3 sites. When asked why they didn't use v3, many people stated that it was because it isn't avaialable on the equipment they use. At least some of these folks would seem to be confused since the equipment which they indicated they managed does support v3. Lastly, Wes also asked what else the respondents wanted in v3. A number of them were content with v3 as it currently exists while others did have some additional desires. The leading desires on the list seemed to be bulk transfer (mostly with some sort of filtering at the agent side). Some other confused folks were asking for security. For more information from this survey can be seen at http://www.netsnmp.org/report In another section of the meeting, a participant stated that SNMPv3 was not being considered at his company due to a lack of integration with RADIUS and the lack of easy centrally controlled management. -- Dave Harrington also presented information from several deployment reports he received by email that were focused on use of features added to RFCs 1905, 1906, and 1907. A number of these reports looked more like implementor reports rather than delployment reports but did identify use of the added features. As might be expected Dave has requested additional deployment reports, he will also try to generate a new feature list template for the core SNMPv3 specificactions that is similar to one used for 1905/1906/1907 since it seems to help collect information. We also do not need any company names, so if companies would like to send either of the Chairs a report, they can remove identifying information before incorporating that information into the full deployment report. RFC1905 New Features GetBulk Inform Snmpv2Trap New error codes Exceptions RFC1906 New Features SNMPv2 over UDP SNMPv2 over OSI SNMPv2 over DDP AppleTalk Addressing SNMPv2 over IPX Proxy to SNMPv1 RFC1907 New Features The System Group The SNMP Group Well-known Traps The Set Group -- Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de) also reported that he has requested deployment information on the Scotty mailing list. - REVIEW OF DOCUMENT STATUS (scheduled for 20 minutes): Our current document set is: Document Status -------- ------ 1905 Update Draft Standard 1906 Update Draft Standard 1907 Update Draft Standard 2570 Informational 2571 Draft Standard 2572 Draft Standard 2573 Draft Standard 2574 Draft Standard 2575 Draft Standard 2576 Proposed The full requirements for moving from draft to full are described in RFC-2026 (A poll of the WG attendees indicated that almost no one at this meeting had read these. Russ noted that it would be good for people involved with any IETF activity to read it in order to understand some of the imprortant IETF process and standards requirements of the IETF). The focus of the discussion was primarily on the specifications that have a status of Draft Standard. The requirements for advancing these specifications from Draft to full Standard are (Ref para 4.1.3, RFC-2026): A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community. In attempting to determine how to progress the various documents, we seem to have significant implementation experience with technically mature documents and a protocol that provides significant benefits. The remaining area is operational experience. In this area we have not yet put together a report. We had some general discussion about what was required in a deployment report. Randy Bush as AD indicated that we don't need a feature by feature analysis - that is required for the transition from Proposed to Draft but not for the transtion from Draft to full Standard. Significant experience is one of those things that we will know it when we see it (in the deployment reports, etc). Randy also indicated that the limited amount of information the WG has collected on SNMPv3 deployment might be a result of inadequate information collection techniques rather than inadequate deployment. In addition to known and planned SNMPV3 deployments, Wes Hardaker said that he had used SNMPv3 to manage a number of systems (around 100) at UC Davis. The result of the discussion was that the WG should move as quickly as possible with actions needed to send the current Draft specifications to the IESG recommending advancement to full Internet Standard. Updates to RFCs 1905,6,7 The sepcifications have been finished and given experience with the features in the documents, it is the sense of the working group that we have enough operational experience to proceed with these documents even though we don't have a large number of deployment reports. Once again folks are asked to file reports or, if they are implementors, to try and get their customers to file reports. When asking customers, it is also probably best to specify the functionality in use (v2c or SNMP security etc) rather than to specify the RFCs. Since the documents have completed WG last call, the co-chairs will prepare the deployment report and forward the documents to the IESG. (Additional deployment reports or information will still be very helpful for this activity.) Updates to 2571,2,3,4,5 There are a small number of edits required to clarify these documents but the list for each document is short (more or less around 5 per document). The group accepted a suggestion to send the edit lists to the Working Group mail list and ask if there are any more editorial items that are required for clarification. We can then respin the documents once more, do the WG last call, assemble the deployment report and forward the specifications to the IESG. (Again, additional deployment reports or information will still be very helpful for this activity.) - OTHER RELATED ITEMS (scheduled for 15 minutes): -- There was a discussion about implementors, implementing read-write variables as read-only. The specifcations do allow for this, possibly via the use of a conformance statement. The community does need to make clear that we want to make sure that all standards track MIBs use read-write where possible rather than making the MAX-ACCESS clause for objects READ-ONLY especially for objects that can be used for configuration. One deployer pointed out that they haven't been using SNMP for configuration in any "dangerous" areas due to a lack of security (before SNMPv3 is deployed), another pointed out that they just don't use SNMP for configuration not due to security issues but just "the way things are done". An implementor pointed out that while they don't use standard MIBs for setting all that much, they do use a fair number of enterprise MIBs that are settable. -- Finally the chairs will talk to the ADs about updating the charter and will work on the potential deadlines for various documents.