Received: from ietf.org by ietf.org id aa13772; 1 Aug 97 10:09 EDT Received: from ietf.ietf.org by ietf.org id aa13329; 1 Aug 97 10:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: snmpv3@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-snmpv3-usm-01.txt Date: Fri, 01 Aug 1997 10:07:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011007.aa13329@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) Author(s) : Bert Wijnen and U. Blumenthal Filename : draft-ietf-snmpv3-usm-01.txt Pages : 72 Date : 31-Jul-97 This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [SNMP-ARCH]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-snmpv3-usm-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-usm-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-snmpv3-usm-01.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970505173055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-usm-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-snmpv3-usm-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970505173055.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13796; 1 Aug 97 10:09 EDT Received: from ietf.ietf.org by ietf.org id aa13407; 1 Aug 97 10:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: snmpv3@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-snmpv3-acm-02.txt Date: Fri, 01 Aug 1997 10:07:45 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011007.aa13407@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : View-based Access Control Model for the Simple Network Management Protocol (SNMP) Author(s) : Keith McCloghrie and Bert Wijnen and Randy Presuhn Filename : draft-ietf-snmpv3-acm-02.txt Pages : 38 Date : 31-Jul-97 This document describes the View-based Access Control Model for use in the SNMP architecture [SNMP-ARCH]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-snmpv3-acm-02.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-acm-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-snmpv3-acm-02.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970505173055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-acm-02.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-snmpv3-acm-02.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970505173055.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa20007; 1 Aug 97 11:14 EDT Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA03004 for ; Fri, 1 Aug 1997 11:13:09 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id LAA25837; Fri, 1 Aug 1997 11:04:04 -0400 (EDT) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id LAA13647 for disman-out; Fri, 1 Aug 1997 11:00:14 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA13615 for ; Fri, 1 Aug 1997 11:00:07 -0400 (EDT) Received: from mail.htconn.com (mail.htconn.com [38.245.21.2]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id LAA07492 for ; Fri, 1 Aug 1997 11:00:26 -0400 (EDT) Received: from tmax by mail.htconn.com (SMI-8.6/SMI-SVR4) id KAA23030; Fri, 1 Aug 1997 10:56:08 -0400 From: "T. Max Devlin" To: Juergen Schoenwaelder Cc: disman@nexen.com, snmpv3@tis.com, netlabs-l@pitt.edu Subject: Re: SNMP targets - a new proposal. Date: Fri, 01 Aug 1997 14:58:11 GMT Organization: Hi-TECH Connections Message-ID: <33e2ed24.2311222@mail.htconn.com> References: <199707302136.XAA22260@spog.gaertner.de> In-Reply-To: <199707302136.XAA22260@spog.gaertner.de> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com On Wed, 30 Jul 1997 23:36:27 +0200, you wrote: >The current proposal in the SNMPv3 Applications MIB to define targets >uses the following approach: >=20 >A table called snmpTargetTable lists groups of targets. A target is a >set of transport addresses, as defined in the snmpTargetAddrTable. >There is a static binding of targets to target groups because the >group membership is determined as part of the index into the >snmpTargetAddrTable. >=20 >There were discussions in the DISMAN WG that a more flexible system is >needed for a DISMAN manager. The idea was to use a late binding >mechanism, where you can add a single new target and it will >automatically become a member of the appropriate target group(s). >=20 >Various approaches have been proposed. For example, Bob Stewart's >proposal which used expressions to define a target groups. Steve >Waldbusser proposed a mechanism which used pattern matching against >some MIB variables to determine group membership. Bob's proposal has >the problem that it requires to have an expression evaluator available >in order to use it. Steve's approach has the problem that MIB values >have to by mapped into strings in order to make pattern matching work, >which does not work well in all cases. >=20 >I would like to make a new proposal, which is hopefully simple enough >so that it is a) acceptable for the SNMPv3 MIB and which is b) >hopefully powerful enough to satisfy the DISMAN requirements of late >binding. The proposed solution is based on the concept of tagging >targets with a set of tags. A target group is also defined by a list >of tags. A target is a member of a target group if the list of tags >for the group is included in the list of tags for the target. >=20 >Tags can for example be stored in a DisplayString object. A tag is a >sequence of non-white-space characters. White space characters >separate tags. Membership can either be determined whenever a new >target comes into existence and if a new group is defined, or >membership is calculated whenever a target group is actually used. >This is an implementation choice with trades-off memory usage and CPU >usage. >=20 >An example: Lets assume we have the following targets: >=20 > TAddr Tags > 1.2.3.4 "router acme" > 1.2.3.5 "switch acme" > 1.2.3.6 "router linux host" > 1.2.3.7 "linux host" >=20 >The groups might be defines as: >=20 > Name Tags > "router" "router" > "acme router" "router acme" > "hosts" "host" >=20 >The key point here is that you only have to add a new entry into the >target table and it will automatically become a member of the "right" >group(s). Also note that every target is only listed once. The current >scheme used by the SNMPv3 MIB would require for this example several >group(s). Also note that every target is only listed once. The current >scheme used by the SNMPv3 MIB would require for this example several >duplicated entries, which wastes memory and makes the whole >configuration much more complex. > >The downside of this approach is that the tags have to be configured, >either by a human or by a clever discover algorithm. However, I think >that the configuration overhead is not worse than in the proposed >solution and it allows a lot of flexibility at very low costs. > =20 >Comments? > Juergen What you are describing seems very similar to a function used in the=20 Seagate NerveCenter software to identify management targets, = capabilities, and administrative groupings known as the property groups system. Each node is assigned to one property group identifying an exclusive set; each node is assigned a single group, but one group can be assigned to = multiple nodes. By default, this is assigned automatically by capabilities (sysObjectId),= or it can be assigned manually. More complex algorithmic assignment, by subnet, for example, = could be possible. =20 Each property group consists of one or more=20 properties. Each property (which is used in the NerveCenter software as = a=20 control key for specific polls and alarms) identifies one capability = (lsystem, or, more generally cisco) or one administrative "tag" (Houston or London, or LAN = or WAN, or local, or Unix or client or big or small or fast or slow or red or blue....). By using a property, you create non-exclusive set of nodes which have = that property appearing in their property group list. This seems the same, to me, as = your description: >A target is a member of a target group if the list of tags >for the group is included in the list of tags for the target All this seems strangely ironic to me, as there is a debate running on = the NerveCenter mailing list concerning the property groups system. The fact that your = system assigns one "property group" (list of tags) to each node, and multiple properties= (tags) to each=20 "target group" ('acme router' being the example, both 'acme' and 'router'= are independent tags)=20 makes your method the same as NerveCenter's would be if it were possible = to key a poll or alarm off of multiple properties (tags). The ironic part is = that the debate on the list centers around the feasibility of the opposite: applying multiple = property groups to a single node. Given that you are not identifying specific management processes = or procedures, (each of which, I assume, could key off one tag, or a boolean expression of = multiple tags), it seems that the two systems are essentially identical. The added mechanism in NerveCenter is an additional level of abstraction = which allows a=20 specific list of tags to be applied to multiple nodes. This is the = "property group" construct, which in your system would simply be the existence of two nodes which = happen to have the exact same tag list. They would be "managed" essentially the same. = Implementation of this additional concept could be an implementation issue. =20 I concur completely with your method. I believe it is the only = practical, feasible way to ensure that both the value and flexibility required of a target system is = provided. I believe (except for some technical limitations of NerveCenter which have been part of the = debate) that this has proven to be a valuable and powerful method for identifying groupings of = managed elements for targeting. Trying to identify multiple groups with multiple items within each group = which are common to=20 multiple groups doesn't seem like it could ever be easier than simply = identifying each target by TA. But using your approach, which essentially makes each TA an = exclusive subset, allows the tags to identify non-exclusive lists of targets. One question would be: how would you handle multiple TAs for the same = node. Would this be restricted, so that each node can only have one TA listed in the target = list? Interestingly, Seagate is also working on this particular thing, but I'm not sure how to explain= their approach.... -- T. Max Devlin Hi-TECH Connections ***************************************************** - Opinions expressed are my own. Anyone else,=20 including my employer, may use them only in accordance with licensing agreements. -=20   Received: from cnri by ietf.org id aa00938; 1 Aug 97 13:41 EDT Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA03691 for ; Fri, 1 Aug 1997 13:39:31 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id NAA26863; Fri, 1 Aug 1997 13:31:44 -0400 (EDT) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id NAA16619 for disman-out; Fri, 1 Aug 1997 13:27:30 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id NAA16610 for ; Fri, 1 Aug 1997 13:27:26 -0400 (EDT) Received: from mail.htconn.com (mail.htconn.com [38.245.21.2]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id NAA10420 for ; Fri, 1 Aug 1997 13:27:45 -0400 (EDT) Received: from tmax by mail.htconn.com (SMI-8.6/SMI-SVR4) id NAA23521; Fri, 1 Aug 1997 13:24:20 -0400 From: "T. Max Devlin" To: disman@nexen.com, netlabs-l@pitt.edu, snmpv3@tis.com Subject: apologies Date: Fri, 01 Aug 1997 17:26:23 GMT Organization: Hi-TECH Connections Message-ID: <33e71a33.13792759@mail.htconn.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com I'm sorry about the line width of my previous message to these lists. A new mail client, a changed default. I wouldn't usually mention it, but I did cross-post it to three lists. ;-) My apologies, especially to Juergen. Now comes the hard part. Picking which of three newsgroups to discuss ideas on target grouping.... -- T. Max Devlin Hi-TECH Connections ***************************************************** - Opinions expressed are my own. Anyone else, including my employer, may use them only in accordance with licensing agreements. -   Received: from ietf.org by ietf.org id aa09034; 2 Aug 97 11:53 EDT Received: from ietf.ietf.org by ietf.org id aa08043; 2 Aug 97 11:38 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: snmpv3@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-appl-01.txt Date: Sat, 02 Aug 1997 11:38:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021138.aa08043@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : SNMPv3 Applications Author(s) : B. Stewart, D. Levi, P. Meyer Filename : draft-ietf-snmpv3-appl-01.txt Pages : 68 Date : 01-Aug-97 This memo describes the various types of SNMP applications which make use of an SNMP engine as described in [SNMP-ARCH]. There are five types of application described herein: - Applications which initiate SNMP Get, GetNext, GetBulk, and/or Set requests, called 'command generators'. - Applications which respond to SNMP Get, GetNext, GetBulk, and/or Set requests, called 'command responders'. - Applications which generate notifications, called 'notification originators'. - Applications which forward SNMP Get, GetNext, GetBulk, and/or Set requests or notifications, called 'proxy forwarders'. This memo also defines MIBs for specifying targets of management operations, for notification filtering, and for proxy forwarding. - Applications which receive notifications, called 'notification receivers'. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpv3-appl-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-appl-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-snmpv3-appl-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801150823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-appl-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-appl-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801150823.I-D@ietf.org> --OtherAccess-- --NextPart--