Minutes SNMPv3 Working Group Recorded by Jeff Case 47th IETF Adelaide Australia Wednesday March 29, 2000 Welcome by Russ Mundy. Introduction of new co-chair, David Harrington, Enterasys. Agenda Bashing -- no changes from agenda published on mailing list. Acknowledgement of Published RFC Updates. The publication of two documents since the 46th IETF was announced: Coexistence and transition document (RFC 2776), Proposed Standard. Diffie-Helman USM Key Management extensions (RFC 2786), Experimental. The next topic was the discussion of updated versions of RFCs 1905-1907 in the interest of advancing them from Draft to Full Standard status. Randy Presuhn made a presentation on the very few remaining open issues with respect to the drafts which had been issued before the meeting: draft-ietf-snmpv3-update-mib-01.txt draft-ietf-snmpv3-update-transmap-01.txt draft-ietf-snmpv3-update-proto-01.txt RFC 1905 bis: there are no known outstanding open issues RFC 1906 bis: there are two related open issues related to rfc1157 domain The issue can be researched by looking at ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/issue1906-06.html The -01 document leaves the text largely unchanged. However, there were at least two comments on the mailing list that the text should be made more clear or the rfc1157 domain should be deprecated. None of the people who raised objections to the text found in the -01 draft were present and the objections were posted after most of those present at the meeting had left home, both of which made discussion somewhat difficult. Keith McCloghrie encouraged the group to come to some closure at the meeting. Randy Bush said that we could not make any final decisions today -- that everything must be decided on the list. The group did take a straw-man vote among those present to get a sense of the working group. There was no objection to advancing the text as published in the -01 draft. The final decision on this issue was deferred to the mailing list. RFC 1907 bis: there is one set of related open issues related to the internationalization of character strings and UTF-8, specifically related to the MIB objects sysDescr, sysName, sysContact, and sysORDescr. The issue can be researched by looking at ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1907/issue1907-18.html Jeff Case argued against the change, reiterating what he had posted to the list. He suggested that we have 3 basic choices (really 2): 1) leave these objects as they are in RFC 1907, but create additional objects that contain localized variations of objects such as sysName and sysContact, etc 2) make the changes as proposed in the -01 draft 3) do neither -- but expect to get the document thrown back in our faces when it reaches the IESG -- not recommended Jeff stated his strong preference for option (1) and explained why he thought that options (2) and (3) were unworkable. Bert Wijnen pointed out the need for this change as proposed in the -01 draft (He spoke in favor of option 2). Bert said we have made similar changes before (Entity MIB). Randy Presuhn stated his preference for the text in the -01 draft (He spoke in favor of option 1). Mike St. Johns: This violates the SMI. Use duplicate objects. (He spoke in favor of option 1). Ran Atkinson: Use duplicate objects. (He spoke in favor of option 1). Participants were encouraged make sure their positions had been posted to the mailing list. A suggestion was made to take a straw poll. After much time and flagellating, we got through the poll. Q1: Retain DisplayString object semantics as found in RFC 1907 (i.e., part of option 1) sense of the room is yes Q2: Create new UTF objects in parallel (i.e., part of option 1) (the question did not distinguish between in parallel in the same draft or in a separate draft) sense of the room is yes Q3: Deprecate existing objects consensus is no Q4: Change semantics on objects to UTF8 (i.e., part of option 2) sense of the room is no It was again observed the the Entity MIB WG has already acted in a way that too the opposite approach to the above conclusions. Bert observed that we cannot add objects to the MIB and advance. Others observed that the information module containing the new objects need not be in the same document. The consensus of the room was for option 1, but based on Randy Bush's earlier input, we were unable to come to a conclusion. Correspondingly, the issue was deferred to the list for the final decision. The next topic was SNMPv3 Deployment Reports Russ Mundy, co-chair reported on four sets of deployment experience he has become aware of. Small testbed at NAI labs Verio - Carl Kalbfleish SNMP Research MG-Soft Reports Significant v3 Product Sales to "Users" He called on Carl Kalbfleish, Verio, who reported on the limited work done to date in his test lab environment. Others were invited to make reports of their experiences. Ran Atkinson reported on the DOCSIS cable modem standard. Testing is happening in the lab against cable modem products. Testing is occuring with agent products built using products from two of the leading toolkit vendors. One vendor indicated that he knows of others in the room that have SNMPv3 successfully implemented (and deployed) but continue to be shy about coming forward and reporting on it. It is somewhat unknown why these people do not want to make their reports public. Deployment experience should be sent to snmpv3@lists.tislabs.com or Russ Mundy or Dave Harrington. It was suggested that people may want to be on the lookout for a large United States Postal Service (USPS) Request for Proposals (RFP) which is rumored to contain a large SNMPv3 component. The next topic was SNMPv3 Q & A Document Discussion: David Harrington Dave Harrington had proposed on the list that we create a question and answer document. So far, he has received only a few comments on the proposal. The purpose of the Internet Draft would be to cover the following: Frequently Asked Questions What does SNMPv3 Do? Alternatives to SNMPv3 Implementation Concerns Deployment Concerns Recommended Practices This document would be similar in some ways to the document from the IAB on the case for IPv6. He wants to be try to answer some of the questions people ask when they go to deploy or implement SNMPv3. Costs/Benefits. Feasibility Analysis. Resource Planning. Resure[sic]/Integration Studies. Buy/Develop Decision. How does SNMPv3 benefit my customer? What features can I sell my customer? Alternatives. Why not SNMPv2c, Ipsec, WEBM… Implementation concerns – code space, etc Deployment concerns. How hard is it to manage? More operators? Interoperability. Co-existence with other management v1, v2c, cli, radius, cops, cmip, tmn Recommended Practices. Once there is a view based control mechanism? How do you use it? Routing configuration verses sysContact. Security Parameters. A/C statements, sysORTable (to determine the capabilities of devices). As release notes See Dave's presentation slides for additional detailed subpoints -- sorry, but we were unable to keep up here. Dave is looking for looking for volunteers to each write small portions of the document. The next topic was Promoting SNMPv3 New/Updated Implementations were discussed. SNMPv3 is now shipping in RedHat Linux and FreeBSD. Find information on Juergen's Web site: http://www.ibr.cs.tu-bs.de/projects/snmpv3 There is an interest in identifying organizations requiring and buying SNMPv3 and other promotional ideas. IWL has offered to host additional interoperability testing if there is sufficient interest. Bert (with AD hat on): promotional activities that smack of marketing should happen outside the IETF. Randy Presuhn: should document the experience with WinSNMP and snmp++ to support SNMPv3. There was some question about how complete those works are. Dave Perkins: is getting questions from cable modem customers about how to use SNMPv3. He has SNMPv3, but has not turned it on, because he does not have sufficient printed information. Straw poll: do we want to do interoperability testing? No strong support. Steve Waldbusser: thinks that we are past the time where interoperability testing is either necessary or useful -- may be counterproductive by sending the wrong message -- indicating the technology is less mature than it is. Bert: sees no need for interoperability testing for promotion. Randy Bush sees no strong need for additional interoperability testing. The next topic was Discussion of Related Items Several potential additional Working Group items were identified and discussed. One question articulated by Co-chair Mundy is: What additional information and specifications that would encourage greater deployment and use of SNMPv3? Several additional security components were discussed in this light: Diffie-Helman USM Key Management extensions on standards track Triple-DES protection from disclosure Kerberos There was no strong interest at this time in bringing new work into the Working Group with respect to additional security modules Jeff Case suggested that it might reduce barriers to adoption and deployment if we invite an expert speaker to come to a future meeting and present tutorial information on the impact of recent changes in export control regulations. Next, there was an attempt to gauge interest in new work items to be considered either in this Working Group, or a new one. A large number of possible work items were presented: Recommended Practices Views for Common MIB Objects read-only versus read-write routing configuration versus sysContact Security Parameters (USM, VACM) Usefulness of A/C Statement Management Extensions for SNMPv3 Applications Bulk Transfer OID Compression Operations on PDUs New (High Capacity) Datatypes New SMI Complete Information Modeling Moving topics from ongoing IRTF work to new IETF work A total of eleven work areas were presented. A straw poll was taken on several of these topics. bulk transfer sense of the room was in favor of looking at working on it OID compression sense of the room was in favor of looking at working on it operations and pdus sense of the room was in favor of looking at working on it The room became somewhat restless, in part, because attendees were being asked to take a position on questions they did not fully understand. At this point, Ran observed that we need to stop enhancing, fixing, and extending and leave things stable so the market can catch up. Randy Bush responded: we cannot remain static -- we have had pressure for some changes building for some time ... therefore we must pick the items for our future work lists *_very_* carefully. The opinions were expressed that our next work items need to incorporate management features, not merely more security address long-standing issues produce solutions compatible with snmpv3 be clearly focused projects At this point David Harrington got his laptop working again which allowed him to project his presentation. Proposed Phase 1 efficient data transfer bulk transfer improved table retrieval OID compression / suppression Proposed Phase 2 new data types and operators need to the understand problem Proposed Phase N Non engineering ready Focus not well understood Not sure which wg should handle these May be IRTF efforts There was no attempt to propose that all work be done here. Projects that should be reviewed in other places including DISMAN Remote intelligence Standardized script language: DISMAN or SNMPCONF The meeting concluded when we ran out of time at 5:30 pm. Respectfully submitted, Jeff Case (Thanks also to Carl Kalbfleisch who provided a second set of notes which helped in the "hurried" places.)