SNMPv3 Meeting Chair: Russ Mundy, TIS Reported by: Shawn A. Routhier, Epilogue Russ opened the meeting with the agenda and a hope that we would be able to finish this meeting early. The agenda was: Status Report on Current IDs, Proposed Additional WG Docs, SNMPv3 Implementation Status Reports, Potential Interoperability Demos and, finally, Discussion of Charter Revisions. - Status Report on Current IDs: The current ID's were approved as proposed standards with a clarification requested for the USM document. The approved IDs were: <draft-ietf-snmpv3-next-gen-arch-07.txt> <draft-ietf-snmpv3-v3mpc-model-07.txt> <draft-ietf-snmpv3-appl-05.txt> <draft-ietf-snmpv3-usm-04.txt> <draft-ietf-snmpv3-acm-05.txt> Thanks was given to the workers who put in large amounts of time and effort producing the specifications. - Proposed Additional WG Documents: We discussed what, if any, additional documents were required. The proposed additional documents discussed were: -- an SNMPv3 overview, -- a spec that defines handling of v1/v2c by v3 -- updates to RFCs 1901 - 1908 primarily for the SMI. -- We also discussed standardizing RFC2089. The consensus was that an overview (road map) document was desired. This would describe how the pieces relate to each other for SNMPv3 and the 190x series, it also might contain applicability statements. The AD (Mike O'Dell) stated that due to the importance of the information that might be contained in this document, it might be appropriate for it to be a standards track document. We shall examine RFC1908 and RFC2089 and see if those documents can be used to deal with handling v1/v2c by SNMPv3. As neither of those docs address adding v1/v2c into schemes such as the one for view control, we may need additional text to cover such issues. We moved onto discussing what changes might be required for 1901 - 1908. The changes discussed were mostly not caused by V3 but were from other areas. We had: IPv6 related items, such as textual conventions, 64 bit integers for RMON, and the drafts that Dave Perkins had published earlier in 1997. The most urgent of these is the 64 bit integers for RMON. Some concern was expressed over the effects these changes could have on the elevation potential of 1902-1908. The AD (again Mike) notes that if backwards compatibility is preserved we might still be able to upgrade the documents (1902 - 1908) from draft to full. The end result was that we need to think this through and determine what minimizes the end to end delay but there don't seem to be any show stoppers. Russ is now looking for editors for various documents, he also will be talking with Dave Perkins about Dave's previous posts for modifying the SMI. - Implementation Status Reports: Several groups had implementations in various states, although no interoperability testing has been done as yet. Dave Levi (SNMP Research) has been implementing for some time and hasn't found any problems with the docs, but he also pointed out that due to his involvement writing the docs he isn't the best candidate for reviewing them. He also hasn't run into any major technical problems. One item he noted was related to unknownEngineIds; there is some text that says you are supposed to increment unknownEngineIds but requires you know whether or not you are authoritative to take the correct action. It was not clear if (or how) you could determine whether or not you were authoritative at that point in the text. Ylian Saint-Hilaire, Omar Cherkaoui (University of Quebec in Montreal) have implemented most of the modules in Java. They have been using debugging versions rather than field tools and have not added security or things related to it yet. For them modularity was a prime objective and they have chosen to follow the ASIs when implementing the code. They allow live attach and detach of security and application modules. They have tested all input/output of SNMPv3 packets, and have partially tested input/output for their modules. They do plan to make it publicly available and some information may be found at "http://atm.teleinfo.uqam.ca/snmp". Bert Wijnen (IBM Research) has started work and plans to include security and acm but not including the proxy stuff at the start. He doesn't intend to follow the ASIs while coding. Randy Presuhn (BMC), they are early in the implementation of v3 but looking at it from an agentx perspective. They feel there may be some problems with the key change objects and the way they are accessed. There is some discussion about why the key change objects are the way they are (basically to allow for a simpler ACM table while allowing a user to change his own keys). Shawn Routhier (Epilogue/ISI) has started work, they will be starting with the security features and may defer the proxy. They also won't be using the ASI's while coding. Juergen Schoenwaelder (TU Braunschweig) has started an implementation, but has found several items that were unclear. He is somewhat less optimistic than Dave Levi and Ylian Saint-Hillaire. There was a small amount of discussion about the testing of the remote configuration of access control and security items. The one group that has an implementation also has a tool to do this and thought that it was working well. - Interoperability Demos: We then turned to the possible timing and location of interoperability demos. Dave Levi mentioned that there has been some contact with Interop about doing something like a technology showcase in the Las Vegas Interop (May 5-7 1998). Some 7 or 8 groups are interested and may be able to participate. Other suggested and possible testing options include: BMC in either Houston or Sunnyvale, TIS in mid to late 1998, somewhere else in the DC area around the end of March (next IETF), and Interworking Labs. (Editors note: Interworking Labs has hosted various testing events in the past and so their name was mentioned as a possible option. However they were not available at the meeting to discuss if they would be able to help with such an event). There were several general comments about testing. 1) Interop tends to be more of a marketing demo while other testing may be more of an engineering bakeoff. 2) Testing that isn't under non-disclosure isn't all that useful 3) Some amount of testing should be done over the internet using well known addresses. 4) Keeping a log (or web page) of the unclear issues as well as sending mail to the list will help in finding and correcting them. 5) We should probably have a test plan for both MIB related and security related items. Dave Perkins volunteered to help write one of these two plans. With all this in mind we are targeting a bakeoff test for sometime around the March IETF. - Discussion of Charter Revisions: Our current deliverables were completed 4 months early and it is time to decide what, if any, changes should be to the charter. The overview document now has a target date of Feb 1998 for the first ID to be posted on the list, this would be similar to RFC1901. There was some discussion if 1901 will be replaced, the answer seems to be no, both will continue to be required. There is also a desire for a v3 to v1/v2c coexistence spec similar to and possibly replacing 1908. We discussed but did not reach consensus on a recommended status for V2C. This should be discussed further on the list. Russ intends to identify volunteers to perform as editors for the docs shortly after Christmas (Dec 25) and then, in conjunction with the IESG, will start work on revising the charter. This was the end of the items on the formal agenda. - Other Items: We started a discussion of items that had been deferred pending resolution of the security issues. The issues brought up were: SMI issues that were previously posted, 64 bit integers, floating point (single & double precision), something better than GetBulk, and some sort of ACTION verb perhaps combining GET/SET into one operation. The floating point data types may be handled via some sort of textual conventions rather than creating a new base type, but we need to determine if the conventions should be done now as part of the v3 work or if they can wait until there is a MIB that needs them. It was pointed out that we had looked at adding a better GetBulk and an action verb some time ago and decided against them. If things haven't changed we may not need to do anything for them now. Final Item: Russ wanted to give one more round of applause to the editors of our current set of documents.