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

Draft minutes from EOS WG meeting in London

See attached text file. Please send any comments to the list before Wednesday.


Cheers, /gww

Final minutes of the EOS WG meeting

IETF-51, London, England, August 7, 2001, 9:00 - 11:30

Minutes by: Dave Allan and Glenn Waters
Minutes edited by: Glenn Waters


Chairs:	Dale Francisco <dfrancisco@acm.org>
	Glenn Waters <gww@nortelnetworks.com>

5 	Chairs		Introduction / Agenda bashing / Minute takers / Blue sheets

15	Sharon Chisholm	Review the requirements email from May 24

10	Sharon Chisholm	Extended Protocol MIB

15	Bryan Levin	SNMP Bulk Data Transfer Extensions overview
	David Battle	draft-ietf-eos-snmp-bulkdata-00.txt
15	Lauren Heintz	Status of current Row Ops draft

 5	Matt White	Status of the OID Compression draft

15	Glenn Waters	Charter review: discuss milestones and moving forward

30	All		Open discussion

 5	Dale Francisco	Wrap up: next steps / collect blue sheets


Sharon Chisholm - Requirements discussion
- slides presented
- Mike: what is the improved error reporting requirement about?
  Sharon: to be further fleshed out
- Steve Moulton: list of requirements was meant as talking points for
  the list/meetings and not for an RFC; requirements are not prescriptive
- Jeurgen: efficient in the overall agents is important; not so
  important to be efficient on the wire
- Jeff Case: what is the compliance column for? Sharon: explained the
  yes/no/maybe values in the column as: Yes is there is rough consensus
  that we want to meet the requirement, maybe is some consensus, no is
  no consensus.

Sharon Chisholm - Extended protocol MIB
- slides presented
- discussion of whether need to have complete rows sent in a set
  o Andy Bierman: mentioned the cases where sets are hard -
    particularily around set split across multiple PDUs
  o Dave Perkins: can put additional constraints on RowStatus; just do
    proper MIB design. A comment was made that PDU size limit can be a 
    problem with large sets.
    Sharon: donít completly disagree with Dave's statement
  o Mike McFadden: most MIB modules donít provide enough text to provide
    interoperable implementations.
    There's a wide variety of responses to set situations that an
    application needs to handle. Most MIBs do not contain enough text to
    describe interoperable implementations.
  o Clarified the removal of traditional sets: not really removal just
    that they would not be supported for some of the MIBs


Bryan Levin: Bulk Data Retrieval - implemented as MIB extensions
- slides presented
- discussion around returning MIB symbolic names from the agent: most
  agents donít have this information -- can be optional from the agent and
  just use the OIDs
- username/password is stored on the device: this is a security problem;
  donít want to stick the passwords for a file server out on a device;
  maybe the server can contact the agent to initiate the upload; not an
  easy problem; one suggestion: sign the file with a digital certificate
  so that the authenticity of the uploaded file can be verified (use
  anonymous FTP); many carriers donít mind having a configured password
  on the devices; take the discussion to the list
- concern around the footprint of the implementation: not necessarily
  for small boxes;  bulk-data is what the draft is about and only larger
  boxes will require the features that are in this draft so foot print
  should not be a big issue
- file versioning as presented is overkill; find a way of making is
- suggestion for storing the files on the device and have the server
  request the file periodically; this solves the versioning and
  authentication problems; the agent knows best when the data needs to
  be pushed since it knows when the buffers are getting full
- Jeff Case: order of magnitude performance improvement over what?
  Compared with a GetBulk, using a 10K row table transferred compressed
  with gzip and using SCP on a 128K ISDN link; lets get some better
  comparisons and post to the list


Lauren Heintz -- Row Operations
- slides presented
- Dave Battle: likes that can be able to interwork with subagent/proxy
  agent technology
- Jeurgen: interesting approach but hard to decide if the approach is
  good before can decide if there is concensus when the document is not
  complete enough
- Mike/Dave Perkins: RowStatus is sufficient as is -- just write some
  better text descriptions that state how the row is allowed to be 
- Glenn: the document is purposefully not complete -- trying to
  understand if there is enough consensus around this approach before
  writing lots of text and making the work complete.

Matt White -- SNMP OID compression
- document is from last April, very little response. Jeurgen commented
  on relative efficiency of ODC vs. OPC described. Robery Story had
  comments on when to use OID compression.
- please post comments to the list.


Glenn Waters - Current Status and Charter Discussion

We're a fair bit behind. We're one revision behind as a loose
description of the status. Overriding comment is list has been extremely
quiet. We need more comments and more discussion to figure out next
steps. Open discussion time now.

One of the big problems is not enough to discuss. Bulk data transfer
just appeared. Rowops needs detail before we put our teeth into it. Need
implementation details.

Any commments on the requirements, are we hitting the mark?

I was trying to figure out what problem we're addressing. Did an
implementation of the get column stuff. it was fast and dirty so CPU
usage is bad, on the wire transfer is good. But this was not our day

Sharon, was given a rough priority on effeciency, simplicity, on the
wire transparancy, but there is a priority on transition, and proxies
etc. Which is the real priority. A: interoperability period... Q: who
thinks being able to translated from tradops to EOSops is a high

Higher level hum question, interest in rowops. Example of time invested
in contributing that black holed and how hahrd it is to motivate
interest in a vaccum.

Back to rowops, no hums either way.

Review of docs and 6 months of mailing list shows lots and lots of

Real problem is slight demand of the operational community, not
complexity of implementation. Benefit of this work is purely to MIB
implementors. (for "write MIB", substitute "implement agents").

As a participant, finding time for EOS is difficult. This is also 5
years overdue,and has lots of competition (COPS etc.). I can;t tell what
is happening in the industry. The overall picture is a mystery.