Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04118; 1 Apr 94 15:52 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04114; 1 Apr 94 15:52 EST Received: from relay.tis.com by CNRI.Reston.VA.US id aa14234; 1 Apr 94 15:52 EST Received: by relay.tis.com; id AA13550; Fri, 1 Apr 94 14:36:22 EST Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma013547; Fri Apr 1 14:36:12 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa13751; 1 Apr 94 14:32 EST Received: from sol.tis.com by magellan.TIS.COM id aa13747; 1 Apr 94 14:26 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15494; Fri, 1 Apr 94 14:26:44 EST Received: by relay.tis.com; id AA13479; Fri, 1 Apr 94 14:27:22 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.3mjr) id sma013474; Fri Apr 1 14:27:09 1994 Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA08818; Fri, 1 Apr 94 11:22:37 -0800 Received: from took.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA22327; Fri, 1 Apr 94 14:22:42 -0500 Message-Id: <9404011922.AA22327@us1rmc.bb.dec.com> Received: from took.enet; by us1rmc.enet; Fri, 1 Apr 94 14:22:43 EST Date: Fri, 1 Apr 94 14:22:43 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Halpin LKG1-3/L6 226-5794 01-Apr-1994 1422 To: snmp2@tis.com Cc: halpin@took.enet.dec.com Apparently-To: snmp2@tis.com Subject: add halpin@took.enet.dec.com add halpin@took.enet.dec.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01167; 6 Apr 94 5:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01163; 6 Apr 94 5:12 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa03042; 6 Apr 94 5:12 EDT Received: by relay.tis.com; id AA08452; Wed, 6 Apr 94 04:51:05 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma008446; Wed Apr 6 04:50:28 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa07558; 6 Apr 94 4:32 EDT Received: from sol.tis.com by magellan.TIS.COM id aa07554; 6 Apr 94 4:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28959; Wed, 6 Apr 94 04:07:16 EDT Received: by relay.tis.com; id AA08325; Wed, 6 Apr 94 04:08:00 EDT Received: from unknown(130.89.10.247) by relay via smap (V1.3mjr) id sma008309; Wed Apr 6 04:06:58 1994 Received: from utis083.cs.utwente.nl by utrhcs (4.1/RBCS-2.6mx) id AA15266; Wed, 6 Apr 94 10:06:38 +0200 Received: by utis083.cs.utwente.nl (4.1/RBCS-1.0.1) id AA15386; Wed, 6 Apr 94 10:06:33 +0200 Message-Id: <9404060806.AA15386@utis083.cs.utwente.nl> To: snmpv2@tis.com Subject: announcement: (alpha) release 2 of UT-SNMPv2. Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: snmp@utwente.nl Organisation: Universiteit Twente Address: Postbus 217, 7500 AE Enschede, NL Phone: +31 53 893742 Telefax: +31 53 333815 Date: Wed, 06 Apr 94 10:06:32 +0200 X-Orig-Sender: berkhout@cs.utwente.nl ************* ANNOUNCEMENT **************** ************* ALPHA RELEASE 2 ************** *** UNIVERSITY OF TWENTEs SNMP version 2 *** The SNMP group at the University of Twente (the Netherlands) has completed the second release of their implementation of SNMP version 2. After releasing our initial prototype at the end of last year, we redesigned and extended this prototype to improve our implementation. The new release can be freely obtained from our anonymous ftp server (ftp.cs.utwente.nl), in the directory: pub/src/snmp. This SNMPv2 implementation follows RFC's 1441-1452. It includes things like Encoding Rules, Party MIB, SNMPv2 MIB, MD5, DES and a easy to use API. Note however that this implementation is an alpha release: it is not fully tested and still has some "inefficient" code. This release still lacks the manager-manager MIB, `meta management' (support to manage, from a remote place and using SNMPv2, the SNMPv2 and party MIB). Besides, it does not handle all errors in accordance with the RFCs. Other "flaws" are described in the README file in the root directory of the package. We expect to include the remaining SNMPv2 functionality and remove potential bugs in the next couple of years. Our management software is written in GNU-C and has been tested on SUN Sparc workstations using SunOs 5.3. We have tested against other SNMPv2 software, most notably CMUs SNMPv2 software. We developed for instance things like proxies that copy management requests from and to a SNMPv2 CMU agent. Also available are two additional programs to provide an easy to use manner to generate initial partymib files. The files (*.conf) have the same easy to read format of the cmu-snmp-v2.1 package. Our group maintains a WWW server that provides information about our SNMPv2 project. This information can be reached at: http://snmp.cs.utwente.nl:8001/snmp/html/homepage.html We appreciate that people who are interested in our software send their name and email address to: snmp@cs.utwente.nl. We will use this information for the announcement of new versions and bug-fixes. You can you the same email addres for bugs, questions, complains and complements. The SNMP V2 Group Tele-Informatics and Open Systems Group Department of Computer Science P.O. Box 217, 7500 AE Enschede, The Netherlands Currently the next people are working in the SNMPv2 group: Associates: Aiko Pras Eric van Hengstum Vincent Berkhout Students: Koert Flapper Anton Holleman Jaap Huib van der Knaap Michel van Ooijen Rene Oude Vrielink Peter Peters Rob Post Edward Veluwenkamp *** NOTE **** Due to national custom regulations, you could be violating your laws by exporting or importing DES. We have therefore made a special tar file without DES available to overcome this problem.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15932; 8 Apr 94 19:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15924; 8 Apr 94 19:00 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa19794; 8 Apr 94 19:00 EDT Received: by relay.tis.com; id AA28897; Fri, 8 Apr 94 18:32:48 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma028891; Fri Apr 8 18:32:25 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa03646; 8 Apr 94 18:28 EDT Received: from sol.tis.com by magellan.TIS.COM id aa03642; 8 Apr 94 18:19 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14739; Fri, 8 Apr 94 18:18:57 EDT Received: by relay.tis.com; id AA28818; Fri, 8 Apr 94 18:19:44 EDT Received: from uu10.psi.com(38.8.4.2) by relay via smap (V1.3mjr) id sma028812; Fri Apr 8 18:19:07 1994 Received: from fibermux.UUCP by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; id AA21570 for ; Fri, 8 Apr 94 18:15:04 -0400 Received: from ccrelay.fibermux.com by fibermux.com (4.1/SMI-4.1) id AA07414; Mon, 4 Apr 94 08:53:30 PDT Received: from ccMail by ccrelay.fibermux.com id AA765474671 Mon, 04 Apr 94 08:51:11 PST Date: Mon, 04 Apr 94 08:51:11 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: cmaciocco@ccrelay.fibermux.com Encoding: 206 Text Message-Id: <9403047654.AA765474671@ccrelay.fibermux.com> To: snmpv2@tis.com Subject: SNMPv1-v2 MIB converter Hi, Can someone gives me the address of Marshall's MIBs converter (from V1 to V2). Thank you. Christian M. cmaciocc@ccrelay.fibermux.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02307; 12 Apr 94 8:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02303; 12 Apr 94 8:30 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa04389; 12 Apr 94 8:30 EDT Received: by relay.tis.com; id AA21523; Tue, 12 Apr 94 08:09:34 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma021518; Tue Apr 12 08:09:16 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa19751; 12 Apr 94 8:07 EDT Received: from sol.tis.com by magellan.TIS.COM id aa19747; 12 Apr 94 7:50 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23366; Tue, 12 Apr 94 07:50:35 EDT Received: by relay.tis.com; id AA21418; Tue, 12 Apr 94 07:51:28 EDT Received: from utrhcs.cs.utwente.nl(130.89.10.247) by relay via smap (V1.3mjr) id sma021413; Tue Apr 12 07:50:34 1994 Received: from utis083.cs.utwente.nl by utrhcs (4.1/RBCS-2.6mx) id AA05754; Tue, 12 Apr 94 13:50:05 +0200 Received: by utis083.cs.utwente.nl (4.1/RBCS-1.0.1) id AA18212; Tue, 12 Apr 94 13:50:01 +0200 Message-Id: <9404121150.AA18212@utis083.cs.utwente.nl> To: snmpv2@tis.com Subject: adjustment clock synchronization Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Edward E. Veluwenkamp" Organisation: U. Twente, Dept of CS, Box 217, 7500 AE Enschede, Netherlands Date: Tue, 12 Apr 94 13:50:00 +0200 X-Orig-Sender: veluwenk@cs.utwente.nl We are working on the SNMPv2 project at the University of Twente and we want to implement the clock synchronization algorithm as described in RFC 1446. If the Authentication clocks of the manager and the agent Authentication party are not synchronized then an AuthRequest of the manager can result in an UnAuthRequest at the agent. The manager has no knowledge of the fact that the AuthRequest was refused by the agent or lossed. So the manager retries several times the same AuthRequest, before asking the question if the drift between the two AuthClocks is to great. Now can the manager try to adjust the synchronization of the Authentication clocks following RFC 1446. Our proposal: If the receiving party rejects an AuthRequest as Unauthenticated, why can't this party generate an Authenticated Response PDU with an error-status equal with genErr(5) or an AuthenticationError (does not exist) consisting of the Authentication Clock values of this party (not in accordance with the RFCs). This ensures the sender of the Authenticated Message that the Authentication clocks are not synchronized, so the sending party doesn't have to try several times before coming to the same conclusion. This principle has also the advantage of a minimum of network access with the same result. answers may be addressed to: snmp@cs.utwente.nl Thanks for any comments, Michel and Edward. ___ __/ \__________ | \___/ | Michel van Ooijen | | and Edward Veluwenkamp |___ __ ___ | University of Twente fax. +31 53 333815 | | | / \ (__ | Tele-Informatics & Open Systems tel. +31 53 894287 | | | \__/ ___) | P.O. Box 217 |_________________| 7500 AE Enschede The Netherlands   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03096; 12 Apr 94 9:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03092; 12 Apr 94 9:24 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa06499; 12 Apr 94 9:24 EDT Received: by relay.tis.com; id AA22071; Tue, 12 Apr 94 08:56:01 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma022060; Tue Apr 12 08:55:10 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa21848; 12 Apr 94 8:54 EDT Received: from sol.tis.com by magellan.TIS.COM id aa21844; 12 Apr 94 8:48 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26237; Tue, 12 Apr 94 08:48:06 EDT Received: by relay.tis.com; id AA21981; Tue, 12 Apr 94 08:48:59 EDT Received: from utrhcs.cs.utwente.nl(130.89.10.247) by relay via smap (V1.3mjr) id sma021972; Tue Apr 12 08:48:26 1994 Received: from utis083.cs.utwente.nl by utrhcs (4.1/RBCS-2.6mx) id AA06854; Tue, 12 Apr 94 14:48:01 +0200 Received: by utis083.cs.utwente.nl (4.1/RBCS-1.0.1) id AA29948; Tue, 12 Apr 94 14:47:59 +0200 Message-Id: <9404121247.AA29948@utis083.cs.utwente.nl> To: snmpv2@tis.com Subject: Object Resources Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Edward E. Veluwenkamp" Organisation: U. Twente, Dept of CS, Box 217, 7500 AE Enschede, Netherlands Date: Tue, 12 Apr 94 14:47:57 +0200 X-Orig-Sender: veluwenk@cs.utwente.nl How do you use the Object Resource Group (OR-Group) in the SNMPv2 MIB ? Definition in the RFC 1450: "The (conceptual) table listing the dynamically configurable object resources in a SNMPv2 entity acting in an agent role. SNMPv2 entities which do not support dynamically-configurable object resources will never have any instances of the columnar objects in this table." In the Simple book we read that the definition of sysObjectID assumes that the agent's Object Resources, "the MIB held by an agent" is rather static. Some agents, however, are able to dynamically acquire new Object Resources. In an agent which can't acquire new Object Resources, this table is always empty. In the book of William Stallings the Object Resources Group is used by an SNMPv2 entity in an agent role to describe those Object Resources that it controls that are subject to dynamic configuration by a manager. How do you interpret an Object Resource in the RFC for use with the OR-Group of the SNMPv2 MIB? answers may be addressed to: snmp@cs.utwente.nl Thanks for any comments, Michel and Edward. ___ __/ \__________ | \___/ | Michel van Ooijen | | and Edward Veluwenkamp |___ __ ___ | University of Twente fax. +31 53 333815 | | | / \ (__ | Tele-Informatics & Open Systems tel. +31 53 894287 | | | \__/ ___) | P.O. Box 217 |_________________| 7500 AE Enschede The Netherlands   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25788; 13 Apr 94 0:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25784; 13 Apr 94 0:44 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa27726; 13 Apr 94 0:44 EDT Received: by relay.tis.com; id AA00406; Wed, 13 Apr 94 00:22:54 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma000400; Wed Apr 13 00:22:10 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa25588; 13 Apr 94 0:13 EDT Received: from sol.tis.com by magellan.TIS.COM id aa25584; 13 Apr 94 0:08 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16726; Wed, 13 Apr 94 00:07:56 EDT Received: by relay.tis.com; id AA00328; Wed, 13 Apr 94 00:08:50 EDT Received: from infotech.wipinfo.soft.net(164.164.6.2) by relay via smap (V1.3mjr) id sma000321; Wed Apr 13 00:08:36 1994 Received: by wipinfo.soft.net (4.1/SMI-4.1) id AA00836; Wed, 13 Apr 94 04:09:27 GMT Received: from comm10. by rolex.rnd.blr (4.1/SMI-4.1) id AA01600; Wed, 13 Apr 94 09:39:25+050 Received: by comm10. (4.1/SMI-4.0) id AA01075; Wed, 13 Apr 94 09:51:10 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "S. Ganesh" Message-Id: <9404130451.AA01075@comm10.> Subject: SNMP over X.25 To: snmpv2@tis.com Date: Wed, 13 Apr 1994 09:51:09 +0500 (IST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 278 Can anybody tell me how SNMP can be implemented over x.25.? Is there any literature available on this topic? Please answer back to guts@wipinfo.soft.net. Thank You. S.Ganesh, Wipro Infotech Ltd, Bangalore."   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06564; 13 Apr 94 13:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06560; 13 Apr 94 13:19 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa12190; 13 Apr 94 13:19 EDT Received: by relay.tis.com; id AA05316; Wed, 13 Apr 94 12:58:19 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma005308; Wed Apr 13 12:57:59 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa01049; 13 Apr 94 12:56 EDT Received: from sol.tis.com by magellan.TIS.COM id aa01045; 13 Apr 94 12:46 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13930; Wed, 13 Apr 94 12:46:22 EDT Received: by relay.tis.com; id AA05237; Wed, 13 Apr 94 12:47:16 EDT Received: from relay1.uu.net(192.48.96.5) by relay via smap (V1.3mjr) id sma005232; Wed Apr 13 12:46:41 1994 Received: from uucp4.uu.net by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwllz14115; Wed, 13 Apr 94 12:46:19 -0400 Received: from hcla.UUCP by uucp4.uu.net with UUCP/RMAIL ; Wed, 13 Apr 1994 12:46:19 -0400 Received: by hcla.hcla.com (5.65c/1.34) for snmpv2@tis.com id AA24887; Wed, 13 Apr 1994 09:43:49 +0530 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Deepak Goel Message-Id: <199404130413.AA24887@hcla.hcla.com> Subject: FAQ for SNMPv2? To: snmpv2@tis.com Date: Wed, 13 Apr 94 9:43:48 IST X-Mailer: ELM [version 2.3 PL11] Hi, I am new to this mailing list and was wondering if there is any compilation of FAQs for SNMPv2. If there is one, could someone please mail me a copy of it. Thanks, -Deepak Goel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10486; 15 Apr 94 15:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10481; 15 Apr 94 15:58 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa17727; 15 Apr 94 15:58 EDT Received: by relay.tis.com; id AA28625; Fri, 15 Apr 94 15:30:55 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma028598; Fri Apr 15 15:29:53 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa28687; 15 Apr 94 15:20 EDT Received: from sol.tis.com by magellan.TIS.COM id aa28092; 15 Apr 94 15:05 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00854; Fri, 15 Apr 94 15:04:43 EDT Received: by relay.tis.com; id AA28364; Fri, 15 Apr 94 15:05:41 EDT Received: from twok.ods.com(192.94.73.2) by relay via smap (V1.3mjr) id sma028353; Fri Apr 15 15:05:37 1994 Received: by istwok.ods.com id AA17109 (5.65c/IDA-1.3.5); Fri, 15 Apr 1994 14:05:42 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Klamm Message-Id: <199404151905.AA17109@istwok.ods.com> Subject: partyAuthProtocol creation To: snmpv2@tis.com Date: Fri, 15 Apr 1994 14:05:33 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2118 Hi, I have a MIB interpretation question for the v2 security WG (and the editor thereof). Reproduced below is the partyAuthProtocol ASN.1 (RFC1447): partyAuthProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The authentication protocol by which all messages generated by the party are authenticated as to origin and integrity. The value noAuth signifies that messages generated by the party are not authenticated. Once an instance of this object is created, its ^^^^^^^ value can not be changed." DEFVAL { v2md5AuthProtocol } ::= { partyEntry 7 } My question concerns the last sentence of the DESCRIPTION. Specifically, what is meant by the word "created?" Suppose a NMS creates a row by sending a single set-PDU with a single varbind of partyStatus = createAndWait. Since a reasonable agent processing this set request might choose to set all objects in the same row with their DEFVALs the partyAuthProtocol object would now have the value of v2md5AuthProtocol. In the strictest interpretation of the word "create" the partyAuthProtocol object has been created albeit with a DEFVAL. The agent now might reasonably reject any subsequent sets to the partyAuthProtocol instance since it already exists. Is the scenario I describe the intended interpretation of partyAuthProtocol? My concern is that interoperability could suffer with this interpretation. A NMS is forced into setting the partyAuthProtocol in the first PDU used to create a new instance in the partyTable. I propose that the following sentence be added to the last sentence: "The object is deemed created when either of the following occur- 1) the object is set via a SNMP set-request PDU, or 2) the associated partyStatus object transitions to active." Comments? Keith Klamm   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13052; 17 Apr 94 6:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13048; 17 Apr 94 6:04 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa21281; 17 Apr 94 6:04 EDT Received: by relay.tis.com; id AA09843; Sun, 17 Apr 94 05:44:52 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma009835; Sun Apr 17 05:44:22 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa09691; 17 Apr 94 5:36 EDT Received: from sol.tis.com by magellan.TIS.COM id aa09687; 17 Apr 94 5:30 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21042; Sun, 17 Apr 94 05:29:48 EDT Received: by relay.tis.com; id AA09787; Sun, 17 Apr 94 05:30:48 EDT Received: from vxdsyc.desy.de(131.169.35.66) by relay via smap (V1.3mjr) id sma009782; Sun Apr 17 05:30:34 1994 Return-Receipt-To: Beznosov@inp.nsk.su Received: from ns.itep.msk.su by vxdesy.desy.de (PMDF V4.2-14 #4122) id <01HBA3CMH1PC8WWSYQ@vxdesy.desy.de>; Sun, 17 Apr 1994 11:29:25 +0100 Received: from inpbox.inp.nsk.su ([193.124.167.251]) by ns.itep.msk.su with SMTP id AA21265 (5.67a8/IDA-1.5 for ); Sun, 17 Apr 1994 13:29:46 +0300 Received: from CSD.inp.nsk.su by inpbox.inp.nsk.su with SMTP id AA10475 (5.65c8/IDA-1.4.4 for ); Sun, 17 Apr 1994 16:28:43 +0700 Received: from CSD/MERCURY by csd.inp.nsk.su (Mercury 1.0); Sun, 17 Apr 94 16:34:13 GMT+6 Date: 17 Apr 94 16:33:50 GMT+0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Konstantin Beznosov Subject: LAN bridge with SNMP To: snmpv2@tis.com Reply-To: Beznosov@inp.nsk.su Message-Id: <152688828C2@csd.inp.nsk.su> Organization: Institute of Nuclear Physics Mime-Version: 1.0 X-Mailer: Pegasus Mail v2.3 (R4). Content-Type: TEXT/PLAIN Content-Transfer-Encoding: QUOTED-PRINTABLE Priority: normal X-Pmrqc: 1 Do anybody know the implementation of multiport (i.e. multi-interface= ) bridge with SNMP built in ( ex=D3epting KarleBridge) =C1=DD=CB IBM-PC clone ? Please answer to Beznosov@INP.Nsk.SU. Thanks in advance. ---------------------------------------------------------------------= --- Konstantin Beznosov | | Assistant System & Network Manager | voice: 7 3832 359-503 Computer Scince Department | Internet: Beznosov@INP.NSK.SU | The Institute of Nuclear Physics | Novosibirsk, Russia |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04299; 19 Apr 94 11:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04295; 19 Apr 94 11:32 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa07890; 19 Apr 94 11:32 EDT Received: by relay.tis.com; id AA27844; Tue, 19 Apr 94 10:39:41 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma027830; Tue Apr 19 10:39:00 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa21215; 19 Apr 94 10:37 EDT Received: from sol.tis.com by magellan.TIS.COM id aa21211; 19 Apr 94 10:28 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04628; Tue, 19 Apr 94 10:28:29 EDT Received: by relay.tis.com; id AA27707; Tue, 19 Apr 94 10:29:32 EDT Received: from twok.ods.com(192.94.73.2) by relay via smap (V1.3mjr) id sma027696; Tue Apr 19 10:28:41 1994 Received: by istwok.ods.com id AA15798 (5.65c/IDA-1.3.5); Tue, 19 Apr 1994 09:29:13 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Klamm Message-Id: <199404191429.AA15798@istwok.ods.com> Subject: Re: partyAuthProtocol creation To: snmpv2@tis.com Date: Tue, 19 Apr 1994 09:29:11 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2020 Hi, I have an update on my earlier question for those of you who are still interested. In summary my question is: What is the meaning of the following sentence from the partyAuthProtocol DESCRIPTION: "Once an instance of this object is created, its value can not be changed."? Chris Young suggested that the agent be designed to not invoke the DEFVALs until partyStatus is set to active. In theory this idea would imply that a set-request to the partyAuthProtocol object would be accepted anytime up to (and including) the PDU that sets partyStatus = active. Sath. Nelakonda pointed out that setting the partyCloneFrom object (which must occur exactly once) copies the partyAuthProtocol field from the cloned party. This means that the partyAuthProtocol object is created (if it doesn't already exist) when the partyCloneFrom object is set. The net effect is that the partyAuthProtocol object would have to be set prior to the partyCloneFrom object. A PDU containing sets to both objects may have an implementation specific result (in this case I would suggest that the set to the partyAuthProtocol object take precedence). Sath. also recognized that the above discussion applies to the partyPrivProtocol object as well. Thanks to all who responded to my query. In summary: The most interoperable way to create a party (with partyAuthProtocol different from cloned party) is to set partyAuthProtocol in the first PDU. Updated proposal to enhance interoperability: Add the following sentence to the end of the DESCRIPTION fields for partyAuthProtocol and partyPrivProtocol: "This object is deemed created upon successfully processing a set-request containing either this object or the associated partyCloneFrom object. Note that if both objects are contained in the same set-request that the party[Auth|Priv]Protocol set will take precedence." Maybe this is all a non-issue. Would anybody ever try to clone a md5Auth party to create a noAuth party (for instance)? Regards, Keith Klamm   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10880; 20 Apr 94 14:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10876; 20 Apr 94 14:26 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa16733; 20 Apr 94 14:26 EDT Received: by relay.tis.com; id AA10555; Wed, 20 Apr 94 13:55:52 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id sma010545; Wed Apr 20 13:55:13 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa29918; 20 Apr 94 13:51 EDT Received: from sol.tis.com by magellan.TIS.COM id aa29914; 20 Apr 94 13:43 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16198; Wed, 20 Apr 94 13:42:39 EDT Received: by relay.tis.com; id AA10453; Wed, 20 Apr 94 13:43:45 EDT Received: from sctc.com(192.55.214.1) by relay via smap (V1.3mjr) id sma010448; Wed Apr 20 13:43:14 1994 Received: from sccmailhost.sctc.com (elvis.sctc.com) by SCTC.COM (4.1/SCTC-010592) id AA08801; Wed, 20 Apr 94 12:42:57 CDT Received: from sccmailhost.sctc.com by sccmailhost.sctc.com id 180560000; 20 Apr 94 11:42 CST Received: from phantasm by sccmailhost.sctc.com id 171100000; 20 Apr 94 11:42 CST Received: from dreez.sctc.com by phantasm.sctc.com (4.1/SMI-4.2) id AA22471; Wed, 20 Apr 94 12:41:01 CDT Received: by dreez.sctc.com (5.0/SMI-4.2) id AA02912; Wed, 20 Apr 1994 12:41:02 +0600 Message-Id: <9404201741.AA02912@dreez.sctc.com> To: snmpv2@tis.com, nms@netmgrs.co.uk Reply-To: endrizzi@sctc.com Subject: Security and SNMPv2 X-Mailer: exmh version 1.3delta 3/31/94 Date: Wed, 20 Apr 1994 12:41:01 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Michael Endrizzi Content-Length: 351 I am interested in the following information: 1) Real world Key Distribution implementations for SNMPv2. 2) How agents and managers synch their initial keys in real products. 3) If SNMPv2 security is really being used, or do administrators find security to be a hassle and turn it off. thanks, dreez endrizzi@sctc.com