IETF 53, Minneapolis, MN. Minutes from the EOS WG Meeting -- March 18, 2002 Meeting was chaired by Glenn Waters. Co-chair for the meeting, Dale Franciso, was not present. Minutes taken by Randy Preshun and Glenn Waters; edited and submitted by Glenn Waters. Introduction -- Glenn Waters Other ideas and WGs around the IETF are causing an impact on the EOS work. When the work started out around 18 months ago SMIng had a direction that was more around changing syntax and the Operators’ draft did not exist (draft-xxx). These items are causing grief for EOS since these other items are taking mindshare and desire away from the current EOS charter. Discussion of this topic will take place after the presentations. MO Aggregation: Programming MIBs -- Glenn Keeni Presentation given (slides included in minutes). Q: what about PDU size? A: application sets limit of variable binding value's maximum size. Q: can value be retrieved in pieces? A: mib defined puts the values into rows. Q: How does access control work since there is third party access to the objects? A: Needs some work. Q: How is this different from other MIBs? A: The behavior is governed by application. Q: Other MIBs such as disman, rmon, esp. expression have similar functionality. A: This MIB has a narrower focus. Q: What about looking at "entire" table, which raises questions of how to deal with row creation and deletion? A: This proposal doesn't address issues of monitoring an entire table, since it must be explicitly configured with all the instances to be monitored. Q: What happens when specific instance being monitored disappears? A: Need to look at this issue. Observation: Looks like the user history table in RMON, except this packs values into a variable binding. Sampling begins when MIB configured, so nothing special about the get/response sequence. We may want to look at a more generic solution to this problem. Resolution: No action to accept this work at this point in time. Further discussion to be taken to the mailing list. SNMP Extended protocol MIB -- Sharon Chisholm Presentation given (slides included in minutes). Open issues: - no enriched error checking, thinking that this would go into a potential revision of RFC 1905 - currently no extended protocol operations making this work unnecessary until new protocol operations exist. Bulk data retrieval -- Bryan Levin Presentation given (slides included in minutes). Q: When do snapshots go away? A: requires NMS to do it. The transferred file? may need more config to manage these. Discussion arose around whether the transfer table could be normalized. Some thought optimizations could be made, others thought what was there was fine. Further discussion on table design on the to occur on the list. Comment: should there be a wall clock timestamp on the data? Discussion: The need for this feature was thought to be low, more discussion to take place on the list. Comment: symbolic names cannot be required since agents in general do not have access to the symbolic names. Must be able to use OIDs. Comment: There are security issues since the data is collected as "root" and the VACM privileges are ignored. Discussion: this issue must be addressed. Comment: The MIB requires storing userids/passwords in the agent so that data can be pushed to a FTP server. This is a security concern that will be sufficent to block this MIB at the IESG. We can request that a security advisor be assigned to help with the security aspects of the MIB design. It was noted that the DISMAN MIB has similar issues and they have been solved there. Discussion around atomicity of the snapshots. The draft should comment on the what can be expected in the snapshots; for example are the snapshots better than just querying from the manager to get the data. Open Discussion Comments from the chair: Status of the group was posted to the list about 2 weeks before the meeting. There have been no responses to the queries on the list. The work that is that furthest along is the Bulk Transfer MIB. All other work does not have any traction. The "RowOps" proposal should be tied to the work in SMIng as the decisions there may change the types of RowOps that the EOS group may define. The other development in the IETF that has occurred since the EOS group was chartered is that the Operators draft has been published. It is not clear if the EOS group should do anything to accomodate their draft. So, what *should* the next steps for this WG be? In particular what should be done with RowOps? Jeff Case commented that he could revive some work that he has done with Steve Moulton and Sandra. The work would line up with the SMI-DS work being done in the SMIng WG. General consensus was that we would try to get that work going and if there is no significant progress by the next IETF meeting then the group should consider dropping RowOps from the charter. Some discussion around the bulk and MO proposals that exist and that there is some overlap in what they accomplish. Glenn will summarize the issues to the list so that we can elicit the direction that this WG should take. Comments from the Area Director: The AD does not want this WG to linger much longer without progress. The AD also does not want this group to become an extension that works on follow up work as a result of any SMIng or Operators work. If that is needed we can form appropriate WGs when we get to that point. The AD would want this WG to try and complete the limited work items that are in the WG charter. If you want to drop some, fine. But either complete or remove the current workitems, or run the risk to be shot down as a WG.