Minutes of the SNMPv3 Working Group Minneapolis IETF Friday, 19 March 1999, 9:00 AM Minutes: - Bob Stewart, edits: - Russ Mundy The chair, Russ Mundy called the meeting to order and began with mutual self congratulations on the IESG approval of our core documents for Draft Standard and the introduction document for Informational. The documents are in the hands of the RFC Editor, waiting to be issued. We reviewed the published agenda and made no changes. These minutes follow that agenda. Rob Frye gave a presentation on the coexistence document. His slides, available from the IETF proceedings, contain the bulk of his points. The following points received his particular emphasis or group discussion. The major remaining issue was Counter64 behavior for SNMPv1, with the following major points. A general mechanism for data type extensibility is out of scope. Rob overviewed the problem and available options. Rob explained the editors' proposed solution but noted it had a serious problem of requiring proper error handling in old, existing application code. Rob then confirmed the following points of consensus regarding an acceptible solution: . It should cover multilingual systems. . It should cover proxy. . It should be for direct access or proxy. This is a strong should since the major difficulty is regarding proxy for an SNMPv1 application to an SNMPv2c/SNMPv3 agent, which is considered a minor situation. . Get, GetNext, and Set should operate the same direct or proxy if practical. . Notifications should operate the same direct or proxy if practical. . In general SNMPv1 applications can handle OPAQUE objects but do not drill into object contents. . NetworkAddress as an index is a problem but of little concern as the only standard MIB where it appears is a deprecated section of MIB II. The coexistence documenet will say that this is covered simply by including a constant 1 as an index field in front of an OCTET STRING network address. . We should not address general extensibility of data types. During this discussion there was a suggestion from the floor (from Bob Stewart) on how to handle the one sticky case for the preferred solution of treating Counter64 as not in view. We then discussed that suggestion. The problem is when an SNMPv1 application sends a GetNext request through a proxy to an SNMPv2 or higher version agent and the proxy gets back a Counter64. In that case the proxy must iterate the request with the agent until it gets past the Counter64, a potentially long, messy, expensive process. The proposed solution is to tell network administrators who see this problem to solve the inefficiency by defining for that application's community a view that does not contain the Counter64, making it truly not in view via access control, thus keeping the necessary iteration within the agent. In addition to this, a proxy that does iterate should push the last subidentifier of the offending object to its maximum value to avoid useless iterations, then re-request all data. The editors accepted this proposal, to be added as implementation and deployment notes. In addition the editors' proposal to return genErr was changed to noSuchName and we decided to follow standard not-in-view procedure and drop notifications going out as SNMPv1 but coming in with Counter64. We then moved on to what needs to be updated in RFCs 1905, 1906, and 1907 for them to go to full Internet Standard. They need some clarifications and an editorial pass. They will not be open for general changes. The goal is to go from Draft Standard to full Standard. We need to adjust terminology similar to what was done for SMPv2. This should be pervasive if not too painful or otherwise a front-end paragraph. Changes need to be clean, clear, and simple. Randy Presuhn, Dave Perkins, and Keith McCloghrie volunteered on the spot. Others provided a maybe, and the need is to be mentioned on the mailing list. The next major point was the need for an applicability statement. Russ reported that Scott Bradner says our present documents are sufficient in that regard. There was some sentiment that we might need something along the line of what it means to implement SNMPv3, but we decided to wait and see. We then discussed wether we needed other major documents on deployment or implementation. - A deployment document would capture what deployment strategies and techniques were intended and expected by the designers. It should include the view of the operations people. We decided we couldn't do that now but perhaps some of us could work with the early deployers. - As to an implementation document, we noted that there are now plenty of implementations without one and that it would be hard to find time for the working group to develop one. The working group consensus was that this item should be dropped as a working group item, perhaps leaving it to The Simple Times. The next agenda item was the work schedule. The coexistence document will tentatively have a new draft by 30 April. The update team for the old RFCs will provide a sense of the problem by 26 April. Next on the agenda was a charter update. This will be done after the update team's report, with Russ providing an early pass to the Area Directors. We then had an informational presentation from Ken Hornstein on his Kerberos for SNMPv3 security research project. He indicated this was an interesting experiment. It's a big change from SNMP's traditional independence from other protocols but has some benefits. We decided to revisit this approach after further research work. There was a question about how it would apply with AgentX. As a final note, Bob Stewart reported that Cisco is now shipping SNMPv3 in IOS and we issued a general call for people to send product ship reports to Juergen Schoenwaelder for inclusion on his SNMPv3 web site and for The Simple Times.