The draft minutes are attached. Comments gratefully accepted. The plan is to submit the minutes on Monday April 2.
Cheers, /gww
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 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 since 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 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.