|
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
www.snmp.com/eos/mailing-list/msg00110.html
10 Sharon Chisholm Extended Protocol MIB
draft-ietf-eos-snmpxproto-mib-01.txt
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
draft-ietf-eos-snmp-rowops-01.txt
5 Matt White Status of the OID Compression draft
draft-ietf-eos-oidcompression-00.txt
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
simpler;
- 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
manipulated.
- 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
job.
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
priority.
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
stuff....
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.