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

RE: IETF 55 EOS WG Minutes and Presentation



Title: IETF 55 EOS WG Minutes and Presentation
Not sure that the question on "interest in this work" at the bottom is
properly represented.
 
I came away with:
- Wes is willing to implement
- Some vendors would consider it, but would have to rely on their stack vendor to
  do the implementation first
- Some were not sure there was benefit for their company
 
I did not get a warm feeling at that point. In fact I was quite disappointed with the
response as to how many want to "help", "review", "implement", "use" this
technology.
 
Was that just me?
 

Thanks,
Bert

-----Original Message-----
From: Glenn Waters [mailto:gww@nortelnetworks.com]
Sent: donderdag 5 december 2002 20:09
To: eos@ops.ietf.org
Subject: IETF 55 EOS WG Minutes and Presentation

Comments please.

Thanks, /gww

------

Draft minutes of the EOS WG meeting
IETF-55, Atlanta, Georgia, Wednesday November 20, 9:00 - 11:30

Minutes by: Glenn Waters
Minutes edited by: Glenn Waters
Meeting chaired by: Glenn Waters

A presentation on the status of the current draft was given by Wes Hardaker. See presentation for details. The minutes just note the questions and responses. No other items were on the agenda.

The current draft is moving forward. Here are some specifics:

- ASN.1 defined
- much of the formal text is in place
- feedback needed on write support

- SMIv3 almost supported
- Cursor field added to GO(R)Ps
- Search-criteria now support AND/OR/NOT
- Errors are now SEQUENCE OFs such that
  o Multiple errors can be returned for a given request
  o No errors is only a 2 byte empty SEQUENCE OF tag

- Does this need to support SMIv3?
  - Yes, this needs to coupled this to SMIv3

- support for large amount of data is very important
  o large sparse tables, augmented tables, millions of rows need support for
- Bob Moore: want to see support in this draft for SMIv2 not just SMIv3

- notification support - should we do it?
  o Yes so that we could have a stand alone document

- return search-criteria field:
  o Only one opinion offered: no
  o Wes will not do this unless some compelling reason comes alone

- desire for complex operations such as "get foo when columnX > columnY + columnZ
  o Expression MIB could do this; don't do in protocol
  o Too much to put into the agent

- augmentation retrieving
  o issue is that joins are hard in the agent
  o biggest issue is when different augments support different rows
  o one opinion is to put this in the agent
  o is ACL an issue? - need to be considered
  o we should do joins of augmented tables was the general consensus of the room

- augmentation searching
  o Yes!

- comment: want to make sure that the new write operations can store
  a complete configuration
  o this is one of the design goals
  o how could we "get" all the data from the agent that is the config and
    is not the other stuff such as stats, counters, etc - want to be able
    to do a system level backup of the configuration

- there is customer interest in this work
  o this was stated by a couple of vendors (3 vendors)
  o there is implementer interest in this work
  o one person said that their company is not interested in this work