[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IETF 53 Draft EOS WG Draft Meeting Minutes

Title: IETF 53 Draft EOS WG Draft Meeting Minutes

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

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
  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
  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 
  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.