See attached text file. Please send any comments to the list before Wednesday.
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 <email@example.com> Glenn Waters <firstname.lastname@example.org> 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.