Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05129; 2 Nov 94 9:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05124; 2 Nov 94 9:47 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa07001; 2 Nov 94 9:47 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma002541; Wed Nov 2 09:20:31 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa23674; 2 Nov 94 9:18 EST Received: from sol.tis.com by magellan.TIS.COM id aa23670; 2 Nov 94 9:04 EST Received: from gatekeeper.roche.com(151.120.84.6) by relay via smap (V1.3) id sma002370; Wed Nov 2 09:05:05 1994 Received: by gatekeeper.roche.com (5.65/fma-120691); id AA06904; Wed, 2 Nov 94 09:05:01 -0500 Received: by mailgate.roche.com (5.65/fma-120691); id AA24306; Wed, 2 Nov 94 09:04:37 -0500 Message-Id: <9411021404.AA24306@mailgate.roche.com> Received: from rnisd0.enet; by inet.enet; Wed, 2 Nov 94 09:05:00 EST Date: Wed, 2 Nov 94 09:05:00 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paduru Amar Reddy To: rnisd0: ;, tis.com@rnisd0.dnet.roche.com, "@list.lis" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Mmdf-Warning: Parse error in original version of preceding line at magellan.TIS.COM Apparently-To: snmpv2@tis.com, info-snmp@ames.arc.nasa.gov, hnms-users@maillist.cs.orst.edu, snmp@psi.com Subject: Software distribution package on the net. Hi I know, someone on the net previously posted a similar question before, but I never read any reply on that. i) Is there any software distribution package available on the net, preferably for PC based networks (Netware ). For unix is also fine. ii) If not on public domain, private applications which are not too expensive is also helpful. iii) If any one on the net tried these before, I really appriciate your comments, notes and other experiences with them. Thanks in advance. You can send mail to me directly. reddyp@rnisd0.dnet.roche.com Amar Reddy Ph: 201-235-3480 (W) Fax: 201-235-3865.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25410; 3 Nov 94 3:26 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25406; 3 Nov 94 3:26 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa28415; 3 Nov 94 3:26 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma014290; Thu Nov 3 03:05:32 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa09112; 3 Nov 94 3:00 EST Received: from sol.tis.com by magellan.TIS.COM id aa09108; 3 Nov 94 2:54 EST Received: from dworkin.wustl.edu(128.252.169.2) by relay via smap (V1.3) id sma014254; Thu Nov 3 02:55:25 1994 Received: (from ehab@localhost) by dworkin.wustl.edu (8.6.8.1/8.6.6.yuck) id BAA02417 for snmp2@tis.com; Thu, 3 Nov 1994 01:57:22 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ehab Al-Shaer Message-Id: <199411030757.BAA02417@dworkin.wustl.edu> Subject: Basic question To: Mailing List SNMP2 Date: Thu, 3 Nov 1994 01:57:21 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 586 Hi, I have the following basic question about the snmp operation: In standard SNMP implementation, How does generally the agent update its MIB ? I believe. to answer this question, there are three choices: a- Updates (fetch) the value of the object only when manager requests it. b- Agent goes over all MIB objects frequently in a round robin fashion and update each one. c- it up to the implementor to specify the fetch period of the agent. Is that right? which is the right one? Thank you and appreciate your help. -ehab PS. any reference (RFC, book, etc) is useful too.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07238; 3 Nov 94 14:57 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07234; 3 Nov 94 14:57 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa14052; 3 Nov 94 14:57 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma019619; Thu Nov 3 14:23:07 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa12490; 3 Nov 94 14:21 EST Received: from sol.tis.com by magellan.TIS.COM id aa12486; 3 Nov 94 14:11 EST Received: from merit.edu(35.1.1.42) by relay via smap (V1.3) id sma019526; Thu Nov 3 14:11:46 1994 Received: (wbn@localhost) by merit.edu (8.6.8.1/merit-1.0) id OAA21965; Thu, 3 Nov 1994 14:11:41 -0500 Date: Thu, 3 Nov 1994 14:11:41 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Norton Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Subject: SNMPv2 sessions To: snmp2@tis.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Bob Stewart - What are your thoughts on what to do during each of the SNMPv2 sessions scheduled throughout the week at the IETF? Also, for those who wish to contribute implementation and operational experience with SNMPv2, were you thinking of an open forum, or rather a forum focused on particular problems and suggested changes, or ... Thanks, Bill ------------------------------------------------------------------------- William B. Norton Merit Network Inc. e-mail: wbn@merit.edu phone: (313) 936-2656 Bien cordialement -------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00640; 4 Nov 94 4:18 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00636; 4 Nov 94 4:18 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa01484; 4 Nov 94 4:18 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma024727; Fri Nov 4 03:39:26 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa14424; 4 Nov 94 3:35 EST Received: from sol.tis.com by magellan.TIS.COM id aa14420; 4 Nov 94 3:29 EST Received: from jack.cisco.com(171.69.1.139) by relay via smap (V1.3) id sma024686; Fri Nov 4 03:30:05 1994 Received: (kzm@localhost) by jack.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA09407; Fri, 4 Nov 1994 00:30:00 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Message-Id: <199411040830.AAA09407@jack.cisco.com> Subject: New I-Ds To: snmpv2@tis.com Date: Fri, 4 Nov 94 0:29:59 PST Cc: Keith McCloghrie Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM X-Mailer: ELM [version 2.3 PL11] Hi, As editor for the re-activating SNMPv2 WG, I've made what I believe are only editorial changes to the set of 12 RFCs, and thereby created 12 Internet-Drafts. I've also created 3 new documents so as to remove (from this set of SNMPv2 framework documents) all dependencies on MIBs defined using SNMPv1's SMI; these three new docuemnts are subsets of MIB-II: 1. IP/ICMP (minus the ipRouteTable, for which an update of RFC 1354 is already in progress); 2. TCP; and 3. UDP. So, I'm submitting 15 new I-Ds (whew!!). No doubt it will take a few days for them to get posted in the usual locations. It doesn't seem appropriate to fill your emailboxes by sending the new I-Ds in successive messages to the list. However, in the expectation that some of you will only want to download/print some of the documents (and to save some trees :-), I include below the "Change Log" sections from each of the 12 which replace the current RFCs. Keith. ------------ snmpV2-intro.txt - recast RFC 1441 into an Internet-Draft, - fixed typos. snmpV2-smi.txt - recast RFC 1442 into an Internet-Draft, - fixed typos - referred sub-typing restrictions to Section 9, - stated explicitly the restrictions on enumeration labels, - specified a restriction on the length of a BIT STRING as TBD bits, - included the restriction on sub-typing of TimeTicks in section 7.1.8, - added a rule for the use of IMPLIED with oid-valued INDEX variables, - clarified the circumstances under which auxiliary variables do not have a MAX-ACCESS clause of "not-accessible", - clarified the description of conceptual row augmentations, and added examples, - explicitly specified the macros in which refined syntax can be used, - included OID definitions for mib-2 and transmission. snmpV2-tc.txt - recast RFC 1443 into an Internet-Draft, - fixed typos, - added a summary of NVT ASCII to description of DisplayString, - clarified the description of InstancePointer, - fixed an error in the RowStatus state table, and another in its notes, - added a clarification on the use of DISPLAY-HINTS for particular types of syntax, snmpV2-conf.txt - recast RFC 1444 into an Internet-Draft, - fixed typos, - modified the usage examples to refer to the SNMPv2 MIB. snmpV2-admin.txt - recast RFC 1445 into an Internet-Draft, - added Overview section, - rewrote Elements of the Model section, - fixed typos in the Elements of Procedure section, - rewrote parts of the Application of the Model section, and retitled it as Usage Examples. - tighted the definition of a proxy SNMPv2 agent, in order to remove confusion, and thereby deleted discussion of foreign proxies. - changed "local party database" to "local party datastore", and introduced LPD as an acronym for it. snmpV2-sec.txt - recast RFC 1446 into an Internet-Draft, - fixed typos, - rewrote various paragraphs, sentences, phrases throughout the document to use less formal, but more easily understood, language, and to omit unnecessary/redundant text. - rewrote text in various sections on the maintenance of party secrets to be consistent with the use of the desPrivProtocol being optional. - removed text describing implementation-specific considerations. - incorporated new text on the creation of parties, discussing "cloning" as defined in the Party MIB. snmpV2-party.txt - recast RFC 1447 into an Internet-Draft, - fixed typos, - added snmpUDPDomain to the IMPORTS clause, - added descriptive text for the initial Context conventions, - added text to the DESCRIPTIONs of partyStatus, contextStatus, aclStatus, and viewStatus, specifying that columnar objects can be modified without having to set the status column to 'notInService', - added clarifying text to the DESCRIPTIONs of contextLocal, contextLocalEntity, contextProxySrcParty, contextProxyDstParty, contextProxyContext, and contextStatus, - removed auxiliary objects from the definition of partyMIBGroup. snmpV2-proto.txt - recast RFC 1448 into an Internet-Draft, - fixed typos, - clarified that while there is a theoretical limit on the number of varbinds, the size of a message is in practice not limited by the number of varbinds, - clarified the definition of noSuchInstance, - added text to require snmpStatsSilentDrops to be incremented whenever a message is discarded without sending a Response. snmpV2-tm.txt - recast RFC 1449 into an Internet-Draft, - fixed typos, - clarified the description of the use of rfc1157Domain as the transport domain of a proxy destination party. snmpV2-mib.txt - recast RFC 1450 into an Internet-Draft, - fixed typos, - fixed syntax of snmpORIndex, - removed ObjectName from IMPORTS clause, - included the system group from MIB-II. - removed definitions of linkUp and linkDown notifications since they are defined in RFC 1573, - referenced definition of egpNeighborLoss notification (in RFC 1213), in order to remove the last dependency on a MIB defined using SNMPv1's SMI, snmpV2-m2m.txt - recast RFC 1451 into an Internet-Draft, - fixed typos, - added a description of how source and destination parties are chosen for sending notifications, - reworded descriptions of notifications so that a context is not depicted as the "destination" of a notification, - added note that management stations are not obligated to use a retrieved value of snmpAlarmNextIndex to create an entry in the snmpAlarmTable. snmpV2-coex.txt - recast RFC 1452 into an Internet-Draft, - fixed typos - removed requirement to set the MAX-ACCESS of auxiliary objects to "not-accessible" when converting a SNMPv1 MIB, in order to be consistent with text in the SMI. - removed requirement to obsolete an object with a SYNTAX of enumerated INTEGER and a named-number enumeration of zero, in order to be consistent with text in the SMI.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01338; 6 Nov 94 9:04 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01334; 6 Nov 94 9:04 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa04202; 6 Nov 94 9:04 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma009206; Sun Nov 6 08:33:30 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa20817; 6 Nov 94 8:31 EST Received: from sol.tis.com by magellan.TIS.COM id aa20813; 6 Nov 94 8:23 EST Received: from thumper.bellcore.com(128.96.41.1) by relay via smap (V1.3) id sma009158; Sun Nov 6 08:24:38 1994 Received: from gatekeeper.mcimail.com (gatekeeper.mcimail.com [192.147.45.5]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id IAA19213 for ; Sun, 6 Nov 1994 08:24:28 -0500 Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA14750; Sun, 6 Nov 94 13:27:12 GMT Received: from mcimail.com by mailgate.mcimail.com id ab07103; 6 Nov 94 13:23 WET Date: Sun, 6 Nov 94 03:59 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Enterprise Management Institute <0006489618@mcimail.com> To: SNMP-WG , SNMP2 , Splinter , ST , Steve Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Subject: Enterprise Management Summit Message-Id: <83941106085938/MAILMAN000DC4EM@MCIMAIL.COM> Enterprise Management Theater -------------------------------- The Enterprise Management Summit '94 is around the corner! Summit '94 will feature a live theater where leading vendors will compete head-to-head to see who has the best enterprise management solution. In this theater will be a live enterprise computing environment. Networks will include SNA, DECNet, NetWare, and TCP/IP. Systems will include MVS, VMS, DOS, OS/2 and UNIX. Windows, NT, desktops, distributed applications and databases will also be present along with enterprise management platforms and applications. During Summit '94, we will "break" this network by introducing a series of hazards. These include (but are certainly not limited to) traffic congestion alarm floods, broadcast storms, applications that hang mysteriously, lost host connections, locked terminals, and forgotten passwords. Each vendor in the theater will have their chance to show how their enterprise management platform and applications deal with these hazards. The theater works like this: 1) Each vendor will have 90 minutes to present their solution. 2) No demos will be allowed. Each vendor must respond to the scenarios that have been given them by Summit '94. (see below) 3) The audience will evalute each presentation. Vendors will be evaluated on how well their solution dealt with each hazard; how easy or hard to implement the solution appears to be; how technically advanced the solution is; and the completeness of the solution. The scenarios are grouped as follows: I Asset Management - Auto Discovery; Inventory II Fault Management - Network Analysis; Multiple Alarms; Management of Disk Space; Data Base Management; Problems with DECNet/SNA, NetWare; Trouble Tracking & Ticketing III Administration - Security, Productivity Tracking, Configuration Management, Software Distribution Participating vendors in the theater are: * Bull * Computer Associates International * Digital Equipment Corporation * Hewlett-Packard * IBM Summit '94 will take place this November 14-18 at the Santa Clara Convention Center. For more information, call 1-800-340-2111 (415-512-1325 outside the US). Email: emiinc@mcimail.com or summit@ix.netcom.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03773; 7 Nov 94 11:04 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03769; 7 Nov 94 11:04 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa09268; 7 Nov 94 11:04 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma014889; Mon Nov 7 10:27:39 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa23788; 7 Nov 94 10:18 EST Received: from sol.tis.com by magellan.TIS.COM id aa23784; 7 Nov 94 10:08 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.3) id sma014732; Mon Nov 7 10:09:01 1994 Received: from nacto1.nacto.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA03576; Mon, 7 Nov 94 07:01:32 -0800 Received: from alex.nacto.lkg.dec.com by nacto1.nacto.lkg.dec.com with SMTP id AA26266; Mon, 7 Nov 1994 10:00:13 -0500 Received: by alex.nacto.lkg.dec.com (5.65/4.7) id AA27160; Mon, 7 Nov 1994 10:00:12 -0500 Message-Id: <9411071500.AA27160@alex.nacto.lkg.dec.com> To: snmp2@tis.com Subject: What are current plans for SNMPv2 workgroup ? Date: Mon, 07 Nov 94 10:00:12 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Aleksey Y. Romanov" Hi, It seems that group re-activation is postponed until the end of November (if I understand NM AD message properly). It seems alsoo that there will be no time left for any kind of fruitfull disuccison to be completed before IETF meeting. Does it mean that plans (to discuss the thing on the mailing list and to hammer out solutions at IETF) had been changed ? If yes, what is the current plot ? If not, how we are going to achieve any progress before IETF ? Aleksey   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06358; 7 Nov 94 13:48 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06354; 7 Nov 94 13:48 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa13671; 7 Nov 94 13:48 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma016645; Mon Nov 7 13:10:37 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa24469; 7 Nov 94 13:02 EST Received: from sol.tis.com by magellan.TIS.COM id aa24465; 7 Nov 94 12:55 EST Received: from utrhcs.cs.utwente.nl(130.89.10.247) by relay via smap (V1.3) id sma016463; Mon Nov 7 12:56:08 1994 Received: from utis94.cs.utwente.nl by utrhcs.cs.utwente.nl (5.0/csrelayMX-SVR4_1.0/RB) id AA15996; Mon, 7 Nov 1994 18:55:54 --100 Received: by utis94.cs.utwente.nl (4.1/RBCS-1.0.1) id AA01148; Mon, 7 Nov 94 18:55:42 +0100 Message-Id: <9411071755.AA01148@utis94.cs.utwente.nl> To: snmp2@tis.com, snmp@tis.com Subject: UT-SNMP ANNOUNCEMENT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: f.p.h.vanHengstum@cs.utwente.nl Organisation: "Frederic P. H. van Hengstum" "Dept. of Computer Science" "P.O. Box 217, 7500 AE Enschede, The Netherlands" "phone +31 53 894099, fax +31 53 333815" "www http://snmp.cs.utwente.nl/" "" Date: Mon, 07 Nov 94 18:55:41 +0100 X-Orig-Sender: hengstum@cs.utwente.nl Content-Length: 1872 ---------------------------------CUT-HERE------------------------------------ ************************** UT-SNMP ANNOUNCEMENT ***************************** INTRODUCTION ============ The UT-SNMP projectgroup at the University of Twente (The Netherlands) is doing research on the entire Simple Network Management Protocol version 2 (SNMPv2 and SNMPv1) framework, along the line(s) of the RFC1441 - RFC1452 specification. As a project spin-off we realize software primairily for unix platforms formalized in the UT-SNMP package. This software is freely available. SOFTWARE ======== description: The MIB-tripper (browser) can browse through an Management Information Base (MIB) contained in an UT-SNMP application. You can 'walk' up and down the MIB tree, display variable values and - descriptions, and initiate interactive the update of an particular variable. The program supports just an ascii interface. package: UT-TRIPPER-1_0.tar.Z programmers: Erwin Bonsma & Ivo Nijhuis ADDRESSES ========= postal: The UT-SNMP projectgroup Tele-Informatics and Open Systems Group Department of Computer Science P.O. Box 217, 7500 AE Enschede, The Netherlands voice: +31 53 894099 email: snmp@cs.utwente.nl www: http:/snmp.cs.uwtente.nl/ ftp: ftp.cs.utwente.nl:/pub/src/snmp/ ************************** UT-SNMP ANNOUNCEMENT ***************************** postal: The UT-SNMP projectgroup Tele-Informatics and Open Systems Group Department of Computer Science P.O. Box 217, 7500 AE Enschede, The Netherlands voice: +31 53 894099 email: snmp@cs.utwente.nl www: http:/snmp.cs.uwtente.nl/ ftp: ftp.cs.utwente.nl:/pub/src/snmp/ ************************** UT-SNMP ANNOUNCEMENT ***************************** ---------------------------------CUT-HERE------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11648; 7 Nov 94 17:51 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11644; 7 Nov 94 17:51 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa10753; 7 Nov 94 17:51 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smad20691; Mon Nov 7 17:13:41 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa25859; 7 Nov 94 17:04 EST Received: from sol.tis.com by magellan.TIS.COM id aa25853; 7 Nov 94 16:59 EST Received: from ub-gate.ub.com(128.203.50.11) by relay via smap (V1.3) id sma019957; Mon Nov 7 16:33:56 1994 Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.9]) id AA21006; Mon, 7 Nov 94 13:33:34 PST Received: from smelt.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA05922; Mon, 7 Nov 94 16:33:28 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Manoj Wadekar Message-Id: <9411072133.AA05922@sunny.andr.UB.com > Subject: unsubscribe To: snmp2@tis.com Date: Mon, 7 Nov 1994 16:32:50 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 350 -- /***************************************************************************/ Manoj Wadekar e-mail address: mkw@wipinfo.soft.net Residential Address: Tel: +91-80-558-8422 28, Sathyanarayana Layout, 3rd stage, 4th Block, Basweswaranagar, Bangalore-79 /***************************************************************************/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12615; 7 Nov 94 19:40 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12610; 7 Nov 94 19:40 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa12943; 7 Nov 94 19:40 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa22812; Mon Nov 7 18:55:35 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa26359; 7 Nov 94 18:54 EST Received: from sol.tis.com by magellan.TIS.COM id aa26355; 7 Nov 94 18:49 EST Received: from gatekeeper.us.oracle.com(192.216.243.3) by relay via smap (V1.3) id sma022700; Mon Nov 7 18:49:39 1994 Received: from prodpyr1.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id PAA04925; Mon, 7 Nov 1994 15:49:27 -0800 Received: by prodpyr1.us.oracle.com (Oracle 1.12/37.7) id AA08750; Mon, 7 Nov 94 15:49:22 PST Message-Id: <9411072349.AA08750@prodpyr1.us.oracle.com> Date: Mon, 7 Nov 94 15:49:22 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "SRAMASWA.US.ORACLE.COM" To: snmp2@tis.com Subject: unsubscribe   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05874; 8 Nov 94 14:08 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05860; 8 Nov 94 14:08 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa14183; 8 Nov 94 14:08 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma004864; Tue Nov 8 13:30:02 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa03486; 8 Nov 94 13:18 EST Received: from sol.tis.com by magellan.TIS.COM id aa03482; 8 Nov 94 13:10 EST Received: from unknown(134.87.131.13) by relay via smap (V1.3) id sma004524; Tue Nov 8 13:11:31 1994 Received: from mahogany.mpr.ca by mprgate.mpr.ca with SMTP id AA24566 (5.67b+/IDA-1.5 for ); Tue, 8 Nov 1994 10:11:05 -0800 Received: by mahogany.mpr.ca (4.1/SMI-4.1) id AA01655; Tue, 8 Nov 94 10:00:36 PST Date: Tue, 8 Nov 94 10:00:36 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Amnon Lever Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Message-Id: <9411081800.AA01655@mahogany.mpr.ca> To: snmp2@tis.com Subject: unsubscribe Cc: lever@mprgate.mpr.ca Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07503; 8 Nov 94 15:18 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07498; 8 Nov 94 15:18 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa16681; 8 Nov 94 15:18 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma006145; Tue Nov 8 14:42:26 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa03955; 8 Nov 94 14:36 EST Received: from sol.tis.com by magellan.TIS.COM id aa03951; 8 Nov 94 14:29 EST Received: from gatekeeper.us.oracle.com(192.216.243.3) by relay via smap (V1.3) id sma005798; Tue Nov 8 14:17:41 1994 Received: from prodpyr1.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id LAA10648; Tue, 8 Nov 1994 11:17:24 -0800 Received: by prodpyr1.us.oracle.com (Oracle 1.12/37.7) id AA13797; Tue, 8 Nov 94 11:17:21 PST Message-Id: <9411081917.AA13797@prodpyr1.us.oracle.com> Date: Tue, 8 Nov 94 11:17:21 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "SMUSALE.US.ORACLE.COM" To: snmp2@tis.com Subject: unsubscribe   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08290; 8 Nov 94 16:04 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08286; 8 Nov 94 16:04 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa18414; 8 Nov 94 16:04 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa06982; Tue Nov 8 15:24:15 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa04500; 8 Nov 94 15:21 EST Received: from sol.tis.com by magellan.TIS.COM id aa04496; 8 Nov 94 15:15 EST Received: from ccnet.ccnet.com(192.215.96.2) by relay via smap (V1.3) id sma006840; Tue Nov 8 15:15:29 1994 Received: (from daveb@localhost) by ccnet.ccnet.com (8.6.9/8.6.9) id MAA17337; Tue, 8 Nov 1994 12:13:22 -0800 Date: Tue, 8 Nov 1994 12:13:22 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Brower Message-Id: <199411082013.MAA17337@ccnet.ccnet.com> To: snmp2@tis.com Subject: Re: Basic question - (maybe related) Reply-To: daveb@ccnet.com The discussion of the bridge mib made me wonder why there isn't an optional SNMP group in the agent that shows the meta-data of the objects supported by the agent. This would let managers query the agents for the mibs rather than relying on the file getting transmitted in some out-of-band method. This may not be particularly germane to the re-opened v2 discussion, but meta-data might address a number of operational issues. It would allow smarter standards-based application-generators too. cheers, -dB   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09220; 8 Nov 94 17:03 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09216; 8 Nov 94 17:03 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa19731; 8 Nov 94 17:03 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma008085; Tue Nov 8 16:26:48 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa05757; 8 Nov 94 16:25 EST Received: from sol.tis.com by magellan.TIS.COM id aa05750; 8 Nov 94 16:18 EST Received: from gemini.rutgers.edu(128.6.15.3) by relay via smap (V1.3) id sma007971; Tue Nov 8 16:18:36 1994 Received: by gemini.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02602; Tue, 8 Nov 94 16:18:24 EST Date: Tue, 8 Nov 94 16:18:24 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Manjunath M Suryanarayana Message-Id: <9411082118.AA02602@gemini.rutgers.edu> To: snmp2@tis.com Subject: unsubscribe Please unsubscribe me. Thanx a lot. Manjunath   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09966; 8 Nov 94 18:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09962; 8 Nov 94 18:22 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa21588; 8 Nov 94 18:22 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma010429; Tue Nov 8 17:42:01 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06225; 8 Nov 94 17:36 EST Received: from sol.tis.com by magellan.TIS.COM id aa06220; 8 Nov 94 17:29 EST Received: from unknown(134.177.3.18) by relay via smap (V1.3) id sma009141; Tue Nov 8 17:01:54 1994 Received: from SynOptics.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA13175; Tue, 8 Nov 94 14:00:40 PST Received: from immer (immer.synoptics.com) by SynOptics.COM (4.1/SMI-4.1) id AA18046; Tue, 8 Nov 94 14:00:40 PST Received: by immer (4.1/2.0N) id AA20048; Tue, 8 Nov 94 13:58:16 PST Message-Id: <9411082158.AA20048@immer> Date: Tue, 8 Nov 94 13:58:16 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Perkins To: snmp2@tis.com Subject: Re: Basic question - (maybe related) HI Dave Brower asked the following... > The discussion of the bridge mib made me wonder why there isn't an > optional SNMP group in the agent that shows the meta-data of the > objects supported by the agent. This would let managers query the > agents for the mibs rather than relying on the file getting > transmitted in some out-of-band method. > Yes, it would be trival to implement a table that identified all the object-types that were supported by an agent. And with the agents that I know the internals, this would not cost any extra in data space to implement. There are two reasons that I can think of that this has not been implemented. The first is creeping featurisum - how many columns do you want in the table. For example, should the table have just an index (the oid of the object-type), and status. Or should it also include a column that specifies if the access is identical to that in MIB, and a column that specifies if the allowed values are the same as specified in the MIB. Is there another table that specifies whether tables allow row creation/deletion via SNMP? Is there another table that specifies required columns that must be specified in a SET for row creation? ETC. The other reason is concerns for security. Does this table have entries for all implemented object-types, or do you only get back the entries in the table that you could retrieve with community string/context that you used on the request? I believe that these tables should be added as mandatory parts of the SNMP group. But, this is really up to the SNMP agent vendors. If they put this in - it will be there. If they refuse - then it won't. Maybe one of them has already added this. /dave perkins, bay networks, 408-764-1516   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10321; 8 Nov 94 19:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10315; 8 Nov 94 19:24 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa22966; 8 Nov 94 19:25 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma011945; Tue Nov 8 18:45:34 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06442; 8 Nov 94 18:40 EST Received: from sol.tis.com by magellan.TIS.COM id aa06438; 8 Nov 94 18:34 EST Received: from ccnet.ccnet.com(192.215.96.2) by relay via smap (V1.3) id sma011600; Tue Nov 8 18:34:34 1994 Received: (from daveb@localhost) by ccnet.ccnet.com (8.6.9/8.6.9) id PAA08107; Tue, 8 Nov 1994 15:32:28 -0800 Date: Tue, 8 Nov 1994 15:32:28 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Brower Message-Id: <199411082332.PAA08107@ccnet.ccnet.com> To: bstewart@cisco.com, snmp2@tis.com In-Reply-To: <199411082234.OAA14752@feta.cisco.com> (bstewart@cisco.com) Subject: Re: Basic question - (maybe related) Reply-To: daveb@ccnet.com Date: Tue, 8 Nov 1994 14:34:02 -0800 From: Bob Stewart Subject: Re: Basic question - (maybe related) >The discussion of the bridge mib made me wonder why there isn't an >optional SNMP group in the agent that shows the meta-data of the >objects supported by the agent. This would let managers query the >agents for the mibs rather than relying on the file getting >transmitted in some out-of-band method. The major reason is the burden on the agent and the network to keep and transmit information that can be readily available out of band and processed once. If we go too far into a discussion of how cheap it could be, Frank Kastenholz will tell you about the agent where he had to leave out all the vowels in the system's help text, and Bill Simpson will give you a lecture on the cost of bandwidth on slower-speed links. In other words, this isn't a new suggestion. On the other side of it, Karl Auerbach will speak up for how powerful some managed systems have become. Did I about cover that, guys? :-)} I'm sure that's the historic argument. However, I'm coming from having just written the RDBMS-MIB, and am about to start creating a *pile* of application-related MIB stuff. None of this is *ever* going to live in a router, and the audiences for that sort of information might take more value out of standard meta-data access. This is why I raise the possibility of an _optional_ group. It's not all that clear that out-of-band transmission of MIBs scales into the mondo-distributed application environment. Us database folks found it very desirable to have tables that described tables in our RDBMSes. Since SNMP is now starting to creep up the food-chain of applicability, it might be desirable to consider things that enhance it's utility for that audience. cheers, -dB   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11526; 8 Nov 94 21:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11522; 8 Nov 94 21:50 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa25323; 8 Nov 94 21:50 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa14351; Tue Nov 8 20:59:31 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06790; 8 Nov 94 20:56 EST Received: from sol.tis.com by magellan.TIS.COM id aa06776; 8 Nov 94 20:51 EST Received: from emory.mathcs.emory.edu(128.140.110.1) by relay via smap (V1.3) id sma014107; Tue Nov 8 20:51:34 1994 Received: from bir.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.8) via UUCP id AA20463 ; Tue, 8 Nov 94 20:51:16 -0500 Return-Path: mlk%bir.UUCP@mathcs.emory.edu Received: by bir.bir.com (uA-1.6v2); Tue, 8 Nov 94 20:27:59 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Michael L. Kornegay" To: snmp2@tis.com Subject: Any plans to discuss Steve's drafts??? Date: Tue, 8 Nov 94 20:27:59 EST Reply-To: mlk%bir.UUCP@mathcs.emory.edu Message-Id: <0D15DDF1.eb3ud5@bir.bir.com> X-Mailer: uAccess - Macintosh Release: 1.6v2 Any plans to discuss Steve's drafts?: draft-waldbusser-conventions-00.txt draft-waldbusser-ssecimpl-00.txt draft-waldbusser-ssecov-00.txt These discuss 'SNMPv2 Simplified Security Conventions'. These were developed outside the working group but address a serious problem with the administrative model. Will these be considered to become working documents of the working group? There was rumored interest by several organizations that were going to try this. Is anyone planning to discuss their implementation experience of these conventions? ___________________ Michael L. Kornegay Internet: mlk@bir.com UUCP: bir!mlk AppleLink: mlk@bir.com@INTERNET#   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11602; 8 Nov 94 22:01 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11598; 8 Nov 94 22:01 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa25500; 8 Nov 94 22:01 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smab14764; Tue Nov 8 21:09:53 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06845; 8 Nov 94 21:04 EST Received: from sol.tis.com by magellan.TIS.COM id aa06840; 8 Nov 94 20:59 EST Received: from emory.mathcs.emory.edu(128.140.110.1) by relay via smap (V1.3) id sma014106; Tue Nov 8 20:51:32 1994 Received: from bir.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.8) via UUCP id AA20515 ; Tue, 8 Nov 94 20:51:19 -0500 Return-Path: mlk%bir.UUCP@mathcs.emory.edu Received: by bir.bir.com (uA-1.6v2); Tue, 8 Nov 94 20:45:22 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Michael L. Kornegay" To: snmp2@tis.com Subject: What are people planning to present/discuss? (was Re: SNMPv2 sessions Date: Tue, 8 Nov 94 20:45:22 EST Reply-To: mlk%bir.UUCP@mathcs.emory.edu Message-Id: <0D15DDF1.eb4v19@bir.bir.com> X-Mailer: uAccess - Macintosh Release: 1.6v2 In Regards to your letter <199411041657.IAA26076@feta.cisco.com>: > Since I haven't heard much from people, I have little idea of exactly what > we'll talk about. I'm confident that the discussion will expand to fill the > time alloted, but I'd prefer to be productive. > 2. Collection of list of who wants to speak to the group and their > topic. This list can be amended throughout the week. Some of us will be unable to attend this IETF meeting... It would be nice for this list of topics to be presented on the mailing list *prior* to the meetings whenever possible so those of us who cannot attend can participate at least on the mailing list. Please make a deliberate effort to assign someone to take *detailed* minutes. I am also interested in additional planned meetings after the IETF in December, is anything tenatively planned before the March recommendation to the IESG? Thanks, ___________________ Michael L. Kornegay Internet: mlk@bir.com UUCP: bir!mlk AppleLink: mlk@bir.com@INTERNET#   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11614; 8 Nov 94 22:01 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11610; 8 Nov 94 22:01 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa25505; 8 Nov 94 22:01 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma014351; Tue Nov 8 20:59:18 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06791; 8 Nov 94 20:56 EST Received: from sol.tis.com by magellan.TIS.COM id aa06780; 8 Nov 94 20:51 EST Received: from emory.mathcs.emory.edu(128.140.110.1) by relay via smap (V1.3) id sma014105; Tue Nov 8 20:51:30 1994 Received: from bir.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.8) via UUCP id AA20415 ; Tue, 8 Nov 94 20:51:09 -0500 Return-Path: mlk%bir.UUCP@mathcs.emory.edu Received: by bir.bir.com (uA-1.6v2); Tue, 8 Nov 94 20:27:29 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Michael L. Kornegay" To: snmp2@tis.com Subject: Any plans to discuss RFC 1503??? Date: Tue, 8 Nov 94 20:27:29 EST Reply-To: mlk%bir.UUCP@mathcs.emory.edu Message-Id: <0D15DDF1.eb3tg1@bir.bir.com> X-Mailer: uAccess - Macintosh Release: 1.6v2 Any plans to discuss RFC 1503?: 1503 I K. McCloghrie, M. Rose, "Algorithms for Automating Administration in SNMPv2 Managers", 08/26/1993. (Pages=19) (Format=.txt) Simplifying and consistently implementing the administrative model are very important topics to the success of SNMPv2... ___________________ Michael L. Kornegay Internet: mlk@bir.com UUCP: bir!mlk AppleLink: mlk@bir.com@INTERNET#   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14498; 8 Nov 94 22:53 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14488; 8 Nov 94 22:53 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa26109; 8 Nov 94 22:53 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma015382; Tue Nov 8 21:52:28 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06935; 8 Nov 94 21:41 EST Received: from sol.tis.com by magellan.TIS.COM id aa06931; 8 Nov 94 21:35 EST Received: from gatekeeper.us.oracle.com(192.216.243.3) by relay via smap (V1.3) id sma015182; Tue Nov 8 21:36:10 1994 Received: from prodpyr1.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id SAA29846; Tue, 8 Nov 1994 18:35:58 -0800 Received: by prodpyr1.us.oracle.com (Oracle 1.12/37.7) id AA29761; Tue, 8 Nov 94 18:35:57 PST Message-Id: <9411090235.AA29761@prodpyr1.us.oracle.com> Date: Tue, 8 Nov 94 18:35:57 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Seshu Adunuthula To: snmp2@tis.com Subject: unsubscribe X-Orcl-Application: In-Reply-To: OASUN1.US.ORACLE.COM:snmpv2-request@magellan.TIS.COM's message of 08-Nov-94 14:29 Please unsubscribe -sm- _____________________________________________________________________ Seshu Adunuthula Tel: (0) 415-506-6193 Oracle Networking (H) 510-494-9556 659410 Redwood Shores CA 94065   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00731; 9 Nov 94 4:56 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00727; 9 Nov 94 4:56 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa01774; 9 Nov 94 4:56 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma018918; Wed Nov 9 04:08:52 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa07713; 9 Nov 94 4:03 EST Received: from sol.tis.com by magellan.TIS.COM id aa07709; 9 Nov 94 3:57 EST Received: from gatekeeper.mcimail.com(192.147.45.5) by relay via smap (V1.3) id sma018638; Wed Nov 9 03:57:54 1994 Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA09793; Wed, 9 Nov 94 09:01:01 GMT Received: from mcimail.com by mailgate.mcimail.com id bf10649; 9 Nov 94 8:56 WET Date: Tue, 8 Nov 94 20:41 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Enterprise Management Institute <0006489618@mcimail.com> To: snmp1 Subject: Enterprise Management Message-Id: <71941109014117/0006489618PK1EM@MCIMAIL.COM> Enterprise Management Theater -------------------------------- The Enterprise Management Summit '94 is around the corner! Summit '94 will feature a live theater where leading vendors will compete head-to-head to see who has the best enterprise management solution. In this theater will be a live enterprise computing environment. Networks will include SNA, DECNet, NetWare, and TCP/IP. Systems will include MVS, VMS, DOS, OS/2 and UNIX. Windows, NT, desktops, distributed applications and databases will also be present along with enterprise management platforms and applications. During Summit '94, we will "break" this network by introducing a series of hazards. These include (but are certainly not limited to) traffic congestion alarm floods, broadcast storms, applications that hang mysteriously, lost host connections, locked terminals, and forgotten passwords. Each vendor in the theater will have their chance to show how their enterprise management platform and applications deal with these hazards. The theater works like this: 1) Each vendor will have 90 minutes to present their solution. 2) No demos will be allowed. Each vendor must respond to the scenarios that have been given them by Summit '94. (see below) 3) The audience will evalute each presentation. Vendors will be evaluated on how well their solution dealt with each hazard; how easy or hard to implement the solution appears to be; how technically advanced the solution is; and the completeness of the solution. The scenarios are grouped as follows: I Asset Management - Auto Discovery; Inventory II Fault Management - Network Analysis; Multiple Alarms; Management of Disk Space; Data Base Management; Problems with DECNet/SNA, NetWare; Trouble Tracking & Ticketing III Administration - Security, Productivity Tracking, Configuration Management, Software Distribution Participating vendors in the theater are: * Bull * Computer Associates International * Digital Equipment Corporation * Hewlett-Packard * IBM Summit '94 will take place this November 14-18 at the Santa Clara Convention Center. For more information, call 1-800-340-2111 (415-512-1325 outside the US). Email: emiinc@mcimail.com or summit@ix.netcom.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02492; 9 Nov 94 9:46 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02488; 9 Nov 94 9:46 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa06586; 9 Nov 94 9:46 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma021335; Wed Nov 9 09:02:19 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa08459; 9 Nov 94 8:55 EST Received: from sol.tis.com by magellan.TIS.COM id aa08455; 9 Nov 94 8:47 EST Received: from ccpngw.in2p3.fr(134.158.69.100) by relay via smap (V1.3) id sma021224; Wed Nov 9 08:48:30 1994 Received: by ccpngw.in2p3.fr (5.57/Ultrix2.4-C-3) id AA17209; Wed, 9 Nov 94 14:48:11 +0100 Message-Id: <9411091348.AA17209@ccpngw.in2p3.fr> Received: from marina.in2p3.fr by cppm.in2p3.fr with SMTP (1.38.193.5/16.2) id AA17307; Wed, 9 Nov 1994 14:48:09 +0100 Date: Wed, 9 Nov 1994 14:48:09 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: meessen@cppm.in2p3.fr To: snmpv2@tis.com Subject: dynamic tables and variables in mib Hello, I wanted to submit an idea for potential addition to SNMPv2. Sorry if this has been covered before. This idea is compatible with actual snmpv1 and snmpv2 protocol but only in an entreprise specific mib. The probelem I'm facing is the need to allow the user to define through snmp operations a new table. The user could define any number of variables of any type for this new table. The only difference with actual SNMP framework is that these tables can't be define in the ASN1 mib description. SInce this description only allows static variables and static tables (but with a dynamic number of rows). The table holding the definition of those dynamic tables would be static and given in the ASN1 mib description. Each entry in this definition table would have the following variable: xxTable OBJECT IDENTIFIER ::= { ... } VariableTypes ::= INTEGER { octet(1), integer32(2), ...} xxDefTable OBJECT-TYPE SYNTAX SEQUENCE OF xxDefEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of table and variable definitions." ::= { xxTable 1 } xxDefEntry OBJECT-TYPE SYNTAX xxDefEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A variable description for a table." INDEX { xxTblIdx, xxVarIdx } ::= { xxDefTable 1 } xxDefEntry ::= SEQUENCE { xxTblIdx INTEGER (1..65535), xxVarIdx INTEGER (0..65535), xxVarIsIndex INTEGER (0..1), xxVarType VariableTypes, xxVarName DisplayString, xxVarDescr DisplayString, xxVarStatus VariableStatus } xxTblIdx OBJECT-TYPE SYNTAX INTEGER (1..65535) ... DESCRIPTION "The table index number of this variable is part of." ::= { xxDefEntry 1 } xxVarIdx OBJECT-TYPE SYNTAX INTEGER (0..65535) ... DESCRIPTION "The variable index number of this table. If the index is 0, the table will have a maximum of one row and there can be only one variable in this table." ::= { xxDefEntry 2 } xxVarIsIndex OBJECT-TYPE SYNTAX INTEGER (0..1) ... DESCRIPTION "If set to 1, the variable is part of the index. The variables part of the index are ordered by the xxVarIdx value. If no variable is part of the index for a specific table, a default integer number from 1 to n will be used as index. If xxVarIdx equals zero, this value is ignored." ::= { xxDefEntry 3 } xxVarType OBJECT-TYPE SYNTAX VariableTypes ... DESCRIPTION "The value type stored in this variable." ::= { xxDefEntry 4 } xxVarName OBJECT-TYPE SYNTAX DisplayString ... DESCRIPTION "A label for this variable. Doesn't need to be unique." ::= { xxDefEntry 5 } xxVarDescr OBJECT-TYPE SYNTAX DisplayString ... DESCRIPTION "A string describing the variable's semantic" ::= { xxDefEntry 6 } xxVarStatus OBJECT-TYPE SYNTAX VariableStatus ... DESCRIPTION "The row Status according to the SNMPv2 SMI." ::= { xxDefEntry 7 } The data could be attached under the following branch xxData OBJECT IDENTIFIER ::= { xxTable 2 } example: The following is the label name of a column or variable xxVarName.1.1 The following is the value of the first row. In this case a simple integer value is used as index. xxData.1.1.1 | | ^-- row index (simple integer if no index value is specified) | ^-- variable index ^-- table index The following is a unique instance value. xxData.2.0 | ^-- variable index = instance specifier. ^-- table index = variable specifier. The problem is for management plateform to be able to handle such dynamic tables and variable types. It could be part of SNMPv2 that is a significant release change in SNMP. The extend in the mib possibility would be important. There are still some points to clear to build a functionnal system. For example the rowStatus field for tables editable by a users or the access control policy. This is just the basic idea description with a mib squeletton. Hope it could be discussed in the next SNMPv2 meetings. Since I can't be part of these meetings that take place on another continent, I must keep confidence in the equitable idea analysis process. Thanks. -- Bien cordialement, Ch. Meessen   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06247; 9 Nov 94 13:40 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06243; 9 Nov 94 13:40 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa12113; 9 Nov 94 13:40 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma027886; Wed Nov 9 13:22:30 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa21185; 9 Nov 94 13:17 EST Received: from sol.tis.com by magellan.TIS.COM id aa21181; 9 Nov 94 12:45 EST Received: from ctron.com(134.141.197.25) by relay via smap (V1.3) id sma027494; Wed Nov 9 12:46:32 1994 Received: from stealth.ctron.com by ctron.com (4.1/SMI-4.1) id AA10097; Wed, 9 Nov 94 12:33:14 EST Received: from express.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA24417; Wed, 9 Nov 94 12:33:06 EST Received: from gimli.ctron by express.ctron.com (4.1/SMI-4.1) id AA13603; Wed, 9 Nov 94 12:33:10 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Harrington Message-Id: <9411091733.AA13603@express.ctron.com> Subject: Index descriptions To: snmpv2@tis.com Date: Wed, 9 Nov 94 12:33:10 EST Cc: David Harrington X-Mailer: ELM [version 2.3 PL11] A proposal for changes to RFC 1447 Indexes: p17 partyIndex SYNTAX INTEGER (1..65535) p30 contextIndex SYNTAX INTEGER (1..65535) p42 viewIndex SYNTAX INTEGER (1..65535) p31 contextViewIndex SYNTAX INTEGER (0..65535) ============================================================================= The indexes are used for internal indexing only, and their values are meaningful only within the implementation of the SNMPV2-PARTY-MIB on a given SNMPv2 entity. The RFCs should indicate this restriction in the description of these indexes. partyIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each SNMPv2 party. The value for each SNMPv2 party must remain constant at least from one re-initialization of the entity's network management system to the next re- * initialization. The value used is meaningful only within * the implementation of the SNMPV2-PARTY-MIB on a given * SNMPv2 entity, and is not guaranteed to be meaningful * to any other snmpv2 entity except as a unique * index for the partyEntry within the datastore * in which the partyEntry exists. " ::= { partyEntry 2 } * [ and corresponding changes to the contextIndex and viewIndex ] contextViewIndex OBJECT-TYPE SYNTAX UInteger32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of an instance of this object is zero, then this corresponding conceptual row in the contextTable refers to a SNMPv2 proxy context; the values of the corresponding instances of the contextProxyDstParty, contextProxySrcParty, and contextProxyContext objects provide further information on the proxied context and the parties used to access it. Otherwise, if the value of an instance of this object is greater than zero, then this corresponding conceptual row in the contextTable refers to a SNMPv2 context which identifies a MIB view of a locally accessible entity; the value of the instance identifies the particular MIB view which has the same value of viewIndex; and the value of the corresponding instances of the contextLocalEntity and contextLocalTime objects provide further information on the local entity and its temporal domain. * If the value of an instance of this object is greater than * zero, then the value used is meaningful only within the * implementation of the SNMPV2-PARTY-MIB on a given SNMPv2 * entity, and is not guaranteed to be meaningful to any * other snmpv2 entity except as a unique index for the MIB * view within the datastore in which the MIB view exists." The Initial Parties on pp.10-15 are misleading in showing the values of the indexes, which should be strictly an implementation decision. The Initial Parties settings should show the Index values as , , , , etc. to show that the value of the index is not guaranteed. To make the examples more readable, a footnote might suffice. -- partyIdentity = { initialPartyId a b c d 1 } * -- partyIndex = ... -- contextIdentity = { initialContextId a b c d 1 } * -- contextIndex = ... * -- aclTarget = * -- aclSubject = * -- aclResources = -- aclPrivileges = 35 (Get, Get-Next & Get-Bulk) ... This change would make things a bit clearer. Any comments? -- ------------------------------------------------- #include David Harrington dbh@ctron.com Cabletron Systems Inc. Spectrum Modeling Group -------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07791; 9 Nov 94 15:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07787; 9 Nov 94 15:17 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa14180; 9 Nov 94 15:17 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma000208; Wed Nov 9 14:46:17 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa25426; 9 Nov 94 14:38 EST Received: from sol.tis.com by magellan.TIS.COM id aa25401; 9 Nov 94 14:18 EST Received: from hp.com(15.255.152.4) by relay via smap (V1.3) id sma001192; Wed Nov 9 14:18:57 1994 Received: from stimpy.cnd.hp.com by hp.com with SMTP (1.37.109.13/15.5+ECS 3.3) id AA160258722; Wed, 9 Nov 1994 11:18:42 -0800 Received: from localhost by stimpy.cnd.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3) id AA04454; Wed, 9 Nov 1994 12:18:32 -0700 Message-Id: <9411091918.AA04454@stimpy.cnd.hp.com> To: snmp2@tis.com Subject: Re: Any plans to discuss Steve's drafts??? X-Mailer: MH 6.3 #5[UCI] (0) of Thu Nov 13 18:46:25 PST 1986 Organization: Hewlett Packard, Network and Systems Management Division In-Reply-To: Your message of Wed, 09 Nov 1994 12:05:38 -0700. Date: Wed, 09 Nov 1994 12:18:31 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Darren Smith I wrote: |How about: | | 3. The security stuff is so complex that identifying a concrete set | of problems or making proposals that meet the criteria put forth | for discussion (specific, implementable, proven) is almost impossible. I should clarify that I did not mean that Steve's stuff falls completely in the above. It is more a matter that understanding the security stuff and understanding Steve's stuff and then trying to express potential problems leaves the recently initiated somewhat daunted. -- Darren Smith dds@cnd.hp.com 229-2536 Network and System Mngmt. Div. --   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08316; 9 Nov 94 15:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08312; 9 Nov 94 15:47 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa14777; 9 Nov 94 15:47 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smac00617; Wed Nov 9 15:11:44 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa28374; 9 Nov 94 15:09 EST Received: from sol.tis.com by magellan.TIS.COM id aa28362; 9 Nov 94 15:01 EST Received: from hp.com(15.255.152.4) by relay via smap (V1.3) id sma000371; Wed Nov 9 14:06:06 1994 Received: from stimpy.cnd.hp.com by hp.com with SMTP (1.37.109.13/15.5+ECS 3.3) id AA148227949; Wed, 9 Nov 1994 11:05:51 -0800 Received: from localhost by stimpy.cnd.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3) id AA04415; Wed, 9 Nov 1994 12:05:38 -0700 Message-Id: <9411091905.AA04415@stimpy.cnd.hp.com> To: snmp2@tis.com, dds@stimpy.cnd.hp.com Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Subject: Re: Any plans to discuss Steve's drafts??? X-Mailer: MH 6.3 #5[UCI] (0) of Thu Nov 13 18:46:25 PST 1986 Organization: Hewlett Packard, Network and Systems Management Division In-Reply-To: Your message of Wed, 09 Nov 1994 06:26:26 -0800. Date: Wed, 09 Nov 1994 12:05:38 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Darren Smith Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM |I'm surprised there hasn't been more action on these. Implementation |reports would definitely be appreciated. Does the lack of action imply |that: | | 1. Nobody really cares about security anyway? | | 2. SNMPv2 security is fine the way it is? How about: 3. The security stuff is so complex that identifying a concrete set of problems or making proposals that meet the criteria put forth for discussion (specific, implementable, proven) is almost impossible. -- Darren Smith dds@cnd.hp.com 229-2536 Network and System Mngmt. Div. --   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09555; 9 Nov 94 16:48 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09551; 9 Nov 94 16:48 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa16212; 9 Nov 94 16:48 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma002862; Wed Nov 9 16:13:27 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa00929; 9 Nov 94 16:06 EST Received: from sol.tis.com by magellan.TIS.COM id aa00924; 9 Nov 94 15:58 EST Received: from ctron.com(134.141.197.25) by relay via smap (V1.3) id sma002291; Wed Nov 9 15:59:28 1994 Received: from stealth.ctron.com by ctron.com (4.1/SMI-4.1) id AA16964; Wed, 9 Nov 94 15:59:19 EST Received: from express.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA02441; Wed, 9 Nov 94 15:59:11 EST Received: from gimli.ctron by express.ctron.com (4.1/SMI-4.1) id AA18429; Wed, 9 Nov 94 15:59:14 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Harrington Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Message-Id: <9411092059.AA18429@express.ctron.com> Subject: Party MIB Index sizes To: snmpv2@tis.com Date: Wed, 9 Nov 94 15:59:14 EST X-Mailer: ELM [version 2.3 PL11] In RFC 1447, is there a reason why the partyIndex, contextIndex, and viewIndex are limited to the range (1..65535)? Given the explosive growth of networks and the potential for growth of indexed rows in the Party MIB of an Enterprise NMS, wouldn't it be wise to remove this potential limit by making these indexes UInteger32? The additional space required for storage in agents or smaller NMSs with a limited number of parties and contexts would be minimal. -- ------------------------------------------------- #include David Harrington dbh@ctron.com Cabletron Systems Inc. Spectrum Modeling Group -------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09588; 9 Nov 94 16:49 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09569; 9 Nov 94 16:49 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa16229; 9 Nov 94 16:49 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa02862; Wed Nov 9 16:13:40 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa01119; 9 Nov 94 16:09 EST Received: from sol.tis.com by magellan.TIS.COM id aa01115; 9 Nov 94 16:03 EST Received: from feta.cisco.com(171.69.1.158) by relay via smap (V1.3) id sma002334; Wed Nov 9 16:00:33 1994 Received: (bstewart@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA02187; Wed, 9 Nov 1994 13:00:11 -0800 Date: Wed, 9 Nov 1994 13:00:11 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart Message-Id: <199411092100.NAA02187@feta.cisco.com> To: snmp2@tis.com In-Reply-To: <9411091905.AA04415@stimpy.cnd.hp.com> (message from Darren Smith on Wed, 09 Nov 1994 12:05:38 -0700) Subject: Re: Any plans to discuss Steve's drafts??? >How about: > > 3. The security stuff is so complex that identifying a concrete set > of problems or making proposals that meet the criteria put forth > for discussion (specific, implementable, proven) is almost impossible. That probably sums it up overall. My perception is that the administrative model and security, and the wrapper change that came with them, have been the major reason that the other parts of SNMPv2 have been held back. Steve's work may provide the answer, or part of it. Karl just suggested that if Steve's proposal is the answer, why keep the complex googob inside? I'd really like to see us get this all sorted out so we can have GetBulk and BitStrings and AGENT-CAPABILITIES out there. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10099; 9 Nov 94 17:28 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10095; 9 Nov 94 17:28 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa17319; 9 Nov 94 17:28 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smad04164; Wed Nov 9 16:52:10 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa03427; 9 Nov 94 16:46 EST Received: from sol.tis.com by magellan.TIS.COM id aa03417; 9 Nov 94 16:40 EST Received: from relay3.uu.net(192.48.96.8) by relay via smap (V1.3) id sma003768; Wed Nov 9 16:40:27 1994 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxpic19390; Wed, 9 Nov 1994 16:40:26 -0500 Received: from peernet.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 9 Nov 1994 16:40:16 -0500 Received: from peer.com (dorothy) by peernet.peer.com (4.1/SMI-4.1) id AA23420; Wed, 9 Nov 94 13:37:43 PST Received: by peer.com (4.1/SMI-4.1) id AA09204; Wed, 9 Nov 94 13:37:45 PST Date: Wed, 9 Nov 94 13:37:45 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Randy Presuhn Message-Id: <9411092137.AA09204@peer.com> To: snmpv2@tis.com Subject: Re: Party MIB Index sizes Hi - David Harrington writes: > In snmpv2, is there a reason why the partyIndex, contextIndex, and > viewIndex are limited to the range (1..65535)? > ... wouldn't it > be wise to remove this potential limit by making these indexes > UInteger32? ... Agreed. The current limit seems to provide no functionality. ---------------------------------------------------------------------- Randy Presuhn PEER Networks, Inc. Voice: +1 408-727-4111 3375 Scott Boulevard, Suite 100 Fax: +1 408-727-4410 Santa Clara, California 95054 Email: randy@peer.com USA ----------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11524; 9 Nov 94 20:04 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11520; 9 Nov 94 20:04 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa19942; 9 Nov 94 20:04 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smab26742; Wed Nov 9 11:54:44 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa21017; 9 Nov 94 11:51 EST Received: from sol.tis.com by magellan.TIS.COM id aa21013; 9 Nov 94 11:44 EST Received: from toadflax.cs.ucdavis.edu(128.120.56.188) by relay via smap (V1.3) id sma026502; Wed Nov 9 11:45:23 1994 Received: from parbat.cs.ucdavis.edu by toadflax.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA11124; Wed, 9 Nov 94 08:45:09 PST Received: by parbat.cs.ucdavis.edu (NX5.67c/NX3.0S) id AA05513; Wed, 9 Nov 94 08:42:40 -0800 Date: Wed, 9 Nov 94 08:42:40 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Louis Todd Heberlein Message-Id: <9411091642.AA05513@parbat.cs.ucdavis.edu> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: snmp2@tis.com Subject: Re: Any plans to discuss Steve's drafts??? Big disclaimer: I have yet to read Steve's drafts (but I am intrigued... after our ARPA program review). So this is a general statement (or opinion) about security and SNMP. > 2. SNMPv2 security is fine the way it is? I am of the opinion that reliable security is on par with reliable traps: you can't do it because you are building on an unreliable base. Example: if we touted a trap as being "reliable", then we risk future management developers assuming that when a critical event occurs, their manager WILL be notified. That is, the manager can rely on the fact that they will get the information. This may in turn lead to a more passive management design - wait until you are notified. However, if there is a problem in the network somewhere between the agent and the manager, or the agent or its host system is having problems. A critical event may never get to the manager - no matter how much energy we put in to making a trap "reliable." Example2: If we tout an agent's security as being "reliable", then we risk future management developers completely trusting the information. For example, we designed and built a little MIB to report various checksums (e.g., MD5, CRCxx) on critical files (actually, we folded in TRIPWIRE, if you are familiar with that code). The idea is that if an intruder comes in and trojans our system, we will detect it. However, this cannot be a long-term, widely distributed solution because we cannot guarantee that the intruder will not trojan the SNMP agent. By the way, encryption doesn't help - but that is another story. So, in summary, if we as a community are going to pursue the security of the SNMP model, we must recognize the fundamental limitation that our agents will be running and dependent on unsecure operating systems. Although this will not be true in all cases, we must be careful in what we advertise. "Reliable" and "Secure" are strong words, and we should be careful not to give future developers a false impression of the capabilities of the SNMP model. Whew.... now to go out and read those documents. Todd   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11692; 9 Nov 94 20:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11686; 9 Nov 94 20:22 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa20208; 9 Nov 94 20:22 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa29482; Wed Nov 9 13:53:23 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa21428; 9 Nov 94 13:41 EST Received: from sol.tis.com by magellan.TIS.COM id aa21424; 9 Nov 94 13:34 EST Received: from ctron.com(134.141.197.25) by relay via smap (V1.3) id sma028481; Wed Nov 9 13:35:13 1994 Received: from stealth.ctron.com by ctron.com (4.1/SMI-4.1) id AA09821; Wed, 9 Nov 94 12:21:05 EST Received: from express.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA24188; Wed, 9 Nov 94 12:20:58 EST Received: from gimli.ctron by express.ctron.com (4.1/SMI-4.1) id AA13456; Wed, 9 Nov 94 12:21:01 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Harrington Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Message-Id: <9411091721.AA13456@express.ctron.com> Subject: Party MIB Index sizes To: snmpv2@tis.com Date: Wed, 9 Nov 94 12:21:01 EST X-Mailer: ELM [version 2.3 PL11] In snmpv2, is there a reason why the partyIndex, contextIndex, and viewIndex are limited to the range (1..65535)? Given the explosive growth of networks and the potential for growth of indexed rows in the Party MIB of an Enterprise NMS, wouldn't it be wise to remove this potential limit by making these indexes UInteger32? The additional space required for storage in agents or smaller NMSs with a limited number of parties and contexts would be minimal. -- ------------------------------------------------- #include David Harrington dbh@ctron.com Cabletron Systems Inc. Spectrum Modeling Group -------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11806; 9 Nov 94 20:38 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11802; 9 Nov 94 20:38 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa20408; 9 Nov 94 20:38 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma001648; Wed Nov 9 14:26:00 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa23716; 9 Nov 94 14:19 EST Received: from sol.tis.com by magellan.TIS.COM id aa23704; 9 Nov 94 14:09 EST Received: from x400gate.bnr.ca(192.58.194.73) by relay via smap (V1.3) id sma000519; Wed Nov 9 14:09:15 1994 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 9 Nov 1994 14:04:00 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 9 Nov 1994 14:03:36 -0500 X400-Received: by /PRMD=bnr/ADMD=telecom.canada/C=ca/; Relayed; Wed, 9 Nov 1994 14:03:31 -0500 Date: Wed, 9 Nov 1994 19:03:31 +0000 X400-Originator: /dd.id=psd52384/g=usenet/i=u/s=support/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<39r6e3$phl@bcarh8ab.bnr.ca>] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Any plans... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "glenn (g.) waters" Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Message-Id: <39r6e3$phl@bcarh8ab.bnr.ca> To: snmpv2@tis.com Subject: Re: Any plans to discuss Steve's drafts??? Reply-To: " (Glenn Waters)" Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Path: bcars6aa!gwaters Newsgroups: bnr.list.snmpv2 Organization: Bell-Northern Research Ltd. Lines: 29 Nntp-Posting-Host: bcars6aa.bnr.ca In article <199411091426.GAA16740@feta.cisco.com>, wrote: > I'm surprised there hasn't been more action on these. Implementation > reports would definitely be appreciated. Does the lack of action imply > that: > > 1. Nobody really cares about security anyway? Absolutely do care. > > 2. SNMPv2 security is fine the way it is? Absolutely not. Pretty much for all the reasons stated in Steve's drafts. > > I can't believe either of those is entirely true. > > Bob I would like to see Steve's work incorporated into the standard and the current security requirements severely discouraged (or even removed, to whatever extent is possible). Steve's work makes the use and administration of SNMPv2 security plausible. -- Glenn Waters (gwaters@bnr.ca), Network Management Systems Bell-Northern Research, Ltd., Ottawa, Canada Don't anthropomorphize computers. They don't like it. #include   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12101; 9 Nov 94 21:06 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12097; 9 Nov 94 21:06 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa21061; 9 Nov 94 21:06 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma010664; Wed Nov 9 20:41:45 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa05081; 9 Nov 94 20:35 EST Received: from sol.tis.com by magellan.TIS.COM id aa05077; 9 Nov 94 20:29 EST Received: from relay3.uu.net(192.48.96.8) by relay via smap (V1.3) id sma010007; Wed Nov 9 20:15:01 1994 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxpiq26410; Wed, 9 Nov 1994 20:14:59 -0500 Received: from peernet.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 9 Nov 1994 20:14:45 -0500 Received: from peer.com (dorothy) by peernet.peer.com (4.1/SMI-4.1) id AA23734; Wed, 9 Nov 94 17:05:11 PST Received: by peer.com (4.1/SMI-4.1) id AA10642; Wed, 9 Nov 94 17:05:14 PST Date: Wed, 9 Nov 94 17:05:14 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Randy Presuhn Message-Id: <9411100105.AA10642@peer.com> To: snmpv2@tis.com Subject: Re: Basic question - (maybe related) Hi - Reuben Sivan writes: > One alternative way of achieving this goal might be (hold the fire) > through a change to the SMI - i.e., I would add a new command (in addition > to get, get-next, etc...), say, get-capability. This command can be > applied to any object supported by the agent, and the agent would return > the capabilities and limitations for that object. > > This is similar to the agent-capabilities TC, except that the data would > be available at run-time. This is an interesting capability, but whether it is supported through a new mib or through a new operation type, it is worth learning from work on ISO 10164-16, the Management Knowledge Management Function: 0) Both AGENT-CAPABILTIES and OBJECT-TYPE kinds of information are of value to managers. 1) The information in ASN.1 modules and MIB definitions may not fit within PDU size limitations, especially DESCRIPTION text which is several pages long in some cases. 2) Which elements of definition merit distinct variables needs to be carefully considered. One extreme is to put an ASN.1 module's text into a variable. The other is to put each identifiable component of each OBJECT-TYPE into a variable. 3) The distinction between what a system could support and which classes are currently available (think of all those hot-swap interface cards that aren't plugged in yet) is important. 4) References to data types, especially IMPORTed ones, requires careful handling to be useful. (How does one resolve the underlying data type of a textual convention IMPORTed into a module if the module from which the definition came is not available?) 5) Where different instances of the same class reflect different underlying resources and instrumentation (e.g., rows in the tables in the RDBMS MIB), what is supported may vary with finer granularity that the AGENT-CAPABILITIES macro seems to allow. Don't get me wrong - I think this merits further consideration, but it might be awkward to support within the constraints of the protocols and information models available. ---------------------------------------------------------------------- Randy Presuhn PEER Networks, Inc. Voice: +1 408-727-4111 3375 Scott Boulevard, Suite 100 Fax: +1 408-727-4410 Santa Clara, California 95054 Email: randy@peer.com USA ----------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12129; 9 Nov 94 21:08 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12125; 9 Nov 94 21:08 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa21121; 9 Nov 94 21:08 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smab10664; Wed Nov 9 20:42:13 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa05108; 9 Nov 94 20:40 EST Received: from sol.tis.com by magellan.TIS.COM id aa05101; 9 Nov 94 20:35 EST Received: from emory.mathcs.emory.edu(128.140.110.1) by relay via smap (V1.3) id sma010543; Wed Nov 9 20:35:33 1994 Received: from bir.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.8) via UUCP id AA14003 ; Wed, 9 Nov 94 20:35:24 -0500 Return-Path: mlk%bir.UUCP@mathcs.emory.edu Received: by bir.bir.com (uA-1.6v2); Wed, 9 Nov 94 19:57:41 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Michael L. Kornegay" Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM To: snmp2@tis.com Subject: Re: SNMPv1.5 (tm) Date: Wed, 9 Nov 94 19:57:41 EST Cc: snmp2@tis.com Reply-To: mlk%bir.UUCP@mathcs.emory.edu Message-Id: <0D15DDF1.edmhj8@bir.bir.com> X-Mailer: uAccess - Macintosh Release: 1.6v2 In Regards to your letter : > Here's my short list: > > 1. Normalize trap pdus with all others (format). > 2. Add GetBulk. > 3. Support most (if not all) v2 SMI TCs and types. > 4. Support most (if not all) v2 error codes. > 5. Others...esp. maybe some smart light-weight security idea. I doubt such a proposal would be considered. If such a proposal was to be considered, i think it could be simplified by just saying *avoid the administrative model*, and do everything else. I suggested such a thing way back under a subject of 'how to get SNMPv2 out there'. I bet the general concensus in the group will be that most of SNMPv2 is pretty decent (with some fixes or clarifications). If the PDUs were wrapped in RFC1157Message or a similar wrapper, it would be easy for many to take advantage of the good stuff in v2 without dealing with the *controversial* administrative model. ___________________ Michael L. Kornegay Internet: mlk@bir.com UUCP: bir!mlk AppleLink: mlk@bir.com@INTERNET#   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21766; 10 Nov 94 2:56 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21762; 10 Nov 94 2:56 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa26448; 10 Nov 94 2:56 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma016204; Thu Nov 10 02:33:13 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06065; 10 Nov 94 2:25 EST Received: from sol.tis.com by magellan.TIS.COM id aa06061; 10 Nov 94 2:20 EST Received: from finwds01.tu-graz.ac.at(129.27.138.60) by relay via smap (V1.3) id sma016148; Thu Nov 10 02:21:08 1994 Received: by finwds01.tu-graz.ac.at (5.65/DEC-Ultrix/4.3) id AA02873; Thu, 10 Nov 1994 08:21:00 +0100 Date: Thu, 10 Nov 1994 08:20:58 +0100 (MET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Leitner Subject: unsubscribe To: snmp2@tis.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please unsubscribe me! --------------------------------------------------------------------------- Tom Leitner, Dept. of Communications, Graz University of Technology/Austria Internet: tom@finwds01.tu-graz.ac.at, FidoNet: 2:316/7.91 WWW home page: http://finwds01.tu-graz.ac.at/people/tom.html ---------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01280; 10 Nov 94 7:16 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01276; 10 Nov 94 7:16 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa03507; 10 Nov 94 7:16 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma018337; Thu Nov 10 06:45:56 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa06702; 10 Nov 94 6:38 EST Received: from sol.tis.com by magellan.TIS.COM id aa06698; 10 Nov 94 6:32 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: LWATANAB@madalena.cce.usp.br Mmdf-Warning: Parse error in original version of preceding line at magellan.TIS.COM Received: from bee.uspnet.usp.br(143.107.253.3) by relay via smap (V1.3) id sma018245; Thu Nov 10 06:32:18 1994 Return-Path: LWATANAB@madalena.cce.usp.br Received: from madalena.cce.usp.br (madalena.cce.usp.br [143.107.70.202]) by bee.uspnet.usp.br (8.6.8.1/SPARC10-CCE2.0)id JAA08718 Received: from MADALENA/SpoolDir by madalena.cce.usp.br (Mercury 1.13); Thu, 10 Nov 94 9:34:32 +1100 Received: from SpoolDir by MADALENA (Mercury 1.13); Thu, 10 Nov 94 9:34:16 +1100 Organization: cce.usp.br To: snmp2@tis.com Date: Thu, 10 Nov 1994 09:34:12 -1800 Subject: unsubscribe Priority: normal X-Mailer: Pegasus Mail/Windows (v1.21) Message-Id: <1F0BAD37B6E@madalena.cce.usp.br> unsubscribe   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05314; 10 Nov 94 11:09 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05310; 10 Nov 94 11:09 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa08764; 10 Nov 94 11:09 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma023264; Thu Nov 10 10:34:56 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa11817; 10 Nov 94 10:30 EST Received: from sol.tis.com by magellan.TIS.COM id aa11813; 10 Nov 94 10:24 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.3) id sma022985; Thu Nov 10 10:24:58 1994 Received: from nacto1.nacto.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA21051; Thu, 10 Nov 94 07:18:21 -0800 Received: from alex.nacto.lkg.dec.com by nacto1.nacto.lkg.dec.com with SMTP id AA01385; Thu, 10 Nov 1994 10:18:18 -0500 Received: by alex.nacto.lkg.dec.com (5.65/4.7) id AA10349; Thu, 10 Nov 1994 10:18:17 -0500 Message-Id: <9411101518.AA10349@alex.nacto.lkg.dec.com> To: snmp2@tis.com Subject: noSuchXXXXXX Date: Thu, 10 Nov 94 10:18:17 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Aleksey Y. Romanov" Hi, I have a strong feeling (based on my implementation experience) that to go back to noSuchName (as type) from noSuchObject/noSuchInstance is a good thing. Pro: 1. It allows to build clean protocol engines, where name access rights calculation is separated from the MIB processing. 2. It allows to perform only one access rights calculation per variable instead of two. 3. It is not implemented properly anyway. It was small off-list discussion of this subject this summer. It happen that at the time only SNMP Research, Inc. did it right. Con: 1. It will not allow NMS to distinguish between empty and not-implemented/not-accessible read-only tables. I does not seem like an important feature, because the primary tool for variable discovery are Get-Next/Get-Bulk and AGENT CAPABILITIES macro. Aleksey   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06346; 10 Nov 94 12:08 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06342; 10 Nov 94 12:08 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa09940; 10 Nov 94 12:08 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa24436; Thu Nov 10 11:27:11 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa13850; 10 Nov 94 11:23 EST Received: from sol.tis.com by magellan.TIS.COM id aa13846; 10 Nov 94 11:18 EST Received: from hp.com(15.255.152.4) by relay via smap (V1.3) id sma024323; Thu Nov 10 11:18:34 1994 Received: from stimpy.cnd.hp.com by hp.com with SMTP (1.37.109.13/15.5+ECS 3.3) id AA183194310; Thu, 10 Nov 1994 08:18:31 -0800 Received: from localhost by stimpy.cnd.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3) id AA18259; Thu, 10 Nov 1994 09:18:23 -0700 Message-Id: <9411101618.AA18259@stimpy.cnd.hp.com> To: snmp2@tis.com Subject: Re: Any plans to discuss Steve's drafts??? X-Mailer: MH 6.3 #5[UCI] (0) of Thu Nov 13 18:46:25 PST 1986 Organization: Hewlett Packard, Network and Systems Management Division In-Reply-To: Your message of Wed, 09 Nov 1994 13:00:11 -0800. Date: Thu, 10 Nov 1994 09:18:23 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Darren Smith Bob Steware wrote: |That probably sums it up overall. My perception is that the administrative |model and security, and the wrapper change that came with them, have been |the major reason that the other parts of SNMPv2 have been held back. I agree with this. We would probably have SNMPv2 widely deployed if it was only all the other misc. changes combined. This does not mean that the administrative model and security are bad per se, but it is an important point to realize: we are paying a price in delayed deployment and real-world implementation experience because of it. |Steve's work may provide the answer, or part of it. Karl just suggested |that if Steve's proposal is the answer, why keep the complex googob inside? |I'd really like to see us get this all sorted out so we can have GetBulk and |BitStrings and AGENT-CAPABILITIES out there. Amen to that. Also, just to be clear: I think Steve's work was great given the underlying v2 model he had to dela with. I applaud him heartily for taking steps to address it while others (like me) just whined. However, the model, while presenting a simplified set of concepts at a higher level, is still complex to understand the workings of if you are not intimately familiar with the SNMPv2 details, and thus hard for outsiders to judge or give good detailed feedback about. I should note that there are others in HP that are capable of that level of feedback and they have been working with Steve. I'm more of a consumer of that work as an application writer. -- Darren Smith dds@cnd.hp.com 229-2536 Network and System Mngmt. Div. --   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06916; 10 Nov 94 13:08 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06912; 10 Nov 94 13:08 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa11053; 10 Nov 94 13:08 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma026002; Thu Nov 10 12:30:49 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa14030; 10 Nov 94 12:25 EST Received: from sol.tis.com by magellan.TIS.COM id aa14026; 10 Nov 94 12:18 EST Received: from mail.unigate1.unisys.com(192.63.100.18) by relay via smap (V1.3) id sma025560; Thu Nov 10 12:19:16 1994 Received: from rsvl.unisys.com ([192.61.220.100]) by mail.unigate1.unisys.com (4.1/SMI-4.1-1.1) id AA10663; Thu, 10 Nov 94 17:38:21 GMT Received: from unirsvl.rsvl.unisys.com by rsvl.unisys.com (4.1/SMI-4.1) id AA01201; Thu, 10 Nov 94 11:19:03 CST Received: by unirsvl.rsvl.unisys.com (4.1/SMI-4.1) id AA22319; Thu, 10 Nov 94 11:25:11 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Connie Ahrens Message-Id: <9411101725.AA22319@unirsvl.rsvl.unisys.com> Subject: snmpv1 header with SMIv2 MIB To: snmp@psi.com Date: Thu, 10 Nov 94 11:25:10 CST Cc: snmpv2@tis.com X-Mailer: ELM [version 2.3 PL8] Does any SNMP management station request MIBs with SMIv2 format with a SNMP v1 header on the message?? Do they only request MIBs with SMIv1 format with a SNMPv1 header? Can a SNMPv2 header message request MIBs with a SMIv1 format?? Thanks for any information. Connie Ahrens   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07587; 10 Nov 94 13:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07583; 10 Nov 94 13:47 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa12074; 10 Nov 94 13:47 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma026809; Thu Nov 10 13:11:09 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa14157; 10 Nov 94 13:08 EST Received: from sol.tis.com by magellan.TIS.COM id aa14152; 10 Nov 94 13:00 EST Received: from inet-gw-3.pa.dec.com(16.1.0.33) by relay via smap (V1.3) id sma026634; Thu Nov 10 13:00:47 1994 Received: from pcsbst.pcs.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA19122; Thu, 10 Nov 94 09:58:07 -0800 Received: by pcsbst.pcs.dec.com (5.65/jmh-inet-gateway-sendmail-V1.05); id AA23426; Thu, 10 Nov 1994 18:57:59 +0100 Message-Id: <9411101757.AA23426@pcsbst.pcs.dec.com> To: snmpv2@tis.com Cc: ihanson@pcsbst.pcs.dec.com Subject: Re: SNMPv1.5 (tm) In-Reply-To: Your message of "Thu, 10 Nov 94 00:00:06 EST." <9411100500.AA20887@buoy.watson.ibm.com> Date: Thu, 10 Nov 94 18:57:59 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Iain K. Hanson" X-Mts: smtp uri@watson.ibm.com wrote : >Well, yes. For apparently, the wide market doesn't yet feel the need >of V2 kind of security. Personally, I don't believe this to be the case. Although security can be a complex subject, just like networking, users want products that are simple to use. For this to happen, developers need to be able to put most of their energy in to thinking about how their product are going to be used and not in to understanding SNMPv2 - which I don't believe to be the case at the moment. When I first started to learn SNMPv2, I was already familar with SNMPv1 and with CMISE. I found it very hard going just working from the RFCs. I found it very difficult to make sense of the Administrative model in particular and how all the peices fitted together. I could only make sense of it once I read rfc1448 - the protocol! I hav'nt had a chance yet to read the new drafts yet to see how much they have improved things ( my printers are broke :-( ) but hope to do so shortly. Now that I understand the admin model I like it, but I would be interested in to know whether people think the model is to complex or whether we need to find a better way to document and explain it? /ikh   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08526; 10 Nov 94 14:28 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08522; 10 Nov 94 14:28 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa13252; 10 Nov 94 14:28 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smab27508; Thu Nov 10 13:46:42 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa14311; 10 Nov 94 13:40 EST Received: from sol.tis.com by magellan.TIS.COM id aa14304; 10 Nov 94 13:34 EST Received: from hp.com(15.255.152.4) by relay via smap (V1.3) id sma027205; Thu Nov 10 13:34:24 1994 Received: from nsmdserv.cnd.hp.com by hp.com with SMTP (1.37.109.13/15.5+ECS 3.3) id AA023242461; Thu, 10 Nov 1994 10:34:22 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3) id AA01578; Thu, 10 Nov 1994 11:34:21 -0700 Message-Id: <9411101834.AA01578@nsmdserv.cnd.hp.com> To: snmp2@tis.com Subject: Re: noSuchXXXXXX X-Mailer: MH 6.3 #5[UCI] (0) of Thu Nov 13 18:46:25 PST 1986 Organization: Hewlett-Packard, Network & System Management Division In-Reply-To: Your message of Thu, 10 Nov 94 10:18:17 -0500. <9411101518.AA10349@alex.nacto.lkg.dec.com> Date: Thu, 10 Nov 94 11:34:21 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bok@nsmdserv.cnd.hp.com Aleksey, Your agent implementation experience is valid. From the manager application side, however, I find VarBind Exceptions (as opposed to error_status/error_index) to be a very good thing. I am not debating the value of having two distinct (i.e., noSuchObject and noSuchInstance) versus one varbind exception. I do, though, want to see the notion of varbind exceptions remain in SNMPv2. bok > > Hi, > > > I have a strong feeling (based on my implementation experience) > that to go back to noSuchName (as type) from noSuchObject/noSuchInstance > is a good thing. > > Pro: > 1. It allows to build clean protocol engines, where name access > rights calculation is separated from the MIB processing. > > 2. It allows to perform only one access rights calculation > per variable instead of two. > > 3. It is not implemented properly anyway. It was small off-list > discussion of this subject this summer. It happen that at > the time only SNMP Research, Inc. did it right. > > Con: > > 1. It will not allow NMS to distinguish between > empty and not-implemented/not-accessible read-only > tables. > > > I does not seem like an important feature, because > the primary tool for variable discovery are > Get-Next/Get-Bulk and AGENT CAPABILITIES macro. > > > Aleksey > > > > ----------------------------------------------------------------------------- Brian O'Keefe Network & System Management Division bok@cnd.hp.com Hewlett-Packard Company, Inc. (303) 229-4303 -----------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09165; 10 Nov 94 15:01 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09161; 10 Nov 94 15:01 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa14096; 10 Nov 94 15:01 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma028139; Thu Nov 10 14:08:57 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa14421; 10 Nov 94 14:03 EST Received: from sol.tis.com by magellan.TIS.COM id aa14417; 10 Nov 94 13:57 EST Message-Id: <9411101857.AA27867@relay.tis.com> Received: from vnet.ibm.com(199.171.26.4) by relay via smap (V1.3) id sma027859; Thu Nov 10 13:57:29 1994 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 5578; Thu, 10 Nov 94 13:56:46 EST Date: Thu, 10 Nov 94 19:56:24 CET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Bert Wijnen (+31-2975-53316)" To: snmp2@tis.com Subject: noSuchXXXXXX Ref: Your note of Thu, 10 Nov 94 10:18:17 EST > Subject: noSuchXXXXXX > Aleksey writes: > I have a strong feeling (based on my implementation experience) > that to go back to noSuchName (as type) from noSuchObject/noSuchInstance > is a good thing. > > Pro: > 1. It allows to build clean protocol engines, where name access > rights calculation is separated from the MIB processing. > > 2. It allows to perform only one access rights calculation > per variable instead of two. > > 3. It is not implemented properly anyway. It was small off-list > discussion of this subject this summer. It happen that at > the time only SNMP Research, Inc. did it right. > We had no problem implementing the noSuchObject and noSuchInstance (I think) and we did it right (I think). It is a bit more code, but then it gives extra info. > Con: > > 1. It will not allow NMS to distinguish between > empty and not-implemented/not-accessible read-only > tables. > > > I does not seem like an important feature, because > the primary tool for variable discovery are > Get-Next/Get-Bulk and AGENT CAPABILITIES macro. > In my view the more important feature that we see in SNMPv2 is that if we get a noSuchXXXXXX in a varBindList, then we donot return an error in error_status, but instead return the noSuchXXXXXX in the offending varBind with an implied NULL value. If we were to return to just noSuchName (I'd rather keep the otehr noSuchXXXXXX types), then at least let us define a noSuchSomething type that goes in the offending varBind. Bert   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14103; 10 Nov 94 20:02 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14099; 10 Nov 94 20:02 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa20585; 10 Nov 94 20:02 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma006511; Thu Nov 10 19:25:19 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa15873; 10 Nov 94 19:19 EST Received: from sol.tis.com by magellan.TIS.COM id aa15869; 10 Nov 94 19:14 EST Received: from relay3.uu.net(192.48.96.8) by relay via smap (V1.3) id sma006382; Thu Nov 10 19:14:51 1994 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxpme27721; Thu, 10 Nov 1994 19:14:40 -0500 Received: from peernet.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Thu, 10 Nov 1994 19:14:32 -0500 Received: from peer.com (dorothy) by peernet.peer.com (4.1/SMI-4.1) id AA25466; Thu, 10 Nov 94 15:18:52 PST Received: by peer.com (4.1/SMI-4.1) id AA14411; Thu, 10 Nov 94 15:18:55 PST Date: Thu, 10 Nov 94 15:18:55 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Randy Presuhn Message-Id: <9411102318.AA14411@peer.com> To: snmp2@tis.com Subject: Re: noSuchXXXXXX Hi - > From: "Aleksey Y. Romanov" ... > I have a strong feeling (based on my implementation experience) > that to go back to noSuchName (as type) from noSuchObject/noSuchInstance > is a good thing. Agreed. Having per-variable error information is nice, but the value of the noSuchObject/noSuchInstance distinction seems to outweighed by the implementation complexity. > Pro: > 1. It allows to build clean protocol engines, where name access > rights calculation is separated from the MIB processing. Yes! Anything to make the administrative model for access control clearer! > 2. It allows to perform only one access rights calculation > per variable instead of two. Yes. (Although it's not that much of a savings in some implementations.) ---------------------------------------------------------------------- Randy Presuhn PEER Networks, Inc. Voice: +1 408-727-4111 3375 Scott Boulevard, Suite 100 Fax: +1 408-727-4410 Santa Clara, California 95054 Email: randy@peer.com USA ----------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14199; 10 Nov 94 20:14 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14195; 10 Nov 94 20:14 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa20792; 10 Nov 94 20:14 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma006711; Thu Nov 10 19:36:09 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa15944; 10 Nov 94 19:31 EST Received: from sol.tis.com by magellan.TIS.COM id aa15940; 10 Nov 94 19:25 EST Received: from emory.mathcs.emory.edu(128.140.110.1) by relay via smap (V1.3) id sma006532; Thu Nov 10 19:25:45 1994 Received: from bir.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.8) via UUCP id AA26906 ; Thu, 10 Nov 94 19:25:30 -0500 Return-Path: mlk%bir.UUCP@mathcs.emory.edu Received: by bir.bir.com (uA-1.6v2); Thu, 10 Nov 94 19:19:35 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Michael L. Kornegay" To: snmp2@tis.com Subject: Re: SNMPv1.5 (tm) Date: Thu, 10 Nov 94 19:19:35 EST Reply-To: mlk%bir.UUCP@mathcs.emory.edu Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Message-Id: <0D15DDF1.eg8m58@bir.bir.com> X-Mailer: uAccess - Macintosh Release: 1.6v2 In Regards to your letter <9411102105.AA23017@buoy.watson.ibm.com>: > Well, you see, the way it's done now - it's end-to-end security. There > is IPSP coming, which [hopefully] will provide host-to-host security > (i.e. authentication and privacy). But is it good enough? If yes, > then the whole V2 Admin just goes down the tubes... But if one > still wants to authenticate the Entity on the remote end, > then I'm afraid IPSP won't be enough (and where else > can security be put? Below - obviously not the > place, and above is UDP/SNMP...) You forgot that IP is not the only transport protocol for SNMP. SNMP has to have authentication and privacy options for situations where the underlying transport does not provide those mechanisms. It is not just an end-to-end vs hop-to-hop issue. I dont know how much the proposed SNMP security architecture will be allowed to change by the working group. It is hard to say with- out having heard the comments from implementors *and* deployers. Remember in all this that network managers, humans, may be requried to configure this stuff. The other question is did we get it right in the Admin Model in the first place. In Houston IETF I attended some meetings of the Security Area and remember there being, though I do not remember the content, a negative comment about the SNMP security model. Kind of funny since they were *supposedly* what held up the origional Secure SNMP RFCs for so long. If any of the new security architectures are superior, we should consider them before we end up specifing and inferior framework. For example is DES enough, I keep hearing about double and tripple DES. And so on... Thanks, ___________________ Michael L. Kornegay Internet: mlk@bir.com UUCP: bir!mlk AppleLink: mlk@bir.com@INTERNET#   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01266; 11 Nov 94 7:06 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01262; 11 Nov 94 7:06 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa03490; 11 Nov 94 7:06 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma012108; Fri Nov 11 06:38:35 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa17521; 11 Nov 94 6:35 EST Received: from sol.tis.com by magellan.TIS.COM id aa17514; 11 Nov 94 6:29 EST Message-Id: <9411111037.AA11908@relay.tis.com> Received: from ldvhp25.ldv.e-technik.tu-muenchen.de(129.187.105.51) by relay via smap (V1.3) id sma011903; Fri Nov 11 05:37:03 1994 Received: by ldvhp23.ldv.e-technik.tu-muenchen.de (1.37.109.4/16.2) id AA03534; Fri, 11 Nov 94 11:39:36 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "H. Nikolaus Schaller" Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Subject: Re: SNMPv1.5 (tm) To: snmp2@tis.com Date: Fri, 11 Nov 94 11:39:35 MEZ In-Reply-To: <9411110007.AA23686@buoy.watson.ibm.com>; from "uri@watson.ibm.com" at Nov 10, 94 7:07 pm Organization: Lehrstuhl fuer Datenverarbeitung, Technische Universitaet Muenchen Address: Arcisstr. 21, D-80290 Muenchen, F.R.G. Phone: +49-89-2105-3606 Mailer: Elm [revision: 70.85] uri@watson.ibm.com says: > > First - I'm not sure it *deals* with SNMP over IP. Is host-to-host > good enough to feel secure? Second - I'm sure IPX has it's own > authentication/privacy (I know very little about IPX, or > AppleTalk - but I'm sure somebody here could shed some > light on this issue)... I believe very soon ALL the > underlying protocols will be secure - but they > can't guarantee security for upper layers, > i.e. if I happen to be on the same host > the NMS is, and I can screw around > with UDP traffic, you'll have no > way to distinguish between > "clean" secured IP packets sent > by your NMS from those I forged using > the advantage of being on the same host... > > Is this a threat? > -- > Regards, > Uri uri@watson.ibm.com N2RIU > ----------- > > I think, there are different threats to consider. One is the security of the network connecting the hosts, which may rely on services out of your control (leased lines, etc.) and therefore without control over eavesdroppers. The other is secure access to processes on the *same* host. If there is a security hole in the local operating system, secure-SNMP won't help anything. It may even be possible to modify system parameters directly without using any agents and management system at all. So we need generally secure communication *and* secure processes on the host. If you consider attacks on the network as the major security problem (as e.g. with SNMPv1), secure-IP (and other lower layer protocols) are sufficient. Until such secure transport protocols exist, relying on security in Layer 7 is a great help when using networks. H. Nikolaus Schaller __________________________________________________________________ Dr. H. Nikolaus Schaller D-80290 Muenchen, F.R.G Lehrstuhl fuer Datenverarbeitung hns@ldv.e-technik.tu-muenchen.de Technische Universitaet Muenchen Tel: +49-89-2105-3606 Arcisstr. 21 DL2MHJ Fax: +49-89-2105-3600 __________________________________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01322; 11 Nov 94 7:18 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01318; 11 Nov 94 7:18 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa03650; 11 Nov 94 7:18 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma012200; Fri Nov 11 06:49:24 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa17535; 11 Nov 94 6:38 EST Received: from sol.tis.com by magellan.TIS.COM id aa17531; 11 Nov 94 6:33 EST Received: from uu3.psi.com(38.145.250.2) by relay via smap (V1.3) id sma012092; Fri Nov 11 06:33:28 1994 Received: from pes5.hns.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA23620 for snmp2@tis.com; Fri, 11 Nov 94 06:33:24 -0500 Received: by pes5.hns.com (1.37.109.4/2.1-Hughes Network Systems) id AA07793; Fri, 11 Nov 94 06:33:22 -0500 Message-Id: <9411111133.AA07793@pes5.hns.com> To: snmp2@tis.com Subject: varbind exceptions: Date: Fri, 11 Nov 94 06:33:21 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Ward We are implementing an SNMPv2 proxy agent, and I have some questions on the use of varbind exceptions. Stallings' book has the following PDU format for varbinds: -- variable binding VarBind ::= SEQUENCE {name ObjectName, CHOICE {value ObjectSyntax, unspecified NULL, noSuchObject [0] IMPLICIT NULL, noSuchInstance [1] IMPLICIT NULL, endoOfMibView [2] IMPLICIT NULL }} I have two questions: 1. How can you tell a value of 0, 1 or 2 from the exception values of 0, 1, and 2 specified for noSuchObject, noSuchInstance and endoOfMibView? Is this implemented as some type of union? 2. Can the exception values be extended on an application basis? For example, if the proxy agent can't communicate to our proprietary equipment, it doesn't make sense to return noSuchInstance. We'd like to return something like noResponse. On a separate note, are there any books that deal in detail with SNMPv2 issues. All of the books I've looked at treat SNMPv2 as an afterthought to SNMPv1. Since we are not going to deal with v1, we'd like to read about a book that deals with v2. Thanks in advance, David Ward (301) 212-1022 (phone) (301) 212-2089 (fax) dward@hns.com (email) Hughes Network Systems Germantown, Md   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02610; 11 Nov 94 9:55 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02606; 11 Nov 94 9:55 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa05868; 11 Nov 94 9:55 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma014121; Fri Nov 11 09:28:36 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa18755; 11 Nov 94 9:24 EST Received: from sol.tis.com by magellan.TIS.COM id aa18747; 11 Nov 94 9:18 EST Received: from nic.stpaul.ncr.com(131.222.1.3) by relay via smap (V1.3) id sma013924; Fri Nov 11 09:18:31 1994 Received: from ncrcos.StPaul.NCR.COM by nic.StPaul.NCR.COM (4.0/NCR-STP/1.0) id AA29673; Fri, 11 Nov 94 08:18:13 CST Received: from csdpc234 by ncrcos.StPaul.NCR.COM (4.1/NCR-STP/1.0) id AA24596; Thu, 10 Nov 94 16:26:02 CST Message-Id: <9411102226.AA24596@ncrcos.StPaul.NCR.COM> X-Sender: meyer@ncrcos Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Nov 1994 16:38:24 -0600 To: snmp2@tis.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paul Meyer Subject: Re: SNMPv1.5 (tm) X-Mailer: This area has been coming up a lot recently. Secure FTP, secure SNMP, secure e-mail, yayayayaya..... The simplest solution would be to add security and authentication options to the transport laters (UDP, TCP, whateverP), and use the groundrules we've been putting into secure SNMP as aids in developing understandable means of handling the various levels of security, key transfers (and initialization), and the other hoary issues. Otherwise each new protocol on the block (secure gopher??) will be doing the exact same work. So, I really really like the simplified SNMPv2 idea, particularily since I really want getbulk and agentcaps. For Ran and the other security gurus, let's also really push to move authentication/encryption work down to transport AND GET IT TO HAPPEN! Paul Meyer NCR NPD St. Paul Internet: Paul.Meyer@StPaul.NCR.COM M/S S045 2700 N Snelling St Paul MN 55113 (612) 638-2754   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03215; 11 Nov 94 10:55 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03211; 11 Nov 94 10:55 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa06928; 11 Nov 94 10:55 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma014922; Fri Nov 11 10:22:22 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa21431; 11 Nov 94 10:12 EST Received: from sol.tis.com by magellan.TIS.COM id aa21426; 11 Nov 94 10:06 EST Message-Id: <9411111506.AA14709@relay.tis.com> Received: from morpheus.bbn.com(128.89.8.217) by relay via smap (V1.3) id sma014707; Fri Nov 11 10:06:30 1994 To: snmp2@tis.com Subject: Re: SNMPv1.5 (tm) Date: Fri, 11 Nov 94 10:06:34 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Waitzman Paul Meyer wrote: > The simplest solution would be to add security and authentication options to > the transport laters (UDP, TCP, whateverP), and use the groundrules we've > been putting into secure SNMP as aids in developing understandable means of > handling the various levels of security, key transfers (and initialization), > and the other hoary issues. Otherwise each new protocol on the block > (secure gopher??) will be doing the exact same work. > For Ran and the other security gurus, let's also really push to move > authentication/encryption work down to transport AND GET IT TO HAPPEN! My take on this question is one of subsystem vulnerability analysis. This is one of the principles of SNMP-- it must work when most subsystems are busted. Will transport layer security mechanisms be robust enough to deal with broken networks? For instance, transport security might want to depend upon closely synchronized clocks. SNMPv2 security has lots of complexity to allow resyncing clocks. Now, I'm not sure that this SNMPv2 feature has been stress tested in broken networks to see how fast it can resync the clocks and get back to doing real management but SNMPv2 at least has the goal of working in this case. -david   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05110; 11 Nov 94 13:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05106; 11 Nov 94 13:47 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa10021; 11 Nov 94 13:47 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma017661; Fri Nov 11 13:06:32 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa00801; 11 Nov 94 12:59 EST Received: from sol.tis.com by magellan.TIS.COM id aa00791; 11 Nov 94 12:52 EST Received: from unknown(171.69.1.158) by relay via smap (V1.3) id sma017463; Fri Nov 11 12:52:41 1994 Received: (jjohnson@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id JAA14872 for snmp2@tis.com; Fri, 11 Nov 1994 09:52:27 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Jeffrey T. Johnson" Message-Id: <199411111752.JAA14872@feta.cisco.com> Subject: Re: SNMPv1.5 (tm) To: snmp2@tis.com Date: Fri, 11 Nov 94 9:52:27 PST In-Reply-To: <9411102226.AA24596@ncrcos.StPaul.NCR.COM>; from "Paul Meyer" at Nov 10, 94 4:38 pm X-Mailer: ELM [version 2.3 PL11] Hi Paul, The main drawback I see with pushing security down to the transport layer is that then you are only as secure as your most insecure transport layer. For those of use who run SNMP over multiple transport protocols, having secure UDP won't help if AppleTalk, IPX, etc are still insecure. Yes, someday they may all be secure (but then again, maybe not). In the interim we are stuck with a management protocol that many folks can't do management with because they won't enable set-requests. /jeff Paul Meyer sez: > >This area has been coming up a lot recently. Secure FTP, secure SNMP, >secure e-mail, yayayayaya..... > >The simplest solution would be to add security and authentication options to >the transport laters (UDP, TCP, whateverP), and use the groundrules we've >been putting into secure SNMP as aids in developing understandable means of >handling the various levels of security, key transfers (and initialization), >and the other hoary issues. Otherwise each new protocol on the block >(secure gopher??) will be doing the exact same work. > >So, I really really like the simplified SNMPv2 idea, particularily since I >really want getbulk and agentcaps. > >For Ran and the other security gurus, let's also really push to move >authentication/encryption work down to transport AND GET IT TO HAPPEN!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06900; 11 Nov 94 16:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06896; 11 Nov 94 16:25 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa12806; 11 Nov 94 16:25 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma021046; Fri Nov 11 15:39:38 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa02922; 11 Nov 94 15:35 EST Received: from sol.tis.com by magellan.TIS.COM id aa02918; 11 Nov 94 15:26 EST Received: from quern.epilogue.com(128.224.1.136) by relay via smap (V1.3) id sma020841; Fri Nov 11 15:27:04 1994 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Bridgham X-Orig-Sender: dab@epilogue.com To: snmpv2@tis.com In-Reply-To: Bob Natale's message of Thu, 10 Nov 1994 13:37:15 EST Subject: SNMPv1.5 (tm) Date: Fri, 11 Nov 94 15:25:03 -0500 Message-Id: <9411111525.aa20718@quern.epilogue.com> > From: Iain K. Hanson > Date: Thu, 10 Nov 94 18:57:59 +0100 > Now that I understand the admin model I like it, I must admit to a similar reaction. I spend a lot of time these days explaining various parts of snmp and our implementation of it to others. I've found that it now only takes me about 20 minutes to give a decent overview of the v2 adminsitrative model and they often respond with, "Is that all? I'd heard it was complicated.". What it needs most is a reasonable user interface. Hand configuring that stuff is out of the question for most users. Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14056; 11 Nov 94 23:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14052; 11 Nov 94 23:12 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa19591; 11 Nov 94 23:12 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma026647; Fri Nov 11 22:45:08 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa04337; 11 Nov 94 22:35 EST Received: from sol.tis.com by magellan.TIS.COM id aa04333; 11 Nov 94 22:29 EST Received: from einstein.technet.sg(192.169.33.50) by relay via smap (V1.3) id sma026300; Fri Nov 11 22:11:19 1994 Received: (from trilyc@localhost) by einstein.technet.sg (8.6.9/8.6.9) id LAA26938; Sat, 12 Nov 1994 11:11:11 +0800 Date: Sat, 12 Nov 1994 11:11:11 +0800 (SST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Lai Yit-Chun To: snmp2@tis.com Subject: unsubscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe trilyc@technet.sg   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02816; 14 Nov 94 10:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02808; 14 Nov 94 10:12 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa06943; 14 Nov 94 10:12 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma012173; Mon Nov 14 09:37:26 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa11481; 14 Nov 94 9:28 EST Received: from sol.tis.com by magellan.TIS.COM id aa11476; 14 Nov 94 9:21 EST Received: from uu3.psi.com(38.145.250.2) by relay via smap (V1.3) id sma012033; Mon Nov 14 09:21:35 1994 Received: from sdesys1.hns.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA13460 for snmp2@tis.com; Mon, 14 Nov 94 09:21:26 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Chakravarthy Kolli Received: by sdesys1.hns.com (1.37.109.11/2.1-Hughes Network Systems) id AA296452881; Mon, 14 Nov 1994 09:21:21 -0500 Message-Id: <199411141421.AA296452881@sdesys1.hns.com> Subject: CMU code ported to HP/UX? To: snmp2@tis.com Date: Mon, 14 Nov 1994 09:21:20 -0500 (EST) X-Hpvue$Revision: 1.8 $ Mime-Version: 1.0 Content-Type: Message/rfc822 X-Vue-Mime-Level: 4 X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 216 Hi, Has anyone ported the agent part of CMU SNMPV2 code to HP/UX? There is some kernel specific code that needs to be ported. I would appreciate any information you can give me. Thanks very much, Chak Kolli   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04648; 14 Nov 94 11:33 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04638; 14 Nov 94 11:33 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa08958; 14 Nov 94 11:33 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma013550; Mon Nov 14 10:53:32 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa14792; 14 Nov 94 10:37 EST Received: from sol.tis.com by magellan.TIS.COM id aa14787; 14 Nov 94 10:28 EST Received: from tix.timeplex.com(134.196.2.121) by relay via smap (V1.3) id sma013083; Mon Nov 14 10:29:12 1994 Received: from torch.timeplex.com by tix.timeplex.com (4.1/SMI-4.1) id AA01825; Mon, 14 Nov 94 10:29:45 EST Received: from ws-4.timeplex.com by torch.timeplex.com (4.1/SMI-4.1) id AA00737; Mon, 14 Nov 94 09:18:53 CST Date: Mon, 14 Nov 94 09:18:53 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "douglas beeman (tv" Mmdf-Warning: Parse error in original version of preceding line at magellan.TIS.COM Message-Id: <9411141518.AA00737@torch.timeplex.com> Subject: Re: Karl's comment on snmpV2 security Apparently-To: >It is a matter for discussion whether we need the existing structure >which can build an access matrix to the degree that we can define for >every electron in the universe what other electrons it can see or talk >to. Finally, the crux of this long string on admin/security! dB   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07692; 14 Nov 94 13:57 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07687; 14 Nov 94 13:57 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa13013; 14 Nov 94 13:57 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma015372; Mon Nov 14 12:49:44 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa19775; 14 Nov 94 12:34 EST Received: from sol.tis.com by magellan.TIS.COM id aa19771; 14 Nov 94 12:25 EST Received: from tix.timeplex.com(134.196.2.121) by relay via smap (V1.3) id sma014998; Mon Nov 14 12:26:12 1994 Received: from torch.timeplex.com by tix.timeplex.com (4.1/SMI-4.1) id AA03224; Mon, 14 Nov 94 12:26:56 EST Received: from ws-4.timeplex.com by torch.timeplex.com (4.1/SMI-4.1) id AA01042; Mon, 14 Nov 94 11:16:06 CST Date: Mon, 14 Nov 94 11:16:06 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "douglas beeman (tv" Mmdf-Warning: Parse error in original version of preceding line at magellan.TIS.COM Message-Id: <9411141716.AA01042@torch.timeplex.com> Subject: Re: Karl's comment on snmpV2 security Apparently-To: >It is a matter for discussion whether we need the existing structure >which can build an access matrix to the degree that we can define for >every electron in the universe what other electrons it can see or talk >to. Finally, the crux of this long string on admin/security! dB   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10377; 14 Nov 94 16:44 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10373; 14 Nov 94 16:44 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa16504; 14 Nov 94 16:44 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma019124; Mon Nov 14 16:07:58 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa21410; 14 Nov 94 16:00 EST Received: from sol.tis.com by magellan.TIS.COM id aa21406; 14 Nov 94 15:51 EST Message-Id: <9411142052.AA18889@relay.tis.com> Received: from vnet.ibm.com(199.171.26.4) by relay via smap (V1.3) id sma018887; Mon Nov 14 15:52:17 1994 Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 3406; Mon, 14 Nov 94 15:51:31 EST Date: Mon, 14 Nov 94 15:45:45 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: zbam@vnet.ibm.com To: snmpv2@tis.com Cc: bstewart@cisco.com Subject: Any plans to discuss Steve's drafts??? Bob - Please do not forget Inform Request. I think Inform request is a nice manager to manager communication facility using open standards. Z Bam   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00955; 15 Nov 94 5:19 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00951; 15 Nov 94 5:19 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa02022; 15 Nov 94 5:19 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma028751; Tue Nov 15 04:55:52 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa23308; 15 Nov 94 4:53 EST Received: from sol.tis.com by magellan.TIS.COM id aa23304; 15 Nov 94 4:44 EST Received: from unknown(192.188.132.4) by relay via smap (V1.3) id sma028690; Tue Nov 15 04:44:35 1994 Received: by gatekeeper.icl.co.uk (4.1/UNIPALM-Vevision: 1.3 gatekeeper.icl.co.uk) id AA20360; Tue, 15 Nov 94 09:47:35 GMT Received: from unknown(145.227.14.59) by gatekeeper via smap (V1.3mjr) id sma020337; Tue Nov 15 09:47:03 1994 Received: from norman.win.icl.co.uk (norman.win01.icl.co.uk) by ming.oasis.icl.co.uk id AA16449; Tue, 15 Nov 94 09:44:28 GMT Received: by win.icl.co.uk (4.1/SMI-4.1) id AA02092; Tue, 15 Nov 94 09:42:46 GMT Date: Tue, 15 Nov 94 09:42:46 GMT Message-Id: <9411150942.AA02092@win.icl.co.uk> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bab@win.icl.co.uk To: snmpv2@tis.com Subject: SNMPV2 and GSSAPI Content-Length: 252 Is there any current, or projected, synergy between the IETF work on SNMPV2 security and the IETF work on the Generic Security Service Application Program Interface (rfc 1508 & 1509)? Barry A Byrne bab@win.icl.co.uk   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08063; 16 Nov 94 14:53 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08058; 16 Nov 94 14:53 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa15439; 16 Nov 94 14:53 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma022899; Wed Nov 16 14:16:08 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa13972; 16 Nov 94 14:11 EST Received: from sol.tis.com by magellan.TIS.COM id aa13968; 16 Nov 94 14:00 EST Received: from mail.netcom.com(192.100.81.99) by relay via smap (V1.3) id sma022047; Wed Nov 16 14:00:23 1994 Received: from heimdall.strata.com by mail.netcom.com (8.6.9/Netcom) id LAA15496; Wed, 16 Nov 1994 11:00:30 -0800 Received: from kiwi.Strata.COM ([199.35.98.98]) by heimdall.strata.com (4.1/SMI-4.1/Heimdall.Strata.Com-GCA-931007) id AA15344; Wed, 16 Nov 94 11:09:12 PST Received: from bahagia.strata.com by kiwi.Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA05963; Wed, 16 Nov 94 10:58:56 PST Received: by bahagia.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA27799; Wed, 16 Nov 94 11:00:01 PST Date: Wed, 16 Nov 94 11:00:01 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Timon Sloane Message-Id: <9411161900.AA27799@bahagia.strata.com> To: snmp2@tis.com Subject: re: TimeStamp definition in Textual conventions ...the suggestion doesn't work since the SYNTAX is different for TimeInterval and a TimeStamp in the words of Emily Latella nevermind Mike Thatcher   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09280; 16 Nov 94 15:58 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09276; 16 Nov 94 15:58 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa17015; 16 Nov 94 15:58 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma024492; Wed Nov 16 15:28:43 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa14704; 16 Nov 94 15:23 EST Received: from sol.tis.com by magellan.TIS.COM id aa14700; 16 Nov 94 15:16 EST Received: from mail.netcom.com(192.100.81.99) by relay via smap (V1.3) id sma024276; Wed Nov 16 15:17:05 1994 Received: from heimdall.strata.com by mail.netcom.com (8.6.9/Netcom) id MAA27129; Wed, 16 Nov 1994 12:16:48 -0800 Received: from kiwi.Strata.COM ([199.35.98.98]) by heimdall.strata.com (4.1/SMI-4.1/Heimdall.Strata.Com-GCA-931007) id AA15287; Wed, 16 Nov 94 10:53:18 PST Received: from bahagia.strata.com by kiwi.Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA05832; Wed, 16 Nov 94 10:43:01 PST Received: by bahagia.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA27770; Wed, 16 Nov 94 10:44:06 PST Date: Wed, 16 Nov 94 10:44:06 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Timon Sloane Message-Id: <9411161844.AA27770@bahagia.strata.com> To: snmp2@tis.com Subject: TimeStamp description in RFC 1443 Cc: thatcher@timonware.com Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM The current description of TimeStamp ties it directly to sysUpTime. Perhaps it could be changed to "the value of a TimeInterval object such as sysUpTime..." so that a mib may define it's own TimeInterval object and use it for a value in a TimeStamp object. Mike Thatcher thatcher@timonware.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12288; 16 Nov 94 18:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12284; 16 Nov 94 18:25 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa21892; 16 Nov 94 18:25 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma027576; Wed Nov 16 17:53:53 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa19486; 16 Nov 94 17:45 EST Received: from sol.tis.com by magellan.TIS.COM id aa19482; 16 Nov 94 17:39 EST Received: from gateway.sctc.com(192.55.214.1) by relay via smap (V1.3) id sma027424; Wed Nov 16 17:39:34 1994 Received: from sccmailhost.sctc.com (sccmailhost.sctc.com [192.55.214.100]) by gateway.sctc.com (8.6.9/8.6.9) with SMTP id QAA12059 for ; Wed, 16 Nov 1994 16:04:17 -0600 Received: from sccmailhost.sctc.com by sccmailhost.sctc.com id 055390000; 16 Nov 94 16:06 CST Received: from spirit by sccmailhost.sctc.com id 246390000; 16 Nov 94 16:06 CST Received: from dreez.sctc.com (dreez [172.17.192.47]) by spirit.sctc.com (8.6.9/8.6.9) with ESMTP id QAA26966 for ; Wed, 16 Nov 1994 16:04:33 -0600 Received: from localhost (endrizzi@localhost) by dreez.sctc.com (8.6.9/8.6.9) with SMTP id QAA11039 for ; Wed, 16 Nov 1994 16:04:30 -0600 Message-Id: <199411162204.QAA11039@dreez.sctc.com> X-Authentication-Warning: dreez.sctc.com: Host localhost didn't use HELO protocol To: snmpv2@tis.com Reply-To: endrizzi@sctc.com Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM X-Face: %g)Bc*Vo+T5nV>m7VM5n}%xP^bGU)?Stw,ndIzF30kWjk8{8Mu,&*?(7$+$:Z+~@(oM109x yCPP}i2*|u:\Yl*Qj|^DD"J#AesTrhjj;5\^[XGt6Vp_}4*mcsS{S3Fb4thWB]Q#XbXG>mTeRX;w1h rtl3[Fw|SV<(myo3$ao|08'#ww/eaO=7Ps_#AOs9\ Subject: SNMPv2 and IPv6 Auth X-Mailer: exmh version 1.5phi 9/15/94 Date: Wed, 16 Nov 1994 16:04:27 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Michael Endrizzi Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM I am interested in the topic of why SNMPv2 can/cannot use IPv6 security mechanisms instead of the RFC1445, 1446. So far I see two problems: 1) IPv6 does not protect against replay attacks. Although IPv6 has a Fragment Offset field, it is only used for intra-packet fragmentation and does not replace the protection of SNMPv2 clock synch. 2) As others have stated, SNMPv2 needs to run over other protocols besides IP Am I right? Are there others? dreez --------------------------------------------------- "The above opinions where not mine but that of the American people." Michael J. Endrizzi;SCC; 2675 Long Lake Road MS. 203 Roseville, MN 55113;endrizzi@sctc.com ---------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02848; 17 Nov 94 10:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02844; 17 Nov 94 10:07 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa07213; 17 Nov 94 10:07 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma005107; Thu Nov 17 09:39:45 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa21458; 17 Nov 94 9:36 EST Received: from sol.tis.com by magellan.TIS.COM id aa21454; 17 Nov 94 9:29 EST Received: from inet-gw-3.pa.dec.com(16.1.0.33) by relay via smap (V1.3) id sma004785; Thu Nov 17 09:11:52 1994 Received: from cssec4.pcs.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA16599; Thu, 17 Nov 94 06:08:43 -0800 Received: by cssec4.pcs.dec.com (5.57/jmh-inet-gw-v1.05); id AA06836; Thu, 17 Nov 94 15:08:34 +0100 Message-Id: <9411171408.AA06836@cssec4.pcs.dec.com> To: snmpv2@tis.com Cc: ihanson@cssec4.pcs.dec.com Subject: Re: Security was Re: SNMPv1.5 (tm) In-Reply-To: Your message of "Tue, 15 Nov 94 21:30:39 EST." <9411160230.AA23229@buoy.watson.ibm.com> Date: Thu, 17 Nov 94 15:08:34 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Iain K. Hanson" X-Mts: smtp Uri wrote: >> Also, many users will not want to pay the performance penalty of >> secure IP ( or >> any other network layer) for all traffic just so that system administration is >> secure. >That will be not up to them! They'll have just as much affect over whether >the IP traffic is secured (with all the penalties of it :-), as they have >today (:-). Uhhh! As I understand it, IPv6 security *Must* be optional, not least because in some coumtries you can lose your life for using encryption. Not that this helps SNMPv2. BobN wrote: >I am sorry to have to admit that I sometimes trade off engineering >"completeness" for marketplace "now-ness"...time-to-market is really >critical today, it seems...especially for standards-based solutions. Bob, I agree with you whole heartidly - where this is necessary. But, I am also loathe to 'throw out the baby with the bath water' and I am not *yet* convinced that it is necessary to do so. and Uri wrote: >> If we can get good security definitions that implementators can uderstand and >> implementations that users do not find a burden, then I believe it will be as >> popular as PGP. >Yeah, but in this case - not a chance (:-). This is the begining of the review process for SNMPv2 and I believe we should at least make an attempt at it, although I do understand the sentiment. That SNMPv2 is implementable is evidenced by the pulicly available implementations. From the discussions on this list, there seems to be agreement that the current documentation needs to be improved. What I would most like to understand is if there are problems other than the documentation. ( My own implementation experience is far from complete as I am only in the design phase. ) For instance; 1) Are agent implementations too time/space expensive? 2) Are Managers & Agents to difficult to configure? If so, is there evedience that this is the fault of the standard and not the implementation. 3) something else? If so, what? On the documentation front, I've at last managed to read most of the new I-Ds and I would particularly like to thank our editor for the work he has put in. I particularly like the improvements in snmpV2-sec.txt. However, I have always felt that 12 documents is far to many unless absolutely necessary. I find it a significant barrier that I need to refer to the Admin model, security, protocol, and party mib documents in order to understand what should be going on. There is also a substancial overlap in content between snmpV2-admin.txt and snmpV2-sec.txt and I personally feel that it would be an improvment to amalgamte these two documents. I would probablely go for adding in the snmpV2-proto.txt as well, giving one document that defined the protocol and state machine for SNMPv2. Any comments? /ikh   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01015; 18 Nov 94 7:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01011; 18 Nov 94 7:11 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa03219; 18 Nov 94 7:11 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa23027; Fri Nov 18 06:48:40 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa03864; 18 Nov 94 6:45 EST Received: from sol.tis.com by magellan.TIS.COM id aa03860; 18 Nov 94 6:41 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.3) id sma022957; Fri Nov 18 06:42:16 1994 Received: from pcsbst.pcs.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA09507; Fri, 18 Nov 94 03:38:33 -0800 Received: by pcsbst.pcs.dec.com (5.65/jmh-inet-gateway-sendmail-V1.05); id AA00196; Fri, 18 Nov 1994 12:38:29 +0100 Message-Id: <9411181138.AA00196@pcsbst.pcs.dec.com> To: snmpv2@tis.com Cc: ihanson@pcsbst.pcs.dec.com Subject: Re: Security was Re: SNMPv1.5 (tm) In-Reply-To: Your message of "Thu, 17 Nov 94 18:05:42 EST." <9411172305.AA23928@buoy.watson.ibm.com> Date: Fri, 18 Nov 94 12:38:29 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Iain K. Hanson" X-Mts: smtp Hi, Uri wrote: >I'm not sure. For imbedded applications and such, you may very >well want NOT to waste that extra 100KB. Many if not most of the SNMPv1 managed elements that I have used or come across have required an additional board ( processor and memory ) in order to handle being managed. There are also devices that will not for the forseeable future, directly support SNMPv1 or SNMPv2. For these we can use a proxy. I agree that there must be a balance, but I don't think 100kb is to high a price to pay for secure system admin. /ikh   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01463; 18 Nov 94 8:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01459; 18 Nov 94 8:47 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa04566; 18 Nov 94 8:47 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma024667; Fri Nov 18 08:20:16 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa04067; 18 Nov 94 8:11 EST Received: from sol.tis.com by magellan.TIS.COM id aa04063; 18 Nov 94 8:06 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.3) id sma024550; Fri Nov 18 08:07:19 1994 Received: from pcsbst.pcs.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA14869; Fri, 18 Nov 94 05:04:11 -0800 Received: by pcsbst.pcs.dec.com (5.65/jmh-inet-gateway-sendmail-V1.05); id AA00607; Fri, 18 Nov 1994 14:04:07 +0100 Message-Id: <9411181304.AA00607@pcsbst.pcs.dec.com> To: snmpv2@tis.com Cc: ihanson@pcsbst.pcs.dec.com Subject: Re: Security was Re: SNMPv1.5 (tm) In-Reply-To: Your message of "Thu, 17 Nov 94 22:03:58 PST." <9411180603.AA05054@cavebear.com> Date: Fri, 18 Nov 94 14:04:07 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Iain K. Hanson" X-Mts: smtp Hi Karl, >And comes to my point -- if everybody uses the same tools to avoid >this kind of problem, then few, if any, will be using the fully admin >MIB capabilities. So why bother having so much unused complexity? I'm afraid that I don't agree with your assumptions here. I agree that good tools are needed, in order to simplify configuration of the Party MIB in agents and Managers. And I see no reason why such tools should not have default sets of assumptions. However, such assumptions would need to be over-rideable by the user, if they are to be of real use to larger organisations. Management policy on a large net can be anything from fully centralised to very devolved and what is just a mere detail to one can be vital to another. I also believe that it is possible to build tools that allow correct fine grained control that are easy to use via a GUI ( I hope so because thats what I'm working on :-). ) As Grady Booch writes "The task of the software development team is to engineer the illusion of simplicity". >we'd just lose the ability > to give each grain of sand on the beach its own collection of parties I believe that this is just a side effect of good generalisation rather than over-specification. >Let's try to revive the concept of "simplicity". I believe that Albert Einstein is attributed as saying "Make things a simple as possible, but no simpler." /ikh   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02388; 18 Nov 94 9:57 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02384; 18 Nov 94 9:57 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa06407; 18 Nov 94 9:57 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma026307; Fri Nov 18 09:21:25 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa04492; 18 Nov 94 9:18 EST Received: from sol.tis.com by magellan.TIS.COM id aa04488; 18 Nov 94 9:12 EST Received: from emory.mathcs.emory.edu(128.140.110.1) by relay via smap (V1.3) id sma026002; Fri Nov 18 09:13:18 1994 Received: from bir.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.9) via UUCP id AA24414 ; Fri, 18 Nov 94 09:13:05 -0500 Return-Path: mlk%bir.UUCP@mathcs.emory.edu Received: by bir.bir.com (uA-1.6v2); Fri, 18 Nov 94 09:11:01 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Michael L. Kornegay" To: snmpv2@tis.com Subject: Re: Security was Re: SNMPv1.5 (tm) Date: Fri, 18 Nov 94 09:11:01 EST Reply-To: mlk%bir.UUCP@mathcs.emory.edu Message-Id: <0D15DDF1.f48145@bir.bir.com> X-Mailer: uAccess - Macintosh Release: 1.6v2 In Regards to your letter <9411180603.AA05054@cavebear.com>: > Both Steve W's proposals and a number of the tools I've seen simplify > configuration by making some large assumptions about views and such, > so that most of the complexity of configuration is not presented to > the administrator. > > Are your tools of that nature? > > Assuming, for the moment, that your answer is "yes", then it becomes > an interesting question whether we need the all the mechanisms found > in the administrative mib. If people use streamlined configuration tools, > then perhaps we could elide out those unused mechanisms from the admin > mib. It is important that these sort of tools all implement the same (standardized) style or conventions for "streamlining". The administrative model seems to provide so many options, that many of us are worried about the ability to successfully configure and update (clock sync) parties in an interoperable environment of many products from many vendors. If we dont get this right, customers will run into situations were the streamlining only works for their own products, and the customer has to go crazy with the low-level party mib configuration to interact with 3rd party stuff. I dont think we want this... The party mib configuration and the administrative model are interoperability issues. Lets go back to the basic goals of snmp, simplicity and inter- operability among very diverse systems. I hope we are not foolish enough to label this a 'host issue', it is an *interoperability* issue. Many snmp'ers have been proud to point out that too many options and complexity is what has made CMIP hard to deploy, lets not screw up the snmp with a problematic, complex, and option rich administrative model. ___________________ Michael L. Kornegay Internet: mlk@bir.com UUCP: bir!mlk AppleLink: mlk@bir.com@INTERNET#   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04416; 18 Nov 94 11:36 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04411; 18 Nov 94 11:36 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa09461; 18 Nov 94 11:36 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma028195; Fri Nov 18 10:56:35 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa05729; 18 Nov 94 10:55 EST Received: from sol.tis.com by magellan.TIS.COM id aa05724; 18 Nov 94 10:49 EST Received: from ctron.com(134.141.197.25) by relay via smap (V1.3) id sma028062; Fri Nov 18 10:49:38 1994 Received: from stealth.ctron.com by ctron.com (4.1/SMI-4.1) id AA02563; Fri, 18 Nov 94 10:49:01 EST Received: from ctron.ctron by stealth.ctron.com (4.1/SMI-4.1) id AA22148; Fri, 18 Nov 94 10:48:37 EST Received: from portsmou by ctron.ctron (4.1/SMI-4.1) id AA15858; Fri, 18 Nov 94 10:48:38 EST Received: by portsmou (931110.SGI/) for snmpv2@tis.com id AA26891; Fri, 18 Nov 94 10:47:23 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Daniel Mahoney Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Message-Id: <9411181047.ZM26887@portsmou> Date: Fri, 18 Nov 1994 10:47:19 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: snmpv2@tis.com Subject: Modification of SnmpV2 Security Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 This contains some ideas for changes in the SnmpV2 Party MIB. The first section discusses the changes; the second lays out the new Party MIB and the last section talks about changes to the format of the SnmpV2 message. Discussion ---------- As I've been implementing SnmpV2 for our NMS, I've come across some places in the Party MIB that I would like to see changes. When the NMS sets up the party pairs for authenticated communication, it sets up a key for each of the manager parties, but really these parties represent the same SnmpV2 entity. So I would like to be able to reuse the authentication key across all manager parties. To do this, I've created an AunthenticationEntry which contains the type of authentication protocol and the key(s) used for it. The second change to the MIB revolves about the privacy information. If I want to reuse the encryption key across a number of devices, there is no way to do this. In addition, I believe that encryption is part of how an NMS talks to a device and part of who the NMS is. So I've suggested a new PrivacyEntry and moving the privacy information from the party to the context. Party MIB changes ----------------- Below, I list the changes to the PartyEntry and ContextEntry plus the new AuthenticationEntry and PrivacyEntry. * = changes PartyEntry ::= SEQUENCE { partyIdentity Party, partyIndex INTEGER, partyTDomain OBJECT IDENTIFIER, partyTAddress TAddress, partyMaxMessageSize INTEGER, partyLocal TruthValue, * partyAuthIndex INTEGER, partyAuthClock Clock, partyAuthLifetime INTEGER, partyCloneFrom Party, partyStorageType StorageType, partyStatus RowStatus } ContextEntry ::= SEQUENCE { contextIdentity Context, contextIndex INTEGER, contextLocal TruthValue, contextViewIndex INTEGER, contextLocalEntity OCTET STRING, contextLocalTime OBJECT IDENTIFIER, contextProxyDstParty Party, contextProxySrcParty Party, contextProxyContext OBJECT IDENTIFIER, * contextPrivacyIndex INTEGER, contextStorageType StorageType, contextStatus RowStatus } *AuthenticationEntry ::= * SEQUENCE { * authAuthIndex INTEGER, * authAuthProtocol OBJECT IDENTIFIER, * authAuthPrivate OCTET STRING, * authAuthPublic OCTET STRING, * authStorageType StorageType, * authStatus RowStatus } *PrivacyEntry ::= * SEQUENCE { * privPrivIndex INTEGER, * privPrivProtocol OBJECT IDENTIFIER, * privPrivPrivate OCTET STRING, * privPrivPublic OCTET STRING, * privStorageType StorageType, * privStatus RowStatus } Message format changes ---------------------- By virtue of moving the privacy from a party to the context, the format of an SnmpV2 message needs to change. When transmitting a private message, the context used for the encryted message needs to be the first part of the message, instead of the destination party. Happy Hunting, DOM II   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01013; 21 Nov 94 6:23 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01009; 21 Nov 94 6:23 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa02634; 21 Nov 94 6:23 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smac16113; Mon Nov 21 05:57:27 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa22562; 21 Nov 94 5:55 EST Received: from sol.tis.com by magellan.TIS.COM id aa22554; 21 Nov 94 5:46 EST Received: from thumper.bellcore.com(128.96.41.1) by relay via smap (V1.3) id sma016073; Mon Nov 21 05:47:21 1994 Received: from comsys.dofn.de (inet_srv.comsys.dofn.de [193.141.78.17]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id FAA24648 for ; Mon, 21 Nov 1994 05:46:58 -0500 Received: by comsys.dofn.de (4.1/SMI-4.1) id AA10301; Mon, 21 Nov 94 11:46:13 +0100 Date: Mon, 21 Nov 94 11:46:13 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ruediger Osten Message-Id: <9411211046.AA10301@comsys.dofn.de> To: snmp2@thumper.bellcore.com Subject: SNMPv2 Working Group Please add me to your submission list. Kind regards.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12391; 21 Nov 94 18:03 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12387; 21 Nov 94 18:03 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa17710; 21 Nov 94 18:03 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa26626; Mon Nov 21 17:12:01 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa01876; 21 Nov 94 17:04 EST Received: from sol.tis.com by magellan.TIS.COM id aa01869; 21 Nov 94 16:56 EST Received: from ctron.com(134.141.197.25) by relay via smap (V1.3) id sma026387; Mon Nov 21 16:57:45 1994 Received: from stealth.ctron.com by ctron.com (4.1/SMI-4.1) id AA17851; Mon, 21 Nov 94 16:57:18 EST Received: from express.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA16356; Mon, 21 Nov 94 16:57:12 EST Received: from gimli.ctron by express.ctron.com (4.1/SMI-4.1) id AA17002; Mon, 21 Nov 94 16:57:05 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Harrington Message-Id: <9411212157.AA17002@express.ctron.com> Subject: autodiscovery To: snmpv2@tis.com Date: Mon, 21 Nov 94 16:57:06 EST X-Mailer: ELM [version 2.3 PL11] One problem with snmpv2 is the difficulty of doing autodiscovery, especially in a security-conscious environment. I would like to propose an add-on to snmpv2 which would allow the autodiscovery of snmpv2 devices in a method which is interoperable. I believe the proposal provides a reasonable trade-off between security and the ability to perform auto-discovery of snmpv2 devices. ----------- Contents: Overview Description of the Party MIB changes Party MIB changes Description of an autodiscovery query Design Notes ----------- Overview: For doing autodiscovery, there should be a generic party-pair and context defined which are not specific to a transport address. For example, "adisc1" and "adisc2" parties, a corresponding "adisc" context and an "adisc" MIBview. Upon receiving an "adisc" communication, a discoverable agent responds with an acknowledgement of its existence, and with the source and destination parties and the context which should be used for more extensive discovery. The "adisc" communication is noAuth/noPriv, and the associated view is absolutely minimal - only the source/dest/context for further discovery, which may be null if further discovery is not supported. An error message may be returned as an acknowledgement instead. The parties for *further* discovery may be Auth or Priv parties, so further discovery is only supported by known entities. Description of the Party MIB changes: Autodiscovery messages can be addressed to individual addresses, or broadcast messages can be sent to a range of devices since the party identities are not tied to a transport address. (Agents may need to be modified to support broadcast messages). The "adisc" parties are noAuth/noPriv. They are not tied to transport addresses, and have no clock sync or key requirements. The "adisc" context maps to an "adisc" MIBview containing only three objects - a source party identity, a destination party identity, and a context identity which can be used for subsequent extended discovery. The OID of the "adisc" MIBview should be vendor-independent so it can be used interoperably. The changes to the party MIB are all additions to the existing proposal, so it is easy to add autodiscovery support if it is desired by the customer/network administrator. Here are the proposed Party MIB additions: ----------- Party MIB changes: A v2adisc MIB extension to snmpv2 v2adisc OBJECT IDENTIFIER ::= { partyAdmin 5 } My example uses { partyAdmin 5 } as an example of a vendor-independent subtree, but the actual location would be determined by the appropriate naming authority. srcParty OBJECT-TYPE SYNTAX Party MAXACCESS read-write DESCRIPTION "The source partyIdentity to use for further discovery of the capabilities of this snmpv2 entity " ::= { v2adisc 1 } dstParty OBJECT-TYPE SYNTAX Party MAXACCESS read-write DESCRIPTION "The destination partyIdentity to use for further discovery of the capabilities of this snmpv2 entity " ::= { v2adisc 1 } context OBJECT-TYPE SYNTAX Context MAXACCESS read-write DESCRIPTION "The contextIdentity to use for further discovery of the capabilities of this snmpv2 entity " ::= { v2adisc 1 } // only one per agent, one per interface, one per TDomain? A generic party "adisc1" partyIdentity={ InitialPartyId 1 } Identity does not include IP address partyIndex= < agent unique number > noAuth/noPriv party - the rest as per InitialPartyId.a.b.c.d.1 A generic party "adisc2" partyIdentity={ InitialPartyId 2 } Identity does not include IP address partyIndex= < agent unique number > noAuth/noPriv party - the rest as per InitialPartyId.a.b.c.d.2 A generic context "adisc" contextIdentity={InitialContextID 1 } Identity does not include IP address contextIndex= < datastore unique number > contextViewIndex= < unique datastore index for "v2adisc" MIBview > A view for v2adisc MIB tree viewIndex= viewSubtree = v2adisc viewMask=''H viewType=included ACL Target=< adisc1 party index > Subject=< adisc2 party index > Resources=< adisc context index > Privileges=1 (Get) ACL Target=< adisc2 party index > Subject=< adisc1 party index > Resources=< adisc context index > Privileges=4 (Response) ------------------ Description of an autodiscovery query: NMS query: To do a discovery, the NMS sends a noAuth/noPriv message from "adisc2" to "adisc1" using context "adisc", requesting a GET of three objects in the "adisc" context MIBview. The message can be addressed to "adisc1" at a known IP address, or it can be a broadcast message. privDst = "adisc1" dstParty= "adisc1" srcParty= "adisc2" context = "adisc" PDU=get_request( v2adisc.srcParty, v2adisc.dstParty, v2adisc.context ) Agent Reply: 1) No reply A secure agent that does not support generic adisc The "adisc" parties are not present in the party table This agent may support re-discovery via another known party. 2) NoSuchObject or returns { src=0 dst=0 context=0 } A semi-secure agent that will acknowledge its existence, The v2adisc MIB is not implemented, or the v2adsic MIB has values "0" so further discovery cannot be done. 3) returns the values for the requested data Discoverer can then make further contact through the v2adisc parties and context. Note that the v2adisc parties may be Auth or Priv if desired, so further information-discovery can only be done if the correct keys are known for the v2adisc parties. The extended discovery parties may include viewEntries which can be used to determine vendor-specific information, such as model numbers, or supported applications of of the agent, such as routing. NMS processes response: 1) reply received, ergo device exists at address of reply-sender 2) Read varbinds. If any are 0, we are done processing 3) Read dst_party varbind extract partyIdentity check datastore for existing matching entry if none, create party with known data: partyIdentity partyIndex (generated) partyTDomain (derived from message header ) partyTAddr (derived from message header) partyLocal=false (on manager) partyAuthProtocol=noAuth partyAuthClock=0 partyAuthPrivate=''H partyAuthPublic=''H partyAuthLifetime=0 partyPrivProtocol=noPriv partyPrivPrivate=''H partyPrivPublic=''H 4) Read src_party varbind repeat processing as per dst_party, except partyIndex (generated) partyTAddr (assigned by local admin) partyLocal=true 5) Read context varbind if match not found in local datastore, create contextIdentity=Identity contextIndex (generated) contextLocal=false NMS further discovery: NMS can now attempt to get further info. use the prescribed src_party, dst_party, and context. If the parties existed, any Auth or Priv should be used If the parties were created, they will be noAuth/noPriv. If there is no reply, the NMS should probably assume that the party-pair is new, and Auth or Priv with unknown keys. Human could update to Auth or Auth/Priv and provide known keys. ---------- Design Notes The benefits of this design: 1) interoperable The MIBview is common; the parties and context are device independent 2) works with the existing admin/security model It can be configurd to ignore "adisc" It provides for secure "further" discovery 3) works with existing agents By using standard protocol operations, this proposal should be able to be used with any existing agent. Broadcast support may need to be added to some agents. 4) optional All party MIB changes are additions only, and are not required so existing devices need not support it, and administrators need not allow it. 5) easy to upgrade It can be added to an existing snmpv2 device by adding two new parties, a context, and a viewEntry, and three static objects. 6) easy to configure to meet policy There are many ways to tailor the "adisc" responses to meet NMOC administrative policy. 7) supports controlled extensive discovery of device capabilities can provide acknowledgement with very limited access can provide secure access to "further" large MIBviews 8) supports extensible discovery "further adisc" MIBviews are not defined by RFCs, so they can be extended over time without breaking conformance. "further adisc" MIBviews may support proprietary adisc MIBs. -- ------------------------------------------------- #include David Harrington dbh@ctron.com Cabletron Systems Inc. Spectrum Modeling Group -------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02320; 22 Nov 94 9:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02316; 22 Nov 94 9:41 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa06096; 22 Nov 94 9:41 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma004363; Tue Nov 22 09:09:44 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa03844; 22 Nov 94 9:01 EST Received: from sol.tis.com by magellan.TIS.COM id aa03840; 22 Nov 94 8:51 EST Received: from sun001.cpdsc.com(198.4.54.1) by relay via smap (V1.3) id sma003910; Tue Nov 22 08:53:14 1994 Received: from sun004.cpdsc.com by cpdsc.com (4.1/SMI-4.1) id AA16988; Tue, 22 Nov 94 07:52:07 CST Received: from sun006.CPDSC by sun004.cpdsc.com (4.1/SMI-4.1) id AA08805; Tue, 22 Nov 94 07:54:02 CST Date: Tue, 22 Nov 94 07:54:02 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Colm Bergin Message-Id: <9411221354.AA08805@sun004.cpdsc.com> To: snmpv2@tis.com Subject: Subscribe Please add cbergin@cpdsc.com to the SNMPv2 mailing list. Thanks. cpb ___ Colm Bergin | Phone: (214)519-7349 | Fax: (214)519-7933 Broadband Products Division | Internet: cbergin@cpdsc.com ---------------------------------+------------------------------------------- >>>> DSC Communications Corp., 1000 Coit Rd, MS-826, Plano, Tx 75075 <<<< -----------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04130; 23 Nov 94 10:24 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04126; 23 Nov 94 10:24 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa07175; 23 Nov 94 10:24 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma024992; Wed Nov 23 09:49:08 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa07668; 23 Nov 94 9:46 EST Received: from sol.tis.com by magellan.TIS.COM id aa07664; 23 Nov 94 9:32 EST Received: from hub.meiko.co.uk(192.131.108.80) by relay via smap (V1.3) id sma024580; Wed Nov 23 09:34:14 1994 Received: from nova3.co.uk (nova3-le0.meiko.co.uk) by hub with SMTP id AA24705 (5.65c/IDA-1.4.4 for snmp2@tis.com); Wed, 23 Nov 1994 14:33:49 GMT Received: by nova3.co.uk (5.0/SMI-SVR4) id AA02400; Wed, 23 Nov 1994 14:34:49 +0000 Date: Wed, 23 Nov 1994 14:34:49 +0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Wilson Message-Id: <9411231434.AA02400@nova3.co.uk> To: snmp2@tis.com Subject: subscribe Content-Length: 18 davol@meiko.co.uk   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08336; 23 Nov 94 14:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08332; 23 Nov 94 14:07 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa12948; 23 Nov 94 14:07 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma027518; Wed Nov 23 13:27:05 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa08550; 23 Nov 94 13:18 EST Received: from sol.tis.com by magellan.TIS.COM id aa08546; 23 Nov 94 13:10 EST Received: from astro.tc.mtu.edu(141.219.5.39) by relay via smap (V1.3) id sma027378; Wed Nov 23 13:11:20 1994 Received: from foghorn.tc.mtu.edu by astro.tc.mtu.edu with SMTP id AA13368 (5.65c/IDA-1.4.4 for ); Wed, 23 Nov 1994 13:10:40 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: onwuka uchendu Message-Id: <199411231810.AA13368@astro.tc.mtu.edu> Subject: Help with SNMP To: snmp@psi.com Date: Wed, 23 Nov 1994 13:07:26 -0500 (EST) Cc: snmpv2@tis.com X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1002 Friends For my MS project, I am building a snmp-controlled Power Monitoring Device. This device is designed to continuosly sample raw ac voltage from the utility company. The analog samples are converted to digital quantities, and processed by a Zenith pc running DOS. The processing is simply a voltage measurement, and comparison against set threshold values. If the samples exceed set voltage thresholds, a trap is sent to the NOC. The NOC is a Sun unix workstation running Sun NetManager. Every sample is also stored in secondary memory to capture the power profile over time. My problem now is to find an appropriate SNMP Agent(Proxy Agent?) to download into my pc to effect snmp communication between the NOC(a unix box) and my DOS pc. Please help. Public domain solutions will be most suitable for me since my student income cannot afford a commercial Agent. I will appreciate any other tips to get me going because I know nothing about SNMP. Thank you. O. Uchendu mtu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00583; 24 Nov 94 5:02 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00579; 24 Nov 94 5:02 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa01735; 24 Nov 94 5:02 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma003891; Thu Nov 24 04:29:34 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa15826; 24 Nov 94 4:18 EST Received: from sol.tis.com by magellan.TIS.COM id aa15822; 24 Nov 94 4:11 EST Message-Id: <9411240913.AA03839@relay.tis.com> Received: from unknown(192.92.126.6) by relay via smap (V1.3) id sma003836; Thu Nov 24 04:13:01 1994 Received: by sodalia.sodalia.it (1.38.193.3/16.2) id AA08106; Thu, 24 Nov 94 10:17:44 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Giovanni Cortese Subject: subscribe To: snmp2@tis.com Date: Thu, 24 Nov 94 10:17:43 MET Mailer: Elm [revision: 70.85] please add me cortese@sodalia.sodalia.it   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02290; 24 Nov 94 13:10 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02286; 24 Nov 94 13:10 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa07538; 24 Nov 94 13:10 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma005763; Thu Nov 24 12:45:08 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa16300; 24 Nov 94 12:36 EST Received: from sol.tis.com by magellan.TIS.COM id aa16294; 24 Nov 94 12:28 EST Received: from ccsg.tau.ac.il(132.66.16.2) by relay via smap (V1.3) id sma005616; Thu Nov 24 12:07:01 1994 Received: by ccsg.tau.ac.il id AA00029 (5.67b/IDA-1.4.4 for snmp2@tis.com); Thu, 24 Nov 1994 19:06:28 +0200 Date: Thu, 24 Nov 1994 19:06:26 +0200 (IST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: galperin meer Subject: help me please To: snmp2@tis.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Maybe somebody knows where i can find educational material about SNMP. Thak in advance. Meir Galperin.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06989; 28 Nov 94 12:32 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06984; 28 Nov 94 12:32 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa10219; 28 Nov 94 12:32 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma025064; Mon Nov 28 12:03:44 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa24626; 28 Nov 94 11:54 EST Received: from sol.tis.com by magellan.TIS.COM id aa24622; 28 Nov 94 11:41 EST Received: from s1.inet.dpw.com(144.211.100.1) by relay via smap (V1.3) id sma024847; Mon Nov 28 11:42:54 1994 Received: by DPW.COM (4.1/DPW-SMTP-RELAY1.6) id AA23408; Mon, 28 Nov 94 11:43:43 EST Received: from s1.f011.dpw.com(144.211.11.1) by s9.serv.dpw.com via smap (V1.3mjr) id sma011643; Mon Nov 28 11:41:27 1994 Received: from w1028.f011.dpw.com by s1.f011.dpw.com (4.1/DPW-SERVER1.3) id AA22261; Mon, 28 Nov 94 11:41:26 EST Date: Mon, 28 Nov 94 11:41:26 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Sholom Fried (Systems Adminstrator" Mmdf-Warning: Parse error in original version of preceding line at magellan.TIS.COM Message-Id: <9411281641.AA22261@s1.f011.dpw.com> To: snmp2@tis.com, meer1@ccsg.tau.ac.il Subject: Re: help me please > Maybe somebody knows where i can find educational material > about SNMP. > Thak in advance. > Meir Galperin. > Meir, Chanukah Sameach! Try one of the following: The Simple Book, by Marshall Rose. (1st Edition) - Covers SNMPv1 The Simple Book, by Marshall Rose. (2nd Edition) - Covers SNMPv2 CMIP, CMOT, and SNMP (I _think_ that's the title), by William Stallings. -- Sholom Fried   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14991; 28 Nov 94 18:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14987; 28 Nov 94 18:41 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa18593; 28 Nov 94 18:41 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smab03112; Mon Nov 28 18:02:23 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa00144; 28 Nov 94 17:53 EST Received: from sol.tis.com by magellan.TIS.COM id aa00140; 28 Nov 94 17:46 EST Received: from thumper.bellcore.com(128.96.41.1) by relay via smap (V1.3) id sma002639; Mon Nov 28 17:47:56 1994 Received: from step (step.polymtl.ca [132.207.7.32]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id RAA24060 for ; Mon, 28 Nov 1994 17:47:12 -0500 Received: by step id AA29035 (5.67a/IDA-1.5 for snmp2@thumper.bellcore.com); Mon, 28 Nov 1994 17:45:34 -0500 Date: Mon, 28 Nov 1994 17:45:34 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Francois Periard Subject: ADD To: snmp2@thumper.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08728; 29 Nov 94 15:04 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08724; 29 Nov 94 15:04 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa13669; 29 Nov 94 15:04 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma010896; Tue Nov 29 14:20:27 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa02991; 29 Nov 94 14:15 EST Received: from sol.tis.com by magellan.TIS.COM id aa02987; 29 Nov 94 14:03 EST Received: from lightning.synoptics.com(134.177.3.18) by relay via smap (V1.3) id sma010729; Tue Nov 29 14:04:44 1994 Received: from SynOptics.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA01117; Tue, 29 Nov 94 11:02:58 PST Received: from immer (immer.synoptics.com) by SynOptics.COM (4.1/SMI-4.1) id AA01598; Tue, 29 Nov 94 11:02:46 PST Received: by immer (4.1/2.0N) id AA26093; Tue, 29 Nov 94 11:00:35 PST Message-Id: <9411291900.AA26093@immer> Date: Tue, 29 Nov 94 11:00:35 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Perkins Mmdf-Warning: Unable to confirm address in preceding line at magellan.TIS.COM To: snmp@psi.com, snmp2@tis.com, waldbusser@cmu.edu Subject: Release of SMICNG!!!! Fellow SNMP and SNMP V2 User's, My name is Greg Foster and I work for Dave Perkins at Bay Networks, Inc. Dave is out of town this week, but wanted to inform everyone that the next generation of SMIC, a compiler for SNMPv1 & SNMPv2 MIBs, is NOW available. The next generation compiler and all the supporting information is available via "anonymous" ftp from ftp.synoptics.com under the directory /tmp/eng/mibcompiler2 Please get the file, "readme.lst", to see the files available for retrieval. Below is a message from Dave describing the package and highlighting some of its key features. Compile On!!! ----------------------------- Dave's Message --------------------------- ANNOUNCEMENT 11/23/94 SMICng I am pleased to announce the availability of the next generation of SMIC - a compiler for SNMPv1 & SNMPv2 MIBs. This tool, to help develop and use SNMPv1 & SNMPv2 MIBs, is a greatly enhanced version of SMIC classic. This compiler is being made "freely available" by Bay Network (SynOptics Communications, Inc.). SMICng Package The first version of this package includes executables for the compiler, MIB stripper, error message displayer, and two programs to build "mib include files". Also included is user a guide, and corrected versions of MIBs from RFCs. At this time only binaries are available. These have been made for SunOSv4.x, HP Unix v9.x, and IBM AIX v3.x. FEATURES * The current version of SMIC, which we call "classic" SMIC has the following features: * multiple input files * concise MIB format (RFC1212) * concise trap format (RFC1215) * multiple MIB modules * items in IMPORTS * textual conventions * alias assignments for modules and object names * selective checking of MIB constructs * extensive MIB syntax checking and continuation of syntax checking after syntax errors * extensive checking of MIB consistency * multiple output options (including MOSY compatible output) * environment variable to locate "included" files * The "next generation" SMIC (SMICng) has all the features of "classic" SMIC plus the following: * Full support for all SNMPv2 MACROs * Support for SIZE and ranges that use the "or" (i.e., the "|") construct. For example: INTEGER (1..10 | 20 | 80..100) and OCTET STRING (SIZE(0..10 | 20 | 30..50)). * Support for MIN & MAX in SIZE/range clauses. For example: INTEGER (0..10 | 20..MAX) or INTEGER (MIN..MAX). * Support for subtyping of TCs. For example: myInt ::= INTEGER(1..20), then myInt (3..12). * Has "automatic imports" for SMI items that needed to be IMPORTed but were not. (And of course, an error is generated.) * Full ASN.1 syntax is allowed for OID values. (Classic SMIC limited OID values to be of form "{ }" or "{ }". Now values like the following are allowed "{ iso org(3) dod(6) internet(1) }" or "{ 1 3 6 }". * Supports referencing items that use the module name prefix. For example, can specify the following: RFC1213-MIB.ifIndex and MYMIB.ifIndex in the same MIB module (for example if needed in an AGENT-CAPABILITIES). * Allows forward references to items in OID values or for types used in SYNTAX clauses. * Added "automatic case-conversion" of leading letter of items. The most common problem seen in MIBs is the wrong case for the sequence name used in table/rows. This is automaticly corrected. Also corrected is the case of TC names. Next generation SMIC doesn't do miracles, so it doesn't fix misspellings or convert the case for letters other than the first. * A new directive, "UNREGISTER", was added to solve the "problem" created by the new IF MIB (RFC 1573) which redefined OBJECT-TYPEs orginally defined in MIB-II. This directive allows items registered with OID values to "give back" their registration so that the OID value can be used for other registrations. * Many new options were added. To Accomodate them, the syntax of the command line was modified. Also, a new environment variable, "SMICOPTS", was added that can be used to specify the "default" settings of the options. A new mechanism was added to allow options to be turned off. To turn off an option on the command line, follow it by the letter "o". * The SNMPv1 and SNMPv2 directives were added so that both v1 and v2 MIBs could be compiled together. Also, if the IMPORTs are done correctly, SMICng "auto selects the version" when parsing the IMPORTs. * As SMICng parses a MIB, line and column positions are saved, so that when a semantic error is reported, it is done at the "exact spot". (In classic SMIC, semantic errors are reported at the line and column that the syntax parser is currently located. For example, most semantic errors in classic SMIC are reported at the location of the END statement of a MIB module.) * SNMPv2 has many new constructs that have new options to control the level of checking for them. * Support was added to allow MIB modules to be tagged with an OID value. Then in another MIB module, the OID value can be used to identify the first MIB module in an IMPORTs instead of using the name. Why might you want this? If you named your MIB modules the same as standard MIB modules, and then you wanted to create an agent-capabilities that has objects from both MIB modules. * For those who would like to pipe in stdin, specifying the filename of "-" as the input filename causes SMICng to read input from stdin. * The MOSY output was updated to be compatable with the new format generated by MOSY v7.1. * Two programs were added to create the "mib include files". * MIB include files are now quite simple since they use the new conditional include directive so that only the directly dependent MIBs need to be specified. * A message display program is now available to take the output from SMICng and display the lines from MIBs marked with the messages. (This is really quite nice.) To use try "smicng -0 | smicewd -". * There are many more features as documented in the new user guide. * Quick start suggestions: * create a directory named smicng. * copy the compressed tar'ed file into smicng * uncompress and extract the tar file (this should create a mibs subdirectory and sunos, hpux, and aix subdirectores) * add the directory for your OS to your path * set up the the SMICINCL environment variable to specify the path to the smicng/mibs subdirectory. (For example, SMICINCL=/home/dperkins/smicng/mibs) * specify "smic -ha" to print all help information. ACKNOWLEDGMENTS The many people that helped getting SMICng complete and tested are listed in the SMICng User's Guide. NOTICE This package is "freely available" but it is not public domain. The following is the copyright and rights to use message for SMICng: Copyright 1992-1994 SynOptics Communications, Inc. All Rights Reserved. SynOptics grants a non-exclusive license to use, copy, modify, and distribute this software for any purpose and without fee, provided that this copyright notice and license appear on all copies and supporting documentation. SynOptics makes no representations about the suitability of this software for any particular purpose. The software is supplied "AS IS", and SynOptics makes no warranty, either express or implied, as to the use, operation, condition, or performance of the software. SynOptics retains all title and ownership in the software. QUESTIONS & HELP Please send me EMAIL if you have questions or need help. dperkins@synoptics.com Enjoy, /dave perkins, SynOptics, 408-764-1516   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24211; 30 Nov 94 2:02 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24207; 30 Nov 94 2:02 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa26349; 30 Nov 94 2:02 EST Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma000912; Wed Nov 30 01:45:07 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa07220; 30 Nov 94 1:42 EST Received: from sol.tis.com by magellan.TIS.COM id aa07211; 30 Nov 94 1:28 EST Received: from thumper.bellcore.com(128.96.41.1) by relay via smap (V1.3) id sma000819; Wed Nov 30 01:19:39 1994 Received: from marsh.cs.curtin.edu.au (marsh.cs.curtin.edu.au [134.7.1.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id BAA29689 for ; Wed, 30 Nov 1994 01:19:16 -0500 Received: from bike.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA23972 (5.67a/IDA-1.5 for ); Wed, 30 Nov 1994 14:19:09 +0800 Received: by bike.cs.curtin.edu.au id AA05590 (5.67a/IDA-1.4.4 for snmp2@thumper.bellcore.com); Wed, 30 Nov 1994 14:19:07 +0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott Pleitner Message-Id: <199411300619.AA05590@bike.cs.curtin.edu.au> To: snmp2@thumper.bellcore.com Date: Wed, 30 Nov 1994 14:19:06 +0800 (WST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 50 subscribe netview-users pleitner@cs.curtin.edu.au