From daemon Thu Oct 30 09:52:28 1997 Delivery-Date: Thu, 30 Oct 1997 10:04:12 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA11107 for ietf-123-outbound.10@ietf.org; Thu, 30 Oct 1997 09:51:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA11087; Thu, 30 Oct 1997 09:50:59 -0500 (EST) Message-Id: <199710301450.JAA11087@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-usm-03.txt Date: Thu, 30 Oct 1997 09:50:58 -0500 Sender: cclark@cnri.reston.va.us --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) : B. Wijnen, U. Blumenthal Filename : draft-ietf-snmpv3-usm-03.txt Pages : 82 Date : 29-Oct-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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-usm-03.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-03.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: <19971029142522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-usm-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-usm-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971029142522.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Thu Oct 30 09:53:28 1997 Delivery-Date: Thu, 30 Oct 1997 10:04:32 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA11164 for ietf-123-outbound.10@ietf.org; Thu, 30 Oct 1997 09:52:05 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA11145; Thu, 30 Oct 1997 09:52:01 -0500 (EST) Message-Id: <199710301452.JAA11145@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-acm-04.txt Date: Thu, 30 Oct 1997 09:52:01 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New 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 (VACM) for the Simple Network Management Protocol (SNMP) Author(s) : K. McCloghrie, B. Wijnen, R. Presuhn Filename : draft-ietf-snmpv3-acm-04.txt Pages : 42 Date : 29-Oct-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 with 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-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-acm-04.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-04.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: <19971029142259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-acm-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-acm-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971029142259.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Thu Oct 30 09:56:52 1997 Delivery-Date: Thu, 30 Oct 1997 10:10:27 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA11285 for ietf-123-outbound.10@ietf.org; Thu, 30 Oct 1997 09:55:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA11266; Thu, 30 Oct 1997 09:55:26 -0500 (EST) Message-Id: <199710301455.JAA11266@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-next-gen-arch-06.txt Date: Thu, 30 Oct 1997 09:55:25 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New 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 : An Architecture for Describing SNMP Management Frameworks Author(s) : B. Wijnen, R. Presuhn, D. Harrington Filename : draft-ietf-snmpv3-next-gen-arch-06.txt Pages : 59 Date : 29-Oct-97 This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpv3-next-gen-arch-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-next-gen-arch-06.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-next-gen-arch-06.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: <19971029120436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-next-gen-arch-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-next-gen-arch-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971029120436.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Oct 31 10:11:06 1997 Delivery-Date: Fri, 31 Oct 1997 10:19:14 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id KAA03625 for ietf-123-outbound.10@ietf.org; Fri, 31 Oct 1997 10:09:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA03606; Fri, 31 Oct 1997 10:09:37 -0500 (EST) Message-Id: <199710311509.KAA03606@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-appl-04.txt Date: Fri, 31 Oct 1997 10:09:36 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New 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-04.txt Pages : 78 Date : 30-Oct-97 This memo describes five types of SNMP applications which make use of an SNMP engine as described in [SNMP-ARCH]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. Internet-Drafts are available by anonymous FTP. Login with 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-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-appl-04.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-04.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: <19971030115123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-appl-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-appl-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971030115123.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Oct 31 10:32:46 1997 Delivery-Date: Fri, 31 Oct 1997 10:45:29 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id KAA04305 for ietf-123-outbound.10@ietf.org; Fri, 31 Oct 1997 10:31:12 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA04286; Fri, 31 Oct 1997 10:31:08 -0500 (EST) Message-Id: <199710311531.KAA04286@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-v3mpc-model-06.txt Date: Fri, 31 Oct 1997 10:31:07 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New 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 : Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) Author(s) : J. Case, B. Wijnen, R. Presuhn, D. Harrington Filename : draft-ietf-snmpv3-v3mpc-model-06.txt Pages : 42 Date : 30-Oct-97 This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [SNMP-ARCH]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpv3-v3mpc-model-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-v3mpc-model-06.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-v3mpc-model-06.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: <19971030105219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-v3mpc-model-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-v3mpc-model-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971030105219.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Mon Nov 3 13:39:09 1997 Delivery-Date: Mon, 03 Nov 1997 13:48:01 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id NAA18365 for ietf-123-outbound.10@ietf.org; Mon, 3 Nov 1997 13:38:56 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA18352; Mon, 3 Nov 1997 13:38:54 -0500 (EST) Message-Id: <199711031838.NAA18352@ietf.org> To: IETF-Announce: ; Cc: snmpv3@tis.com From: The IESG SUBJECT: Last Call: An Architecture for Describing SNMP Management Frameworks to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 03 Nov 1997 13:38:54 -0500 Sender: scoya@cnri.reston.va.us The IESG has received a request from the SNMP Version 3 Working Group to consider publication of the following as Proposed Standards: An Architecture for Describing SNMP Management Frameworks Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) SNMPv3 Applications User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 17, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-next-gen-arch-06.txt ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-v3mpc-model-06.txt ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-appl-04.txt ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-usm-03.txt ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-acm-04.txt From ~ned+madman-errors@sigurd.innosoft.com Wed Nov 5 15:45:00 1997 Delivery-Date: Wed, 05 Nov 1997 15:45:00 -0500 Return-Path: ~ned+madman-errors@sigurd.innosoft.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA02099 for ; Wed, 5 Nov 1997 15:44:59 -0500 (EST) Received: from sigurd.innosoft.com (SIGURD.INNOSOFT.COM [192.160.253.70]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA12283 for ; Wed, 5 Nov 1997 15:47:51 -0500 (EST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by sigurd.innosoft.com (PMDF V5.2-0 #15002) id <01IPNFW2DLCW90OK62@sigurd.innosoft.com> (original mail from gbjones@mitre.org) for IETF-ARCHIVE@CNRI.RESTON.VA.US; Wed, 5 Nov 1997 12:36:11 PST Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by sigurd.innosoft.com (PMDF V5.2-0 #15002) with ESMTP id <01IPNFVV0LFA90Q9GG@sigurd.innosoft.com>; Wed, 05 Nov 1997 12:34:42 -0800 (PST) Received: from mbunix.mitre.org ("port 3850"@mbunix.mitre.org) by INNOSOFT.COM (PMDF V5.1-10 #8694) with ESMTP id <01IPNFP5ZBEM9JF8FG@INNOSOFT.COM>; Wed, 05 Nov 1997 12:33:43 -0800 (PST) Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by mbunix.mitre.org (8.8.6/8.8.6/mitre.0) with SMTP id PAA02480; Wed, 05 Nov 1997 15:28:39 -0500 (EST) Received: from m23392-pc.mitre.org (128.29.105.169) by fuzzy.mitre.org with SMTP id 35106; Wed, 05 Nov 1997 15:28:38 -0500 (EST) Date: Wed, 05 Nov 1997 14:27:33 -0500 From: gbjones@mitre.org (Gordon B. Jones) Subject: Message Tracking MIB and BOF To: applmib@emi-summit.com, drums@cs.utk.edu, madman@INNOSOFT.COM, snmpv3@tis.com, snmp@psi.com Cc: gbjones@mitre.org Message-id: <3460C8A5.86F3CDCC@mitre.org> Organization: The MITRE Corp. MIME-version: 1.0 X-Mailer: Mozilla 4.01 [en] (Win95; I) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit X-Priority: 3 (Normal) Greetings, Three companies have implemented SNMP MIBs for message tracking, an e-mail management function. An internet-draft for the work exists and a BOF meeting is planned for the December IETF. If this interests you, continue to read this message. The mailing list is called msgmib-list@mitre.org. To subscribe, send a message to listserv@mitre.org. In the body of the message put: subscribe msgmib-list your name, where "your name" is obviously your name, .e.g. "harald t alvestrand" The draft is called draft-ietf-madman-trackmib-00.txt. It was origjnally released under MADMAN for lack of a better place to put it; the MIB is messaging-specific and in a way extends the work done by that group. The acronym msgmib will be used on any agenda mentioning the BOF, if such an agenda appears. If you want more technical information, here is a brief synopsis: Much work has been done in standards communities to define standards for managing messaging using the Internet Simple Network Management Protocol (SNMP) and Management Information Bases (MIBs). Until this time, however, these standards have focused upon aggregates of messages processed by the messaging entity (e.g., the total number of messages received over a specific time interval), but have not addressed individual messages, their characteristics, or the path they have taken through the messaging network. Several companies have now implemented SNMP MIBs in accordance with an Internet draft standard for message tracking. SNMP is a mature network and application management technology that provides an abundance of user tools, and a cross-vendor, cross-technology ubiquity. SNMP provides a migration path to a secure solution, and to web-based user interfaces. SNMP is the only approved Internet standard for application management. Use of this will allow development of message tracking applications that can operate in a multi-vendor messaging environment: the approach is a standard approach open to any messaging vendor. The phenomenon we call message tracking has multiple uses: · When there is a lack of trust in the messaging system, such as when an originator claims a message failed to be delivered, the point of failure may be isolated. This includes messages that were never delivered or messages that were delivered incorrectly. Message tracking thus adds to the overall reliability of the mail system; · Per-message information obtained from message tracking can be used for accounting and billing purposes, to itemize traffic on a per-origin or per-destination basis by system or originator. This typically involves two steps: collection of message traffic data, followed by the generation of appropriate reports or billing. A MIB approach aids report generation in that COTS managers can place the MIB information directly in a COTS database; · Message tracking information provides security in that the origins of potential security threats can be more precisely determined. If a system were flooded with traffic, for instance, the origin of this traffic would become known. Message tracking information is suitable for routine security audits containing the details of messaging traffic over specific time intervals; · The message tracking MIB would aid in message loop detection, since unique message identifiers of looping messages, when these exist, would be recorded multiple times; · Performance characteristics about the type of messaging traffic could be determined, such as the multiple number of outbound messages that resulted from a single inbound message, and the percentage of message traffic that consists of delivery reports or receipts; · Standardized message tracking information acts as a bridge between dissimilar messaging products and dissimilar messaging communities. This message tracking approach provides flexible functionality in certain key areas, particularly when compared with "hard-wired" message tracking approaches where custom code is written to perform a limited number of sequential operations: · The approach is a standard approach open to any messaging vendor; · The approach does not require the user to have prior knowledge of attributes such as the message ID or originating system in order to track a message; · The approach allows a user to search "forward" through the chain of MTAs in the delivery path for a message starting with the first MTA, as well as "backwards" starting with the final MTA in the delivery path; · The approach allows both a sequential search through a path of MTAs or a concurrent "pull" of information from multiple MTAs simultaneously. In the second case the processing is completely distributed and the determination of the delivery path can be performed after the fact in one central location without tying up resources at the MTAs; in the first case it can be performed sequentially upon demand; · The approach treats both completed transactions and incomplete transactions in the same way; · Multiple, concurrent searches can be issued simultanoeusly; · Data can be automatically extracted by a management application between specified time intervals; · Management platforms often provide "off-the-shelf" integration between SNMP and commercial database technologies The internet-draft has the rest... From qqi@world.std.com Fri Nov 7 08:45:04 1997 Delivery-Date: Fri, 07 Nov 1997 08:45:09 -0500 Return-Path: qqi@world.std.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA04958 for ; Fri, 7 Nov 1997 08:45:04 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA18648 for ; Fri, 7 Nov 1997 08:47:58 -0500 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA04955 for ; Fri, 7 Nov 1997 08:44:57 -0500 (EST) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id IAA19543; Fri, 7 Nov 1997 08:44:53 -0500 (EST) Received: by world.std.com (5.65c/Spike-2.0) id AA15948; Fri, 7 Nov 1997 08:44:53 -0500 From: qqi@world.std.com (Quality Quorum) Message-Id: <199711071344.AA15948@world.std.com> Subject: Re: SNMPv3, last call To: Eric.Smith@barclays.co.uk (Eric Smith) Date: Fri, 7 Nov 1997 08:44:53 -0500 (EST) Cc: snmpv3@tis.com, iesg@ietf.org In-Reply-To: <9711070934.AA43230@hermes.rhl.barclays.co.uk> from "Eric Smith" at Nov 7, 97 09:34:50 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > > > > I did not see any other opinions posted by anybody beyond AD and WG chair > > and people who did work on these drafts directly, despite direct > > call to do it. So, one conclude that proposed drafts are not > > interesting to public beyond narrow circle of its authors. > > > > I don't believe Aleksey's comment is true. I'm sure there others > who, like myself, monitor the activities of the SNMP WGs through > the mail lists or news groups but do not feel in a position to > challenge the expert view. As a system developer involved in the > implementation of systems that use SNMP I have a great interest in > the direction of proposed standards but do not have the wealth of > experience held by most of the WG members, nor do I have the time ^^^^^^^^^^^^^^^^^^ > to review very draft in detail, thus I am reluctant to comment. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is exactly my point: apparently drafts do not generate enough interest for anybody to review them. > > I would like to congratulate the WG on its enthusiastic start and > express my hope that progress is not impeded by issues that non WG > members might consider minor, resulting in the same fate as SNMPv2. > > Eric G Smith > > > ------------------------------------------------------------------------------- > Email Phone > ----- ----- > Office: Eric.Smith@barclays.co.uk 44 (0)1565 612526 > > Internet communications are not secure and therefore the Barclays Group does > not accept legal responsibility for the contents of this message. > > Thanks, Aleksey From mo@UU.NET Fri Nov 7 08:53:00 1997 Delivery-Date: Fri, 07 Nov 1997 08:53:00 -0500 Return-Path: mo@UU.NET Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA05210 for ; Fri, 7 Nov 1997 08:53:00 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA18681 for ; Fri, 7 Nov 1997 08:55:59 -0500 (EST) Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA05207 for ; Fri, 7 Nov 1997 08:52:58 -0500 (EST) Received: from rodan.UU.NET by relay2.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdoqh04902; Fri, 7 Nov 1997 08:53:05 -0500 (EST) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQdoqh20044; Fri, 7 Nov 1997 08:52:58 -0500 (EST) Message-Id: To: qqi@world.std.com (Quality Quorum) cc: Eric.Smith@barclays.co.uk (Eric Smith), snmpv3@tis.com, iesg@ietf.org Subject: Re: SNMPv3, last call In-reply-to: Your message of "Fri, 07 Nov 1997 08:44:53 EST." <199711071344.AA15948@world.std.com> Date: Fri, 07 Nov 1997 08:52:58 -0500 From: "Mike O'Dell" you want interest? ok.... as a person looking to buy a couple of hundred million dollars worth of network elements over the next few years, I intend to require SNMPv3 from vendors to get that money. and i have perfect knowledge that several vendors are feverishly working to have a shot at taking it, some with running code already. -mo From qqi@world.std.com Fri Nov 7 12:54:01 1997 Delivery-Date: Fri, 07 Nov 1997 12:54:01 -0500 Return-Path: qqi@world.std.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA09326 for ; Fri, 7 Nov 1997 12:54:00 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA19867 for ; Fri, 7 Nov 1997 12:57:00 -0500 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA09322 for ; Fri, 7 Nov 1997 12:53:53 -0500 (EST) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id MAA02386; Fri, 7 Nov 1997 12:53:53 -0500 (EST) Received: by world.std.com (5.65c/Spike-2.0) id AA11507; Fri, 7 Nov 1997 12:53:53 -0500 From: qqi@world.std.com (Quality Quorum) Message-Id: <199711071753.AA11507@world.std.com> Subject: Re: SNMPv3, last call To: mo@uu.net (Mike O'Dell) Date: Fri, 7 Nov 1997 12:53:53 -0500 (EST) Cc: snmpv3@tis.com, iesg@ietf.org In-Reply-To: from "Mike O'Dell" at Nov 7, 97 08:52:58 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > you want interest? ok.... Aren't you our area director ? Or may be I am missing something. > as a person looking to buy a couple of hundred million dollars worth > of network elements over the next few years, I intend to require > SNMPv3 from vendors to get that money. BTW, if all you need are secure SETs, RFCs 1909-1910 do provide a better environment to do it. > and i have perfect knowledge that several vendors are feverishly > working to have a shot at taking it, some with running code already. So what ? I saw a lot of unreasonable requests from my customers too :). Did I work *feverishly* to satisfy them - yes :). BTW, cold facts are cold facts no matter what our attitudes are: I did not see any interest expressed by general public to the specs. > -mo Thanks, Aleksey From aeb1@amneris.noceast.dws.disney.com Fri Nov 7 15:53:14 1997 Delivery-Date: Fri, 07 Nov 1997 15:53:15 -0500 Return-Path: aeb1@amneris.noceast.dws.disney.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA11939 for ; Fri, 7 Nov 1997 15:53:14 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA20636 for ; Fri, 7 Nov 1997 15:56:14 -0500 (EST) Received: from huey.disney.com (0@huey.disney.com [204.128.192.10]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA11936 for ; Fri, 7 Nov 1997 15:53:09 -0500 (EST) Received: from amneris.noceast.dws.disney.com (amneris.noceast.dws.disney.com [153.6.200.150]) by huey.disney.com (8.7.5/8.7.3) with ESMTP id MAA09130; Fri, 7 Nov 1997 12:51:32 -0800 (PST) Received: (from aeb1@localhost) by amneris.noceast.dws.disney.com (8.6.12/8.6.12) id PAA06408; Fri, 7 Nov 1997 15:50:38 -0500 Date: Fri, 7 Nov 1997 15:50:32 -0500 (EST) From: "Alan E. Beard" To: Quality Quorum cc: "Mike O'Dell" , snmpv3@tis.com, iesg@ietf.org Subject: Re: SNMPv3, last call In-Reply-To: <199711071753.AA11507@world.std.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Aleksey et al: I have watched this very public dispute over the past several weeks with growing dismay. Although I have been entirely silent up to this point, I will now speak my mind (what little there is of it) in clear, perhaps blunt language. Responses inline. On Fri, 7 Nov 1997, Quality Quorum wrote: > Date: Fri, 7 Nov 1997 12:53:53 -0500 (EST) > From: Quality Quorum > To: Mike O'Dell > Cc: snmpv3@tis.com, iesg@ietf.org > Subject: Re: SNMPv3, last call > > > > > > > you want interest? ok.... > > Aren't you our area director ? Or may be I am missing something. > Interest exists beyond the area director. However, at least some remaining observers of the activities of the working group have elected to reserve their comments for fear of further inflaming the apparently sore tempers of a small number of regular contributors to (perhaps "participants in" would be more accurate) this discussion. IMO, the working group have produced a workable specification under very difficult conditions. Is it perfect? Probably not. Is it sufficiently sound from a technical standpoint to be commercially viable? Probably so. Can it be improved? Probably so. Should publication of the draft document be delayed as provided in the last call process pending additional modifications? NO. That's my opinion, and I am unlikely to change it. And since I have to recommend to my management strategies for management protocols and systems in our network, I have a clear and compelling interest in a technically sound and commercially viable successor to SNMP V1. *I am strongly in favor of allowing the drafts to go forward in their present form, even though a wrong decision on this could adversely affect my relationships with our senior management.* In short, I am willing to bet a substantial portion of my career on this specification, mostly because I am firmly of the opinion that further time spent on modifications will cost more that the benefit such modifications are likely to bring. I don't know how to state my opinion more clearly than that. > > as a person looking to buy a couple of hundred million dollars worth > > of network elements over the next few years, I intend to require > > SNMPv3 from vendors to get that money. > > BTW, if all you need are secure SETs, RFCs 1909-1910 do provide a better > environment to do it. > Most user network administrators are looking for secure sets, but not _exclusively_ for that function. The overall SNMPV3 spec as proposed is probably the soundest standards-based specification, taken as a whole, that can be got in a reasonable time. Further delay is not warranted, at least in the opinion of this user. > > and i have perfect knowledge that several vendors are feverishly > > working to have a shot at taking it, some with running code already. > > So what ? I saw a lot of unreasonable requests from my customers too :). > Did I work *feverishly* to satisfy them - yes :). > We, too, will begin to request implementations of SNMPV3 from our suppliers as soon as the RFCs come out of draft status. We do not consider this unreasonable, given what we have in use today. And we _will_ demand that the manufacturers meet our expectation for SNMPV3 support, as will many other purchasers, unless the specification proves so flawed as to be technically infeasible, an eventuality we consider unlikely in the extreme. > BTW, cold facts are cold facts no matter what our attitudes are: I did > not see any interest expressed by general public to the specs. > You have now seen at least one such expression of interest and, perhaps curiously to your eyes, strong support. These drafts should go forward; further delay is not warranted. > > -mo > > Thanks, > > Aleksey > > > The above represents my opinion, not company policy. However, I will recommend my opinion to our management, since company policy on SNMPv3 is not yet established. AEB ------------------------------------------------------------------------- Alan E. Beard Network Design, Disney Worldwide Services DISC Building NSA Walt Disney World PO Box 10,000 Lake Buena Vista, FL 32830-1000 PH: (407) 824-2004 (tie line 8273) EMAIL: aeb1@amneris.noceast.dws.disney.com SnailMail: deprecated, but see above if you must ------------------------------------------------------------------------- From qqi@world.std.com Sat Nov 8 08:12:10 1997 Delivery-Date: Sat, 08 Nov 1997 08:12:11 -0500 Return-Path: qqi@world.std.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA23413 for ; Sat, 8 Nov 1997 08:12:10 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA22259 for ; Sat, 8 Nov 1997 08:15:09 -0500 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA23410 for ; Sat, 8 Nov 1997 08:12:02 -0500 (EST) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id IAA21904; Sat, 8 Nov 1997 08:12:03 -0500 (EST) Received: by world.std.com (5.65c/Spike-2.0) id AA15761; Sat, 8 Nov 1997 08:12:03 -0500 From: qqi@world.std.com (Quality Quorum) Message-Id: <199711081312.AA15761@world.std.com> Subject: Re: SNMPv3, last call To: aeb1@amneris.noceast.dws.disney.com (Alan E. Beard) Date: Sat, 8 Nov 1997 08:12:03 -0500 (EST) Cc: snmpv3@tis.com, iesg@ietf.org In-Reply-To: from "Alan E. Beard" at Nov 7, 97 03:50:32 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Interest exists beyond the area director. However, at least some > remaining observers of the activities of the working group have elected > to reserve their comments for fear of further inflaming the apparently > sore tempers of a small number of regular contributors to (perhaps > "participants in" would be more accurate) this discussion. ????? Did you read this group in say 1994 ? > IMO, the working group have produced a workable specification under very > difficult conditions. Is it perfect? Probably not. Is it sufficiently > sound from a technical standpoint to be commercially viable? Probably > so. Can it be improved? Probably so. Should publication of the draft > document be delayed as provided in the last call process pending > additional modifications? NO. That's my opinion, and I am unlikely to > change it. Main point of disagrement is whether specs are good enough to be immediately released at the Proposed Standard or they should be kept at Experimental level, at least for a while. I would say that you had expressed enough reservations for Experimental status to look appropriate. > I am willing to bet a substantial portion of my career on this > specification, mostly because I am firmly of the opinion that further > time spent on modifications will cost more that the benefit such > modifications are likely to bring. I don't know how to state my opinion > more clearly than that. Oh, as long as SNMPv1 NMS will be able to talk to SNMPv3 device, you have nothing to fear. > Most user network administrators are looking for secure sets, but not > _exclusively_ for that function. The overall SNMPV3 spec as proposed is > probably the soundest standards-based specification, taken as a whole, > that can be got in a reasonable time. Further delay is not warranted, at > least in the opinion of this user. Again, it seems like experimental level for the spec will be a fine match to your opinion. > You have now seen at least one such expression of interest and, perhaps > curiously to your eyes, strong support. ^^^^^^ In my eys your support looks like a very cautious one :). > AEB Aleksey From aeb1@amneris.noceast.dws.disney.com Mon Nov 10 10:08:26 1997 Delivery-Date: Mon, 10 Nov 1997 10:08:27 -0500 Return-Path: aeb1@amneris.noceast.dws.disney.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA12861 for ; Mon, 10 Nov 1997 10:08:26 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02360 for ; Mon, 10 Nov 1997 10:11:27 -0500 (EST) Received: from huey.disney.com (0@huey.disney.com [204.128.192.10]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA12857 for ; Mon, 10 Nov 1997 10:08:23 -0500 (EST) Received: from amneris.noceast.dws.disney.com (amneris.noceast.dws.disney.com [153.6.200.150]) by huey.disney.com (8.7.5/8.7.3) with ESMTP id HAA26948; Mon, 10 Nov 1997 07:08:23 -0800 (PST) Received: (from aeb1@localhost) by amneris.noceast.dws.disney.com (8.6.12/8.6.12) id KAA06781; Mon, 10 Nov 1997 10:07:27 -0500 Date: Mon, 10 Nov 1997 10:07:26 -0500 (EST) From: "Alan E. Beard" To: Quality Quorum cc: snmpv3@tis.com, iesg@ietf.org Subject: Re: SNMPv3, last call In-Reply-To: <199711081312.AA15761@world.std.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Aleksey: Thanks for your gracious and prompt response. Comments inline. On Sat, 8 Nov 1997, Quality Quorum wrote: > Date: Sat, 8 Nov 1997 08:12:03 -0500 (EST) > From: Quality Quorum > To: "Alan E. Beard" > Cc: snmpv3@tis.com, iesg@ietf.org > Subject: Re: SNMPv3, last call > > > Interest exists beyond the area director. However, at least some > > remaining observers of the activities of the working group have elected > > to reserve their comments for fear of further inflaming the apparently > > sore tempers of a small number of regular contributors to (perhaps > > "participants in" would be more accurate) this discussion. > > ????? > > Did you read this group in say 1994 ? > Yes, and I reserved my comments then (except upon rare occasions) for much the same reason. Granted, present conditions are _much_ improved from the great SNMPv2 wars, but I still put on my nomex-and-chain-mail knickers before venturing into the mailing list. ;-) > Main point of disagrement is whether specs are good enough to be > immediately released at the Proposed Standard or they should be kept at > Experimental level, at least for a while. I would say that you had expressed > enough reservations for Experimental status to look appropriate. > This is a judgement call. Experimental status is, at least in my opinion, an option, but it may not be best for the communuity of network designers and network administrators, particularly those in commercial environments. Senior management in commercial shops are unlikely to permit introduction of any implementation based on an "experimental" specification - it scares the bejabbers out of folks who might not understand the IETF standards-track process. Senior management are even less likely to pay _money_ for implementations based on experimental specifications. It may be better for the commercial network-administration community to allow these drafts to be promoted to full standards; if, in the course of commercial implementation and deployment, improvements in the protocol specification come into being (either as developer-coded alternatives or private extensions to the specifications) the standards specifications may be modified or extended as appropriate. This is not unprecedented, nor is it invarably fatal: SMTP and DNS have both been extended and modified over time, and neither seems in danger of immediate demise. > > I am willing to bet a substantial portion of my career on this > > specification, mostly because I am firmly of the opinion that further > > time spent on modifications will cost more that the benefit such > > modifications are likely to bring. I don't know how to state my opinion > > more clearly than that. > > Oh, as long as SNMPv1 NMS will be able to talk to SNMPv3 device, you have > nothing to fear. > In the immediate, you are, of course, absolutely correct. However, we are beginning to try the upper bound of SNMPv1 function and the limits of many SNMPv1 commercial implementations. It would be exceedingly helpful for us to have available from commercial sources (and at reasonable cost) the additional function of SNMPv3 as currently defined. > > Most user network administrators are looking for secure sets, but not > > _exclusively_ for that function. The overall SNMPV3 spec as proposed is > > probably the soundest standards-based specification, taken as a whole, > > that can be got in a reasonable time. Further delay is not warranted, at > > least in the opinion of this user. > > Again, it seems like experimental level for the spec will be a fine match to > your opinion. > Granted, the reasoning set forth above does not _exclude_ the possibility of experimental status. However, I continue to be of the opinion that promotion to full standard is a better course. Experimental status is not a _wrong_ choice; it is, however, not the optimum choice, IMO. > > You have now seen at least one such expression of interest and, perhaps > > curiously to your eyes, strong support. > ^^^^^^ > In my eys your support looks like a very cautious one :). > Hmmm. I had not seen it in quite that light. My support for the current drafts is, granted, not unqualified; however, I think it can nonetheless be accurately described as strong. I still think that the risks of going forward are, for the commercial network administrators, less than the risks occasioned by further delay. The specifications as now proposed are, IMO, sufficiently sound to support viable (even good) commercial implementations. I think the drafts should be promoted to standards status. > > > AEB > > Aleksey > > Again, thank you for the time taken to discuss these matters, and for your thoughtful and gracious response. Regards, AEB Please note that the opinions above should not be construed as giving any indication of any policy or opinion of Disney Worldwide Services or any other Disney company. These opinions are strictly my own. ------------------------------------------------------------------------- Alan E. Beard Network Design, Disney Worldwide Services DISC Building NSA Walt Disney World PO Box 10,000 Lake Buena Vista, FL 32830-1000 PH: (407) 824-2004 (tie line 8273) EMAIL: aeb1@amneris.noceast.dws.disney.com SnailMail: deprecated, but see above if you must ------------------------------------------------------------------------- From qqi@world.std.com Mon Nov 10 11:39:35 1997 Delivery-Date: Mon, 10 Nov 1997 11:39:35 -0500 Return-Path: qqi@world.std.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA14912 for ; Mon, 10 Nov 1997 11:39:34 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03046 for ; Mon, 10 Nov 1997 11:42:31 -0500 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA14899 for ; Mon, 10 Nov 1997 11:39:27 -0500 (EST) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id LAA12422; Mon, 10 Nov 1997 11:39:26 -0500 (EST) Received: by world.std.com (5.65c/Spike-2.0) id AA29371; Mon, 10 Nov 1997 11:39:26 -0500 From: qqi@world.std.com (Quality Quorum) Message-Id: <199711101639.AA29371@world.std.com> Subject: Re: SNMPv3, last call To: aeb1@amneris.noceast.dws.disney.com (Alan E. Beard) Date: Mon, 10 Nov 1997 11:39:26 -0500 (EST) Cc: snmpv3@tis.com, iesg@ietf.org In-Reply-To: from "Alan E. Beard" at Nov 10, 97 10:07:26 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Only two short notes: > > Main point of disagrement is whether specs are good enough to be > > immediately released at the Proposed Standard or they should be kept at > > Experimental level, at least for a while. I would say that you had expressed > > enough reservations for Experimental status to look appropriate. > > > This is a judgement call. Experimental status is, at least in my > opinion, an option, but it may not be best for the communuity of network > designers and network administrators, particularly those in commercial > environments. Senior management in commercial shops are unlikely to > permit introduction of any implementation based on an "experimental" > specification - it scares the bejabbers out of folks who might not > understand the IETF standards-track process. Senior management are even > less likely to pay _money_ for implementations based on experimental > specifications. 1. It seems like you are implying that specs are not able to stay on its own beacuase they have to be propped by artificially inflated status. 2. Considering experimental status assigned to RFC 1901, applying reasons of this kind is highly unusual to the established standartization process. > AEB Aleksey From aeb1@amneris.noceast.dws.disney.com Mon Nov 10 13:56:09 1997 Delivery-Date: Mon, 10 Nov 1997 13:56:09 -0500 Return-Path: aeb1@amneris.noceast.dws.disney.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA16124 for ; Mon, 10 Nov 1997 13:56:08 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03643 for ; Mon, 10 Nov 1997 13:59:07 -0500 (EST) Received: from huey.disney.com (0@huey.disney.com [204.128.192.10]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA16120 for ; Mon, 10 Nov 1997 13:55:56 -0500 (EST) Received: from amneris.noceast.dws.disney.com (amneris.noceast.dws.disney.com [153.6.200.150]) by huey.disney.com (8.7.5/8.7.3) with ESMTP id KAA01727; Mon, 10 Nov 1997 10:55:53 -0800 (PST) Received: (from aeb1@localhost) by amneris.noceast.dws.disney.com (8.6.12/8.6.12) id NAA06964; Mon, 10 Nov 1997 13:54:58 -0500 Date: Mon, 10 Nov 1997 13:54:58 -0500 (EST) From: "Alan E. Beard" To: Quality Quorum cc: snmpv3@tis.com, iesg@ietf.org Subject: Re: SNMPv3, last call In-Reply-To: <199711101639.AA29371@world.std.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Aleksey: Again, thanks for the response. I want to clarify one point, then I'll fall silent again. We have expressed our opinions clearly; it is now time to let the AD make his judgement. On Mon, 10 Nov 1997, Quality Quorum wrote: > Date: Mon, 10 Nov 1997 11:39:26 -0500 (EST) > From: Quality Quorum > To: "Alan E. Beard" > Cc: snmpv3@tis.com, iesg@ietf.org > Subject: Re: SNMPv3, last call > > > > Only two short notes: > > > > > Main point of disagrement is whether specs are good enough to be > > > immediately released at the Proposed Standard or they should be kept at > > > Experimental level, at least for a while. I would say that you had expressed > > > enough reservations for Experimental status to look appropriate. > > > > > This is a judgement call. Experimental status is, at least in my > > opinion, an option, but it may not be best for the communuity of network > > designers and network administrators, particularly those in commercial > > environments. Senior management in commercial shops are unlikely to > > permit introduction of any implementation based on an "experimental" > > specification - it scares the bejabbers out of folks who might not > > understand the IETF standards-track process. Senior management are even > > less likely to pay _money_ for implementations based on experimental > > specifications. > > 1. It seems like you are implying that specs are not able to stay on its > own beacuase they have to be propped by artificially inflated status. > Perhaps I should have been less circumspect. Actually, my intent here was somewhat different; I'll clarify. I suggest that, in commercial environments, _any_ specification, even one demonstrably perfect in every respect, would be greatly disadvantaged by bearing the label "experimental". It doesn't make technical sense; in fact, it flies in the face of all logic. But such is the practice in commercial user environments, particularly those where senior financial management have come to insist that the network must be "a high-reliability production system." The issue, at least to my mind, is that we may fatally hobble an otherwise sound specification by labeling it experimental. The suggestion that we might lend artificial credibility to a fundamentally unworkable specification by improperly granting it "Proposed Standard" status would be compelling if I believed the SNMPv3 specifications in their present form to be other than fundamentally sound and commercially viable. However, such is _not_ my opinion, so, at least to my eyes, the argument fails not on logic but on premises. Put in legal terms, this is an issue of fact rather than an issue of law. We are trying the facts here, and the judgement has not yet been handed down by the AD. > 2. Considering experimental status assigned to RFC 1901, applying > reasons of this kind is highly unusual to the established standartization > process. > The course of this matter is perhaps too painfully known to all who might see this correspondence to countenance yet another rehash of the issues. Right or wrong, it's history now. > > AEB > > Aleksey > Thanks for your time and patience with this matter. We've made our opinions known: now the matter is up to the AD. AEB The opinions above are mine alone. No element of Disney Company policy may be construed from any of the foregoing. ------------------------------------------------------------------------- Alan E. Beard Network Design, Disney Worldwide Services DISC Building NSA Walt Disney World PO Box 10,000 Lake Buena Vista, FL 32830-1000 PH: (407) 824-2004 (tie line 8273) EMAIL: aeb1@amneris.noceast.dws.disney.com SnailMail: deprecated, but see above if you must ------------------------------------------------------------------------- From dward@hns.com Mon Nov 10 18:03:07 1997 Delivery-Date: Mon, 10 Nov 1997 18:03:07 -0500 Return-Path: dward@hns.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA18932 for ; Mon, 10 Nov 1997 18:03:06 -0500 (EST) From: dward@hns.com Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA04799 for ; Mon, 10 Nov 1997 18:06:07 -0500 (EST) Received: from hnssysb.hns.com (hnssysb.hns.com [139.85.52.101]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA18929 for ; Mon, 10 Nov 1997 18:03:00 -0500 (EST) Received: from ngw2.hns.com (ngw2.hns.com [139.85.177.38]) by hnssysb.hns.com (8.8.3/) with SMTP id SAA19245; Mon, 10 Nov 1997 18:01:30 -0500 (EST) Received: by ngw2.hns.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525654B.007E8ECF ; Mon, 10 Nov 1997 18:02:20 -0500 X-Lotus-FromDomain: HNS To: aeb1@amneris.noceast.dws.disney.com cc: qqi@world.std.com, snmpv3@tis.com, iesg@ietf.org Message-ID: <8525654B.007E799E.00@ngw2.hns.com> Date: Mon, 10 Nov 1997 18:01:49 -0500 Subject: Re: SNMPv3, last call Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Dick Ward does not exist. To: qqi @ world.std.com cc: snmpv3 @ tis.com, iesg @ ietf.org (bcc: Dick Ward/HNS) From: aeb1 @ amneris.noceast.dws.disney.com Date: 11/10/97 10:07:26 AM Subject: Re: SNMPv3, last call SMTP Headers: Headers Aleksey: Thanks for your gracious and prompt response. Comments inline. On Sat, 8 Nov 1997, Quality Quorum wrote: > Date: Sat, 8 Nov 1997 08:12:03 -0500 (EST) > From: Quality Quorum > To: "Alan E. Beard" > Cc: snmpv3@tis.com, iesg@ietf.org > Subject: Re: SNMPv3, last call > > > Interest exists beyond the area director. However, at least some > > remaining observers of the activities of the working group have elected > > to reserve their comments for fear of further inflaming the apparently > > sore tempers of a small number of regular contributors to (perhaps > > "participants in" would be more accurate) this discussion. > > ????? > > Did you read this group in say 1994 ? > Yes, and I reserved my comments then (except upon rare occasions) for much the same reason. Granted, present conditions are _much_ improved from the great SNMPv2 wars, but I still put on my nomex-and-chain-mail knickers before venturing into the mailing list. ;-) > Main point of disagrement is whether specs are good enough to be > immediately released at the Proposed Standard or they should be kept at > Experimental level, at least for a while. I would say that you had expressed > enough reservations for Experimental status to look appropriate. > This is a judgement call. Experimental status is, at least in my opinion, an option, but it may not be best for the communuity of network designers and network administrators, particularly those in commercial environments. Senior management in commercial shops are unlikely to permit introduction of any implementation based on an "experimental" specification - it scares the bejabbers out of folks who might not understand the IETF standards-track process. Senior management are even less likely to pay _money_ for implementations based on experimental specifications. It may be better for the commercial network-administration community to allow these drafts to be promoted to full standards; if, in the course of commercial implementation and deployment, improvements in the protocol specification come into being (either as developer-coded alternatives or private extensions to the specifications) the standards specifications may be modified or extended as appropriate. This is not unprecedented, nor is it invarably fatal: SMTP and DNS have both been extended and modified over time, and neither seems in danger of immediate demise. > > I am willing to bet a substantial portion of my career on this > > specification, mostly because I am firmly of the opinion that further > > time spent on modifications will cost more that the benefit such > > modifications are likely to bring. I don't know how to state my opinion > > more clearly than that. > > Oh, as long as SNMPv1 NMS will be able to talk to SNMPv3 device, you have > nothing to fear. > In the immediate, you are, of course, absolutely correct. However, we are beginning to try the upper bound of SNMPv1 function and the limits of many SNMPv1 commercial implementations. It would be exceedingly helpful for us to have available from commercial sources (and at reasonable cost) the additional function of SNMPv3 as currently defined. > > Most user network administrators are looking for secure sets, but not > > _exclusively_ for that function. The overall SNMPV3 spec as proposed is > > probably the soundest standards-based specification, taken as a whole, > > that can be got in a reasonable time. Further delay is not warranted, at > > least in the opinion of this user. > > Again, it seems like experimental level for the spec will be a fine match to > your opinion. > Granted, the reasoning set forth above does not _exclude_ the possibility of experimental status. However, I continue to be of the opinion that promotion to full standard is a better course. Experimental status is not a _wrong_ choice; it is, however, not the optimum choice, IMO. > > You have now seen at least one such expression of interest and, perhaps > > curiously to your eyes, strong support. > ^^^^^^ > In my eys your support looks like a very cautious one :). > Hmmm. I had not seen it in quite that light. My support for the current drafts is, granted, not unqualified; however, I think it can nonetheless be accurately described as strong. I still think that the risks of going forward are, for the commercial network administrators, less than the risks occasioned by further delay. The specifications as now proposed are, IMO, sufficiently sound to support viable (even good) commercial implementations. I think the drafts should be promoted to standards status. > > > AEB > > Aleksey > > Again, thank you for the time taken to discuss these matters, and for your thoughtful and gracious response. Regards, AEB Please note that the opinions above should not be construed as giving any indication of any policy or opinion of Disney Worldwide Services or any other Disney company. These opinions are strictly my own. ------------------------------------------------------------------------- Alan E. Beard Network Design, Disney Worldwide Services DISC Building NSA Walt Disney World PO Box 10,000 Lake Buena Vista, FL 32830-1000 PH: (407) 824-2004 (tie line 8273) EMAIL: aeb1@amneris.noceast.dws.disney.com SnailMail: deprecated, but see above if you must ------------------------------------------------------------------------- From qqi@world.std.com Tue Nov 11 08:38:28 1997 Delivery-Date: Tue, 11 Nov 1997 08:38:28 -0500 Return-Path: qqi@world.std.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA00053 for ; Tue, 11 Nov 1997 08:38:28 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA06153 for ; Tue, 11 Nov 1997 08:41:27 -0500 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA00047 for ; Tue, 11 Nov 1997 08:37:52 -0500 (EST) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id IAA29203; Tue, 11 Nov 1997 08:37:53 -0500 (EST) Received: by world.std.com (5.65c/Spike-2.0) id AA26630; Tue, 11 Nov 1997 08:37:53 -0500 From: qqi@world.std.com (Quality Quorum) Message-Id: <199711111337.AA26630@world.std.com> Subject: Re: SNMPv3, last call To: rjsmith@cisco.com (Richard Smith) Date: Tue, 11 Nov 1997 08:37:52 -0500 (EST) Cc: snmpv3@tis.com, iesg@ietf.org In-Reply-To: <199711110131.RAA04390@sheltie.cisco.com> from "Richard Smith" at Nov 10, 97 05:31:35 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Aleksey, > > You don't know me, and I'm not involved with SNMPv3 at all. > (I do work with SNMPv1 though :-) > > I have been following this discussion for a while, and I'm > wondering, if there is such a large security hole in SNMPv3 (and I > don't doubt that there is), why not challenge the WG to a "bake off". There is no doubt for WG members that this security hole exists - consensus is that it is OK to be open for attack of this kind. > They can put up their reference implementation of SNMPv3 (assuming > there is one), and if you can create a program that permanently wedges > their manager or their agent, then they have to go back to the drawing > board, and fix the RFCs. If you cannot, then the RFCs proceed as is. Nobody has any doubts that I can, but again consensus is that RFCs should proceed as is :). > My two cents, > > --Rich > Aleksey From benp@ancor.com Tue Nov 11 10:51:49 1997 Delivery-Date: Tue, 11 Nov 1997 10:51:50 -0500 Return-Path: benp@ancor.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02803 for ; Tue, 11 Nov 1997 10:51:49 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA06707 for ; Tue, 11 Nov 1997 10:54:49 -0500 (EST) Received: from ancor.com (root@xiuko.ancor.com [206.9.2.18]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02796 for ; Tue, 11 Nov 1997 10:51:45 -0500 (EST) Received: from tricord (tricord [192.82.149.97]) by ancor.com (8.8.5/8.8.5) with ESMTP id JAA01514; Tue, 11 Nov 1997 09:51:19 -0600 Received: from TRICORD/SpoolDir by tricord (Mercury 1.21); 11 Nov 97 10:05:20 +0600 Received: from SpoolDir by TRICORD (Mercury 1.21); 11 Nov 97 10:05:06 +0600 From: "Ben Preece" Organization: Ancor Communications, Inc. To: "Alan E. Beard" Date: Tue, 11 Nov 1997 10:05:06 +0600 Subject: Re: SNMPv3, last call CC: snmpv3@tis.com, iesg@ietf.org Return-receipt-to: "Ben Preece" Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Message-ID: <58A58576A7F@tricord> I'm just another one of those people who've watched without participating, and I don't know if opinions are still welcome. (I think) "Alan E. Beard" suggested: > It may be better for the commercial network-administration community to > allow these drafts to be promoted to full standards; if, in the course of > commercial implementation and deployment, improvements in the protocol > specification come into being (either as developer-coded alternatives or > private extensions to the specifications) the standards specifications > may be modified or extended as appropriate. This is not unprecedented, > nor is it invarably fatal: SMTP and DNS have both been extended and > modified over time, and neither seems in danger of immediate demise. I have no technical objections to the contents of the documents. However, the documents shouldn't be progressed unless there are actual independent interoperable implementations of the spec. Modifying a working protocol is one thing; fixing an unworkable protocol is another. If this has been published, then where can someone find a description of the SNMPv3 interoperability tests that have been done so far? If not, then some specific time period should be allowed to publicly demonstrate the current implementations before progressing the documents. Just MHO. -Ben ---------- Ben Preece Ancor Communications. Minnetonka, MN mailto:benp@ancor.com http://www.ancor.com From bok@cnd.hp.com Tue Nov 11 14:01:35 1997 Delivery-Date: Tue, 11 Nov 1997 14:01:35 -0500 Return-Path: bok@cnd.hp.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA04902 for ; Tue, 11 Nov 1997 14:01:34 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA07700 for ; Tue, 11 Nov 1997 14:04:34 -0500 (EST) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA04892 for ; Tue, 11 Nov 1997 14:01:07 -0500 (EST) Received: from nsmdserv.cnd.hp.com (daemon@nsmdserv.cnd.hp.com [15.2.104.118]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id LAA13544; Tue, 11 Nov 1997 11:01:03 -0800 (PST) Received: from nautique (nautique.cnd.hp.com) by nsmdserv.cnd.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA202214858; Tue, 11 Nov 1997 12:00:58 -0700 Message-Id: <3468AB6C.4776@cnd.hp.com> Date: Tue, 11 Nov 1997 12:01:00 -0700 From: "Brian O'Keefe" Reply-To: bok@cnd.hp.com Organization: Hewlett-Packard Company X-Mailer: Mozilla 3.01Gold (WinNT; I) Mime-Version: 1.0 To: Quality Quorum Cc: Richard Smith , snmpv3@tis.com, iesg@ietf.org Subject: Re: SNMPv3, last call References: <199711111337.AA26630@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Quality Quorum wrote: > > > > > Aleksey, > > > > You don't know me, and I'm not involved with SNMPv3 at all. > > (I do work with SNMPv1 though :-) > > > > I have been following this discussion for a while, and I'm > > wondering, if there is such a large security hole in SNMPv3 (and I > > don't doubt that there is), why not challenge the WG to a "bake off". > > There is no doubt for WG members that this security hole exists - > consensus is that it is OK to be open for attack of this kind. > > > They can put up their reference implementation of SNMPv3 (assuming > > there is one), and if you can create a program that permanently wedges > > their manager or their agent, then they have to go back to the drawing > > board, and fix the RFCs. If you cannot, then the RFCs proceed as is. > > Nobody has any doubts that I can, but again consensus is that RFCs > should proceed as is :). > > Aleksey Aleksey, I have doubts you can. Further, never once have you actually detailed your proposed solution for the working group (e.g., elements of procedure). Either put up or shut up. bok From qqi@world.std.com Tue Nov 11 15:14:58 1997 Delivery-Date: Tue, 11 Nov 1997 15:14:59 -0500 Return-Path: qqi@world.std.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA05887 for ; Tue, 11 Nov 1997 15:14:58 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08041 for ; Tue, 11 Nov 1997 15:17:57 -0500 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA05884 for ; Tue, 11 Nov 1997 15:14:56 -0500 (EST) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id PAA01662; Tue, 11 Nov 1997 15:14:54 -0500 (EST) Received: by world.std.com (5.65c/Spike-2.0) id AA01558; Tue, 11 Nov 1997 15:14:54 -0500 From: qqi@world.std.com (Quality Quorum) Message-Id: <199711112014.AA01558@world.std.com> Subject: Re: SNMPv3, last call To: bok@cnd.hp.com Date: Tue, 11 Nov 1997 15:14:54 -0500 (EST) Cc: snmpv3@tis.com, iesg@ietf.org In-Reply-To: <3468AB6C.4776@cnd.hp.com> from "Brian O'Keefe" at Nov 11, 97 12:01:00 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Quality Quorum wrote: > > > > > > > > Aleksey, > > > > > > You don't know me, and I'm not involved with SNMPv3 at all. > > > (I do work with SNMPv1 though :-) > > > > > > I have been following this discussion for a while, and I'm > > > wondering, if there is such a large security hole in SNMPv3 (and I > > > don't doubt that there is), why not challenge the WG to a "bake off". > > > > There is no doubt for WG members that this security hole exists - > > consensus is that it is OK to be open for attack of this kind. > > > > > They can put up their reference implementation of SNMPv3 (assuming > > > there is one), and if you can create a program that permanently wedges > > > their manager or their agent, then they have to go back to the drawing > > > board, and fix the RFCs. If you cannot, then the RFCs proceed as is. > > > > Nobody has any doubts that I can, but again consensus is that RFCs > > should proceed as is :). > > > > Aleksey > > Aleksey, I have doubts you can. Further, never once have you > actually detailed your proposed solution for the working group > (e.g., elements of procedure). Apparently you are not reading this group too often. My proposal is on the table a loooong time - get rid of unsecure reports - they do not buy anything good anyway. And just to refresh you and others memeory, I am attaching nice desctiption of the problme posted by Uri not so long time ago. He was responding to R.G. Mundy. > Either put up or shut up. If we are talking aout ideas and solutions I have no problems to put up, what about you ? > bok Aleksey ======================================================================== : From uri@watson.ibm.com Sun Sep 21 02:05:14 1997 : Received: from igw3.watson.ibm.com by world.std.com (5.65c/Spike-2.0) : id AA16477; Sat, 20 Sep 1997 22:05:21 -0400 : Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id WAA15320; Sat, 20 Sep 1997 22:05:15 -0400 : Received: from v9n4fi0.watson.ibm.com (v9n4fi0.watson.ibm.com [9.2.122.13]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id WAA23000; Sat, 20 Sep 1997 22:05:14 -0400 : Received: by v9n4fi0.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) : id AA49362; Sat, 20 Sep 1997 22:05:14 -0400 : From: Uri Blumenthal : Message-Id: <9709210205.AA49362@v9n4fi0.watson.ibm.com> : Subject: Re: "Secure" Reports (was:Re: Delayed/Revised I-D release Date) : To: mundy@tis.com (G R Mundy) : Date: Sat, 20 Sep 1997 22:05:14 -0400 (EDT) : Cc: qqi@world.std.com, uri@watson.ibm.com (Uri Blumenthal) : In-Reply-To: <199709192113.RAA10773@clipper.hq.tis.com> from "G R Mundy" at Sep 19, 97 05:13:52 pm : Reply-To: uri@watson.ibm.com : X-Mailer: ELM [version 2.4 PL25] : Content-Type: text : Status: RO : : One big argument for the reports [back when adding those was : discussed] was: "Now if you mistyped your password, you don't : have to wait three minutes and then guess whether the password : was incorrect, or your packet hasn't made it through, or maybe : the response was lost." : : Of course, securing report "Wrong digest" makes little sense, : because if it's mistyped password that we worry about, the : report won't be authenticate-able anyway (guess why :-). : : When there are no hostiles with capabilities to transmit on the : wire (i.e. the highest threat level is eavesdropping), insecure : reports have no undesirable side-effects. : : But this is not a realistic picture. : : Imagine me on the wire, listening to your communications with your : agents. At some point when I see you sending a request to an agent, : I immediately send to you (spoof) a report message as-if from that : agent, saying "Wrong Digest" (with the correct message-ID etc). : : As a manager (NMS), what are you going to do? [Note: the number of : choices isn't overwhelming.] : : Naturally I can watch your reaction and fine-tune the attack. : In general, it is of the denial-of-service class and nothing : more. However, the ease of mounting it does mean our results : are less than superb. Plus, see below. : : > This illustration does not provide any compelling reason to "secure : > all reports". : : It is not feasible to secure them all, regardless. In the above : example, what is one supposed to do, receiving a "Wrong Digest" : report that doesn't authenticate correctly? Is it a spoof or is : my password mistyped, or were both the request and the report : damaged en-route? Your action? : : > - The first assumption seems to be that an implementation and/or : > operational use cannot be "more secure" than what is required by the : > specs. If users want to make greater use of the available : > cryptographic mechanisms because of their operational environment, : > there is nothing in the specs prevents that. : : Would you care to amplify? What mechanisms did you have in mind? To : the best of my knowledge, there are no applicable cryptographic : mechanisms [plus, it used to be SNMP position not to rely : on any outside service, cryptographic or otherwise]. : : > ...attackers will be able predict the specific reaction of management : > station software (& possibly the human operator reaction to the : > software reaction).... : : There are rather few choices and they're all easily observed on the wire. : : > -- It would be difficult for an attacker to know the reaction of a : > specific management station software package to a particular incoming : > report. : : Easily determined by spoofing such report and observing the reaction. : : > -- If a successful attack required the operator to take a specific : > action, this would be even harder to predict than the management : > station software reaction. : : (a) set of reasonable actions is usually very limited, plus the choice : is often clear from watching the subsequent traffic; and (b) success : here means more than a simple denial-of-service - but a combination : attack [i.e. attack on SNMP expecting a certain (possibly verifiable) : reaction from the operator, exploitable in a parallel attack using : another protocol]. : : > -- An operational use that is concerned with meeting certain : > security requirements should not permit the use of a lower : > securityLevel (even if the operator tries). : : >From SNMP point of view, report-related attacks appear to be only of : denial-of-service class. However,the highest security level provided : by SNMPv3 does not foil these. Plus, what may be denial-of-service : only for SNMP, can be a part of a wider attack, crossing over : more than one protocol. : : > If there is something we're missing perhaps a better description of : > your concern or different illustration will clarify things. : : I don't think it's practical (or even possible) to completely foil : denial-of-service attacks. However, the concern here is that we're : making it too easy to mount a successful attack on SNMPv3 NMS. : : > > I think it is really simple to fix reports, there is simple no will to : > > do it - I feel the reason is that some of you just fall in love with : > > the concept. : : How do you propose to fix them? Can you explain "while I'm standing : on one foot"? : -- : Regards, : Uri uri@watson.ibm.com : -=-=-=-=-=-=- : : : From qqi@world.std.com Wed Nov 12 12:35:13 1997 Delivery-Date: Wed, 12 Nov 1997 12:35:13 -0500 Return-Path: qqi@world.std.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA21819 for ; Wed, 12 Nov 1997 12:35:13 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA11150 for ; Wed, 12 Nov 1997 12:38:12 -0500 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA21816 for ; Wed, 12 Nov 1997 12:35:11 -0500 (EST) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id MAA17597; Wed, 12 Nov 1997 12:35:12 -0500 (EST) Received: by world.std.com (5.65c/Spike-2.0) id AA25925; Wed, 12 Nov 1997 12:35:12 -0500 From: qqi@world.std.com (Quality Quorum) Message-Id: <199711121735.AA25925@world.std.com> Subject: Re: SNMPv3, last call To: bstewart@cisco.com (Bob Stewart) Date: Wed, 12 Nov 1997 12:35:12 -0500 (EST) Cc: snmpv3@tis.com, iesg@ietf.org In-Reply-To: <3.0.3.32.19971112115606.006d77fc@zipper.cisco.com> from "Bob Stewart" at Nov 12, 97 11:56:06 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Going over and over and over the same ground is not useful. > > You have gained no support. You yourself have said repeatedly the working > group does not consider the problem worth solving. Accept that. I am accepting that, it does not mean that I agree and it does mean that whenever asked (e.g. in Last Call) I will provide my opinion on the subject. > Give it a rest. You lost. Stop wasting electricity by complaining about it. I am not complaining about anything. I posted a single post as a part of last call process and lots of people posted follow ups and I do respond when I feel necessary to clarify an issue, which was exactly the case with both Brian's and your post. E.g. Brian thinks that there is no problem here at all. > Bob Aleksey From qqi@world.std.com Wed Nov 12 15:23:40 1997 Delivery-Date: Wed, 12 Nov 1997 15:23:40 -0500 Return-Path: qqi@world.std.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA24150 for ; Wed, 12 Nov 1997 15:23:39 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA11852 for ; Wed, 12 Nov 1997 15:26:40 -0500 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA24145 for ; Wed, 12 Nov 1997 15:23:37 -0500 (EST) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id PAA17917; Wed, 12 Nov 1997 15:23:21 -0500 (EST) Received: by world.std.com (5.65c/Spike-2.0) id AA17397; Wed, 12 Nov 1997 15:23:21 -0500 From: qqi@world.std.com (Quality Quorum) Message-Id: <199711122023.AA17397@world.std.com> Subject: Re: SNMPv3, last call To: rpresuhn@peer.com (Randy Presuhn) Date: Wed, 12 Nov 1997 15:23:20 -0500 (EST) Cc: snmpv3@tis.com, iesg@ietf.org In-Reply-To: <199711121847.AA117460447@dorothy.peer.com> from "Randy Presuhn" at Nov 12, 97 10:47:27 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > What is more detailed solution intellegent person needs than > > one I had proposed many times: > > Please be patient with those of us who have not been blessed with such > intelligence. It seems like I am trying my best, just compare Brian mails and my responses. > > 1. Reports which cannot be made secure by their nature (e.g. > > "wrongDigest") should be excluded from the spec. > ... > > The attack you hinted at presumed behaviour on the part of the command > generator that, as far as I can tell, is not required by the current > documents. Problem is that current specs do limit ability of command generator to fend off denial of service attack. > Receipt of a "wrongDigest" provides prompt notification that > either there really is a wrongDigest, there is an implementation error, > or an attempted attack. This appears to be more information than silence. And may I ask how this information is intended to be used by receiving entity ? > > It was demonstrated and I did not see anybody disagreed > > that attack described by me will succeed. Disagreement > > is whether or not it is worth bother with protecting > > against it. > ... > > What about Uri's message (which Aleksey quoted)? It seemed to be a > pretty thorough analysis of just how far (or not) such an attack could go. Yes it is prety good analysis, I am wondering do you agree with its conclusion ? As far as I understand it concludes that SNMPv3 entity is indeed open to very simple attack. > Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Alkesey From daemon Fri Dec 5 07:30:39 1997 Delivery-Date: Fri, 05 Dec 1997 07:39:47 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id HAA11401 for ietf-123-outbound.10@ietf.org; Fri, 5 Dec 1997 07:29:47 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA11387; Fri, 5 Dec 1997 07:29:44 -0500 (EST) Message-Id: <199712051229.HAA11387@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: snmpv3@tis.com From: The IESG Subject: Protocol Action: An Architecture for Describing SNMP Management Frameworks to Proposed Standard Date: Fri, 05 Dec 1997 07:29:44 -0500 Sender: scoya@cnri.reston.va.us The IESG has approved the Internet-Draft for publication as Proposed Standards: An Architecture for Describing SNMP Management Frameworks Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) SNMPv3 Applications User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) These documents are the product of the SNMP Version 3 Working Group. The IESG contact persons are John Curran and Michael O'Dell. Technical Summary This protocol provides for the remote management of network elements, both in simple manager/agent systems, but also in more complex systems with proxy agents and delegation structures. The protocol is builds on the experience gained with SNMPv2 by keeping the enhanced SMI with richer data types and operators, but then extends the functionality to support proxies and certain extensibility notions with a more regular architecture and far fewer "magic relationships" than the previous designs. For example, it is now possible to concisely descibe whether an element acts as a manager or an agent, or both, without the contortions previously required. Most importantly, SNMPv3 provides a set of security mechanisms which are powerful and robust enough to dramatically improve the operational landscape of the global Internet, while remaining simple enough to be deployed at large scale. Working Group Summary In general, the Working Group converged quite strongly. An almost unfathomable amount of work was done in record time with a level of professionalism and decorum rarely seen in the IETF. One issue was raised in Last Call regarding denial of service attacks and it was resolved in rough consensus as the cure being worse than the ill, and a situation which is dramatically better than the problems with the currently-deployed technology. This is a clearly a judgement call - but the operations faction claims to be quite willing to live with the caveat. There was also a strong consensus that real field experience is now needed to identify and guide any further required work. Protocol Quality This work has been reviewed by the Area Director responsible for the work as well as others knowledgeable in both SNMP fundamentals and large-scale network management deployment. There is at least one draft implementation, possibly two, which tracked the drafts as they evolved. Feedback from this implementation was quite valuable to the document authors. At least one commercial SNMP technology foundry has demonstrated a fully functional implementation at a trade show, and work is under way to fund upgrading one of the publicly available SNMPv2 implementations to full SNMPv3. Several network element vendors have stated intentions to provide SNMPv3 implementations in their products in the near future. From daemon Fri Dec 5 11:35:07 1997 Delivery-Date: Fri, 05 Dec 1997 11:42:08 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA16250 for ietf-123-outbound.10@ietf.org; Fri, 5 Dec 1997 11:34:59 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA16222; Fri, 5 Dec 1997 11:34:55 -0500 (EST) Message-Id: <199712051634.LAA16222@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-v3mpc-model-07.txt Date: Fri, 05 Dec 1997 11:34:55 -0500 Sender: cclark@cnri.reston.va.us --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. Note: This revision reflects comments received during the last call period. Title : Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) Author(s) : J. Case, B. Wijnen, R. Presuhn, D. Harrington Filename : draft-ietf-snmpv3-v3mpc-model-07.txt Pages : 42 Date : 04-Dec-97 This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [SNMP-ARCH]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing 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-v3mpc-model-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-v3mpc-model-07.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-v3mpc-model-07.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: <19971204190035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-v3mpc-model-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-v3mpc-model-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204190035.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Dec 5 11:52:05 1997 Delivery-Date: Fri, 05 Dec 1997 11:58:10 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA17120 for ietf-123-outbound.10@ietf.org; Fri, 5 Dec 1997 11:51:53 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA17086; Fri, 5 Dec 1997 11:51:49 -0500 (EST) Message-Id: <199712051651.LAA17086@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-next-gen-arch-07.txt Date: Fri, 05 Dec 1997 11:51:49 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New 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 : An Architecture for Describing SNMP Management Frameworks Author(s) : B. Wijnen, R. Presuhn, D. Harrington Filename : draft-ietf-snmpv3-next-gen-arch-07.txt Pages : 59 Date : 04-Dec-97 This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpv3-next-gen-arch-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-next-gen-arch-07.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-next-gen-arch-07.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: <19971204185703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-next-gen-arch-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-next-gen-arch-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204185703.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Dec 5 13:37:36 1997 Delivery-Date: Fri, 05 Dec 1997 13:44:06 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA19863 for ietf-123-outbound.10@ietf.org; Fri, 5 Dec 1997 13:37:24 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA19833; Fri, 5 Dec 1997 13:37:19 -0500 (EST) Message-Id: <199712051837.NAA19833@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-appl-05.txt Date: Fri, 05 Dec 1997 13:37:19 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New 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-05.txt Pages : 79 Date : 04-Dec-97 This memo describes five types of SNMP applications which make use of an SNMP engine as described in [SNMP-ARCH]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. Internet-Drafts are available by anonymous FTP. Login with 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-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-appl-05.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-05.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: <19971204173031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-appl-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-appl-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204173031.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Dec 5 13:42:43 1997 Delivery-Date: Fri, 05 Dec 1997 13:49:12 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA20043 for ietf-123-outbound.10@ietf.org; Fri, 5 Dec 1997 13:42:28 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20014; Fri, 5 Dec 1997 13:42:25 -0500 (EST) Message-Id: <199712051842.NAA20014@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-usm-04.txt Date: Fri, 05 Dec 1997 13:42:24 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New 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) : B. Wijnen, U. Blumenthal Filename : draft-ietf-snmpv3-usm-04.txt Pages : 77 Date : 04-Dec-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 with 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-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-usm-04.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-04.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: <19971204173345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-usm-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-usm-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204173345.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Dec 5 13:48:30 1997 Delivery-Date: Fri, 05 Dec 1997 13:56:55 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA20241 for ietf-123-outbound.10@ietf.org; Fri, 5 Dec 1997 13:48:16 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20220; Fri, 5 Dec 1997 13:48:11 -0500 (EST) Message-Id: <199712051848.NAA20220@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-acm-05.txt Date: Fri, 05 Dec 1997 13:48:10 -0500 Sender: cclark@cnri.reston.va.us --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. Note: This revision reflects comments received during the last call period. Title : View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) Author(s) : K. McCloghrie, B. Wijnen, R. Presuhn Filename : draft-ietf-snmpv3-acm-05.txt Pages : 38 Date : 04-Dec-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-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-acm-05.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-05.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: <19971204173633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-acm-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-acm-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204173633.I-D@ietf.org> --OtherAccess-- --NextPart-- From list-owner-rmonmib-outgoing@cisco.com Wed Jan 7 17:22:06 1998 Delivery-Date: Wed, 07 Jan 1998 17:22:07 -0500 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA07016 for ; Wed, 7 Jan 1998 17:21:59 -0500 (EST) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11877 for ; Wed, 7 Jan 1998 17:24:47 -0500 (EST) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id OAA26756 for Rmonmib-outgoing; Wed, 7 Jan 1998 14:14:39 -0800 (PST) Received: from mailgate-rtp-1.cisco.com (mailgate-rtp-1.cisco.com [171.69.160.46]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id OAA26750 for ; Wed, 7 Jan 1998 14:14:33 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by mailgate-rtp-1.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id RAA14409 for ; Wed, 7 Jan 1998 17:14:31 -0500 (EST) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id OAA26215 for ; Wed, 7 Jan 1998 14:14:30 -0800 (PST) Received: from pimaia2w.prodigy.com(198.83.19.115) by proxy1.cisco.com via smap (V2.0) id xma026205; Wed, 7 Jan 98 22:14:27 GMT Received: from mime4.prodigy.com (mime4.prodigy.com [192.168.254.43]) by pimaia2w.prodigy.com (8.8.5/8.8.5) with ESMTP id RAA24264; Wed, 7 Jan 1998 17:13:25 -0500 Received: (from root@localhost) by mime4.prodigy.com (8.6.10/8.6.9) id RAA07980; Wed, 7 Jan 1998 17:07:18 -0500 Message-Id: <199801072207.RAA07980@mime4.prodigy.com> X-Mailer: Prodigy Internet GW(v0.9beta) - ae01dm04sc03 From: CEBA78B@prodigy.com ( JUDY A KELLER) Date: Wed, 7 Jan 1998 17:07:18, -0500 To: applmib-request@emi-summit.com, hubmib@hprnd.rose.hp.com, ieeetcpc@ccvm.sunysb.edu, ietf-madman@innosoft.com, ietf@ns.ietf.org, ifip-emilmgt@ics.uci.edu, ISODE-SNMPv2@ida.liu.se, members@nmf.org, ovforum@andrew.cmu.edu, rmonmib@cisco.com, snmp2@tis.com, snmp@psi.com, snmpv3@tis.com cc: j.keller@comsoc.org, g.weisman@comsoc.org Subject: NOMS '98 REGISTRATION Sender: owner-rmonmib@cisco.com Precedence: bulk Not yet Registered for NOMS'98? It is not too late but time is running out to attend IEEE/IFIP 1998 Network Operations and Management Symposium in New Orleans, Louisiana, USA, 15-20 February, 1998. We think that this will be your best opportunity in 1998 to examine the latest practical solutions and visionary ideas across all types of networks, products, technologies (SONET/SDH, ATM, Wireless), enterprise communications systems, distributed computing systems, and applications. See if you agree. Check our www site: http://www.comsoc. org/confs/noms/98 You'll also find scheduled exhibits, and on-line inquiry and registration forms on the site. But don't delay. Hotels will be jammed because of Mardi Gras celebrations. You should book your room by January 16 or you will pay far more -- if you can find space at all. Veli Sahin, General Chair P.S. My apologies if you have received more than one of these messages From CEBA78B@prodigy.com Wed Jan 7 17:22:58 1998 Delivery-Date: Wed, 07 Jan 1998 17:22:59 -0500 Return-Path: CEBA78B@prodigy.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA07034 for ; Wed, 7 Jan 1998 17:22:57 -0500 (EST) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11881 for ; Wed, 7 Jan 1998 17:25:45 -0500 (EST) Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id OAA07920; Wed, 7 Jan 1998 14:18:42 -0800 (PST) Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.20/15.5+ECS 3.3) id AA149151478; Wed, 7 Jan 1998 14:17:58 -0800 Received: from pimaia2w.prodigy.com (pimaia2w.prodigy.com [198.83.19.115]) by hp.com (8.8.5/8.8.5tis) with ESMTP id OAA19623 for ; Wed, 7 Jan 1998 14:17:55 -0800 (PST) Received: from mime4.prodigy.com (mime4.prodigy.com [192.168.254.43]) by pimaia2w.prodigy.com (8.8.5/8.8.5) with ESMTP id RAA24264; Wed, 7 Jan 1998 17:13:25 -0500 Received: (from root@localhost) by mime4.prodigy.com (8.6.10/8.6.9) id RAA07980; Wed, 7 Jan 1998 17:07:18 -0500 Message-Id: <199801072207.RAA07980@mime4.prodigy.com> X-Mailer: Prodigy Internet GW(v0.9beta) - ae01dm04sc03 From: CEBA78B@prodigy.com ( JUDY A KELLER) Date: Wed, 7 Jan 1998 17:07:18, -0500 To: applmib-request@emi-summit.com, hubmib@hprnd.rose.hp.com, ieeetcpc@ccvm.sunysb.edu, ietf-madman@innosoft.com, ietf@ns.ietf.org, ifip-emilmgt@ics.uci.edu, ISODE-SNMPv2@ida.liu.se, members@nmf.org, ovforum@andrew.cmu.edu, rmonmib@cisco.com, snmp2@tis.com, snmp@psi.com, snmpv3@tis.com Cc: j.keller@comsoc.org, g.weisman@comsoc.org Subject: NOMS '98 REGISTRATION Not yet Registered for NOMS'98? It is not too late but time is running out to attend IEEE/IFIP 1998 Network Operations and Management Symposium in New Orleans, Louisiana, USA, 15-20 February, 1998. We think that this will be your best opportunity in 1998 to examine the latest practical solutions and visionary ideas across all types of networks, products, technologies (SONET/SDH, ATM, Wireless), enterprise communications systems, distributed computing systems, and applications. See if you agree. Check our www site: http://www.comsoc. org/confs/noms/98 You'll also find scheduled exhibits, and on-line inquiry and registration forms on the site. But don't delay. Hotels will be jammed because of Mardi Gras celebrations. You should book your room by January 16 or you will pay far more -- if you can find space at all. Veli Sahin, General Chair P.S. My apologies if you have received more than one of these messages From adm Wed Jan 7 17:20:38 1998 Delivery-Date: Wed, 07 Jan 1998 17:27:15 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id RAA06975 for ietf-outbound.10@ietf.org; Wed, 7 Jan 1998 17:20:02 -0500 (EST) Received: from pimaia2w.prodigy.com (pimaia2w.prodigy.com [198.83.19.115]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA06902 for ; Wed, 7 Jan 1998 17:15:16 -0500 (EST) Received: from mime4.prodigy.com (mime4.prodigy.com [192.168.254.43]) by pimaia2w.prodigy.com (8.8.5/8.8.5) with ESMTP id RAA24264; Wed, 7 Jan 1998 17:13:25 -0500 Received: (from root@localhost) by mime4.prodigy.com (8.6.10/8.6.9) id RAA07980; Wed, 7 Jan 1998 17:07:18 -0500 Message-Id: <199801072207.RAA07980@mime4.prodigy.com> X-Mailer: Prodigy Internet GW(v0.9beta) - ae01dm04sc03 From: CEBA78B@prodigy.com ( JUDY A KELLER) Date: Wed, 7 Jan 1998 17:07:18, -0500 To: applmib-request@emi-summit.com, hubmib@hprnd.rose.hp.com, ieeetcpc@ccvm.sunysb.edu, ietf-madman@innosoft.com, ietf@ns.ietf.org, ifip-emilmgt@ics.uci.edu, ISODE-SNMPv2@ida.liu.se, members@nmf.org, ovforum@andrew.cmu.edu, rmonmib@cisco.com, snmp2@tis.com, snmp@psi.com, snmpv3@tis.com cc: j.keller@comsoc.org, g.weisman@comsoc.org Subject: NOMS '98 REGISTRATION Not yet Registered for NOMS'98? It is not too late but time is running out to attend IEEE/IFIP 1998 Network Operations and Management Symposium in New Orleans, Louisiana, USA, 15-20 February, 1998. We think that this will be your best opportunity in 1998 to examine the latest practical solutions and visionary ideas across all types of networks, products, technologies (SONET/SDH, ATM, Wireless), enterprise communications systems, distributed computing systems, and applications. See if you agree. Check our www site: http://www.comsoc. org/confs/noms/98 You'll also find scheduled exhibits, and on-line inquiry and registration forms on the site. But don't delay. Hotels will be jammed because of Mardi Gras celebrations. You should book your room by January 16 or you will pay far more -- if you can find space at all. Veli Sahin, General Chair P.S. My apologies if you have received more than one of these messages From rmorgan@tonex.com Mon Jan 12 21:24:52 1998 Delivery-Date: Mon, 12 Jan 1998 21:24:53 -0500 Return-Path: rmorgan@tonex.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA24231 for ; Mon, 12 Jan 1998 21:24:51 -0500 (EST) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA04992 for ; Mon, 12 Jan 1998 21:27:37 -0500 (EST) Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id SAA04565; Mon, 12 Jan 1998 18:16:03 -0800 (PST) Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.20/15.5+ECS 3.3) id AA213147677; Mon, 12 Jan 1998 18:14:37 -0800 Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by hp.com (8.8.5/8.8.5tis) with ESMTP id SAA22046 for ; Mon, 12 Jan 1998 18:14:35 -0800 (PST) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id UAA03176; Mon, 12 Jan 1998 20:07:12 -0600 (CST) Received: from whx-ca2-06.ix.netcom.com(204.31.115.70) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma003159; Mon Jan 12 20:06:43 1998 Message-Id: <34BACB93.7317@tonex.com> Date: Mon, 12 Jan 1998 18:04:03 -0800 From: Kathy Franklin Reply-To: kfranklin@tonex.com Organization: TONEX Texhnologies, Inc. X-Mailer: Mozilla 3.0C-NC320 (Win95; U) Mime-Version: 1.0 To: snmp2@tis.com Cc: snmp@psi.com, snmpv3@tis.com, rmonmib@cisco.com, ISODE-SNMPv2@ida.liu.se, hubmib@hprnd.rose.hp.com Subject: Global TMN/OSI Training and Workshop Schedule, 1998 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Telecom Industry Leaders, Attached is the new schedule of the upcoming TMN training classes as you requested. You can access this information on-line on the web "http://www.tonex.com/seminars.com". If you have any further questions, please feel free to contact me. Best Regards, Ryan Morgan mailto:rmorgan@tonex.com or tmn-workshop@tonex.com ------------------------------- Technology Overview Course: TMN (Telecommunications Management Network) Techniques, Architecture, Implementations and Migration, Level I Dallas, Texas, January 26-30, 1998 Montreal, Canada, February 2-6, 1998 Ottawa, Canada, March 9-13, 1998 New Jersey, March 16-20, 1998 Kawasaki, Japan, March 23-27, 1998 Tokyo, Japan, March 30-April 3, 1998 Paris, France, April 6-10, 1998 Seoul, Korea, April 27-May 1, 1998 Denver, Colorado, May 4-8, 1998 Washington D.C, May 11-15, 1998 Chicago, Illinois, May 18-22, 1998 Seattle, Washington, May 25-29, 1998 Singapore, June 1-5, 1998 Toronto, Canada, June 15-19, 1998 Topic this course will cover Introduction to Service and Network and Service Management principles, and techniques Introduction to TMN principles, layers, interfaces, techniques, and benefits Introduction to OSI principles, techniques, benefits Introduction to OSI System Management Communications: CMIS/CMIP Introduction to Network Operations and OAM&P Introduction to Q3 Interface Introduction to TMN Physical Architecture Introduction to TMN Functional Architecture Introduction to TMN Information Architecture Understanding of the more common terms and concepts associated with communications protocols Introduction to CMIS/CMIP/ROSE Understanding of the more common terms and concepts associated with MIB Introduction to GDMO Introduction to ASN.1 Introduction to SONET/ATM/GR-303 Information Models (GDMO/ASN.1) An overview of the international standard bodies involved in the TMN effort An overview of the technique, tools, products associated with TMN network and service management development effort An overview of TMN migration issues An overview of next generation TMN and CORBA compliant Operation Support Systems An overview of TMN and CORBA integration An introduction to TMN market opportunities and market leaders An overview of the TMN vendors Associated Workshops -GDMO Workshop: Working with GDMO Templates -ASN.1 Workshop: Working with ASN.1 Syntax -CMISE/CMIP Workshop: OSI/CMISE/CMIP/ROSE Overview -CORBA Workshop -TMN and CORBA Integration Workshop -Java for Telecom Management Workshop ---------------------------------------------------------- IMPLEMENTATION COURSE: TMN Implementation and Deployment , Level II (working with the TMN tools and platforms) Dallas, Texas, February 23-26, 1998 Kawasaki, Japan, March 30-April 2, 1998 Tokyo, Japan, April 6-9, 1998 Paris, France, April 13-17, 1998 Seoul, Korea, May 4-7, 1998 Denver, Colorado, May 11-14, 1998 Washington D.C, May 18-21, 1998 Chicago, Illinois, May 25-28, 1998 Seattle, Washington, June 1-4, 1998 Singapore, June 15-18, 1998 Toronto, Canada, June 22-25, 1998 Montreal, Canada, June 29-July 2, 1998 Ottawa, Canada, July 6-9, 1998 From list-owner-rmonmib-outgoing@cisco.com Mon Jan 12 21:31:37 1998 Delivery-Date: Mon, 12 Jan 1998 21:31:37 -0500 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA24270 for ; Mon, 12 Jan 1998 21:31:36 -0500 (EST) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05009 for ; Mon, 12 Jan 1998 21:34:22 -0500 (EST) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id SAA27195 for Rmonmib-outgoing; Mon, 12 Jan 1998 18:18:18 -0800 (PST) Received: from mailgate-rtp-1.cisco.com (mailgate-rtp-1.cisco.com [171.69.160.46]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id SAA27190 for ; Mon, 12 Jan 1998 18:18:14 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by mailgate-rtp-1.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id VAA02675 for ; Mon, 12 Jan 1998 21:18:12 -0500 (EST) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id SAA25388 for ; Mon, 12 Jan 1998 18:07:29 -0800 (PST) Received: from dfw-ix11.ix.netcom.com(206.214.98.11) by proxy3.cisco.com via smap (V2.0) id xma025367; Tue, 13 Jan 98 02:07:23 GMT Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id UAA03176; Mon, 12 Jan 1998 20:07:12 -0600 (CST) Received: from whx-ca2-06.ix.netcom.com(204.31.115.70) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma003159; Mon Jan 12 20:06:43 1998 Message-ID: <34BACB93.7317@tonex.com> Date: Mon, 12 Jan 1998 18:04:03 -0800 From: Kathy Franklin Reply-To: kfranklin@tonex.com Organization: TONEX Texhnologies, Inc. X-Mailer: Mozilla 3.0C-NC320 (Win95; U) MIME-Version: 1.0 To: snmp2@tis.com CC: snmp@psi.com, snmpv3@tis.com, rmonmib@cisco.com, ISODE-SNMPv2@ida.liu.se, hubmib@hprnd.rose.hp.com Subject: Global TMN/OSI Training and Workshop Schedule, 1998 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Dear Telecom Industry Leaders, Attached is the new schedule of the upcoming TMN training classes as you requested. You can access this information on-line on the web "http://www.tonex.com/seminars.com". If you have any further questions, please feel free to contact me. Best Regards, Ryan Morgan mailto:rmorgan@tonex.com or tmn-workshop@tonex.com ------------------------------- Technology Overview Course: TMN (Telecommunications Management Network) Techniques, Architecture, Implementations and Migration, Level I Dallas, Texas, January 26-30, 1998 Montreal, Canada, February 2-6, 1998 Ottawa, Canada, March 9-13, 1998 New Jersey, March 16-20, 1998 Kawasaki, Japan, March 23-27, 1998 Tokyo, Japan, March 30-April 3, 1998 Paris, France, April 6-10, 1998 Seoul, Korea, April 27-May 1, 1998 Denver, Colorado, May 4-8, 1998 Washington D.C, May 11-15, 1998 Chicago, Illinois, May 18-22, 1998 Seattle, Washington, May 25-29, 1998 Singapore, June 1-5, 1998 Toronto, Canada, June 15-19, 1998 Topic this course will cover Introduction to Service and Network and Service Management principles, and techniques Introduction to TMN principles, layers, interfaces, techniques, and benefits Introduction to OSI principles, techniques, benefits Introduction to OSI System Management Communications: CMIS/CMIP Introduction to Network Operations and OAM&P Introduction to Q3 Interface Introduction to TMN Physical Architecture Introduction to TMN Functional Architecture Introduction to TMN Information Architecture Understanding of the more common terms and concepts associated with communications protocols Introduction to CMIS/CMIP/ROSE Understanding of the more common terms and concepts associated with MIB Introduction to GDMO Introduction to ASN.1 Introduction to SONET/ATM/GR-303 Information Models (GDMO/ASN.1) An overview of the international standard bodies involved in the TMN effort An overview of the technique, tools, products associated with TMN network and service management development effort An overview of TMN migration issues An overview of next generation TMN and CORBA compliant Operation Support Systems An overview of TMN and CORBA integration An introduction to TMN market opportunities and market leaders An overview of the TMN vendors Associated Workshops -GDMO Workshop: Working with GDMO Templates -ASN.1 Workshop: Working with ASN.1 Syntax -CMISE/CMIP Workshop: OSI/CMISE/CMIP/ROSE Overview -CORBA Workshop -TMN and CORBA Integration Workshop -Java for Telecom Management Workshop ---------------------------------------------------------- IMPLEMENTATION COURSE: TMN Implementation and Deployment , Level II (working with the TMN tools and platforms) Dallas, Texas, February 23-26, 1998 Kawasaki, Japan, March 30-April 2, 1998 Tokyo, Japan, April 6-9, 1998 Paris, France, April 13-17, 1998 Seoul, Korea, May 4-7, 1998 Denver, Colorado, May 11-14, 1998 Washington D.C, May 18-21, 1998 Chicago, Illinois, May 25-28, 1998 Seattle, Washington, June 1-4, 1998 Singapore, June 15-18, 1998 Toronto, Canada, June 22-25, 1998 Montreal, Canada, June 29-July 2, 1998 Ottawa, Canada, July 6-9, 1998 From adm Wed Jan 14 11:20:17 1998 Delivery-Date: Wed, 14 Jan 1998 11:24:38 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA29551 for ietf-outbound.10@ietf.org; Wed, 14 Jan 1998 11:20:03 -0500 (EST) Received: from dfw-ix9.ix.netcom.com (dfw-ix9.ix.netcom.com [206.214.98.9]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA29368 for ; Wed, 14 Jan 1998 11:16:10 -0500 (EST) Received: (from smap@localhost) by dfw-ix9.ix.netcom.com (8.8.4/8.8.4) id KAA11623; Wed, 14 Jan 1998 10:14:49 -0600 (CST) Received: from whx-ca7-15.ix.netcom.com(205.187.202.47) by dfw-ix9.ix.netcom.com via smap (V1.3) id rma011594; Wed Jan 14 10:14:16 1998 Message-ID: <34BCE3C5.2B65@tonex.com> Date: Wed, 14 Jan 1998 08:11:49 -0800 From: Charles Alexi Reply-To: claexi@tonex.com Organization: TONEX Technologies, Inc. X-Mailer: Mozilla 3.0C-NC320 (Win95; U) MIME-Version: 1.0 To: ieeetcpc@ccvm.sunysb.edu, ietf-madman@innosoft.com, ietf@ns.ietf.org, ifip-emilmgt@ics.uci.edu CC: applmib-request@emi-summit.com, snmp@psi.com, snmpv3@tis.com, rmonmib@cisco.com, ISODE-SNMPv2@ida.liu.se, hubmib@hprnd.rose.hp.com, snmp2@tis.com Subject: Sorry, Sorry, Sorry! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am very sorry for the previous commercial email sent to IETF mailing lists by mistake. I was trying to get the information to some other telecom groups by their requests (not anyone from IETF for sure). Best Regards, Ryan From list-owner-rmonmib-outgoing@cisco.com Wed Jan 14 11:37:08 1998 Delivery-Date: Wed, 14 Jan 1998 11:37:08 -0500 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA00266 for ; Wed, 14 Jan 1998 11:36:59 -0500 (EST) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA10765 for ; Wed, 14 Jan 1998 11:39:46 -0500 (EST) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id IAA13359 for Rmonmib-outgoing; Wed, 14 Jan 1998 08:17:43 -0800 (PST) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id IAA13349 for ; Wed, 14 Jan 1998 08:17:23 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id IAA11959 for ; Wed, 14 Jan 1998 08:17:21 -0800 (PST) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id IAA17477 for ; Wed, 14 Jan 1998 08:17:20 -0800 (PST) Received: from dfw-ix9.ix.netcom.com(206.214.98.9) by proxy2.cisco.com via smap (V2.0) id xma017449; Wed, 14 Jan 98 16:17:15 GMT Received: (from smap@localhost) by dfw-ix9.ix.netcom.com (8.8.4/8.8.4) id KAA11623; Wed, 14 Jan 1998 10:14:49 -0600 (CST) Received: from whx-ca7-15.ix.netcom.com(205.187.202.47) by dfw-ix9.ix.netcom.com via smap (V1.3) id rma011594; Wed Jan 14 10:14:16 1998 Message-ID: <34BCE3C5.2B65@tonex.com> Date: Wed, 14 Jan 1998 08:11:49 -0800 From: Charles Alexi Reply-To: claexi@tonex.com Organization: TONEX Technologies, Inc. X-Mailer: Mozilla 3.0C-NC320 (Win95; U) MIME-Version: 1.0 To: ieeetcpc@ccvm.sunysb.edu, ietf-madman@innosoft.com, ietf@ns.ietf.org, ifip-emilmgt@ics.uci.edu CC: applmib-request@emi-summit.com, snmp@psi.com, snmpv3@tis.com, rmonmib@cisco.com, ISODE-SNMPv2@ida.liu.se, hubmib@hprnd.rose.hp.com, snmp2@tis.com Subject: Sorry, Sorry, Sorry! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk I am very sorry for the previous commercial email sent to IETF mailing lists by mistake. I was trying to get the information to some other telecom groups by their requests (not anyone from IETF for sure). Best Regards, Ryan From rmorgan@tonex.com Wed Jan 14 11:42:05 1998 Delivery-Date: Wed, 14 Jan 1998 11:42:18 -0500 Return-Path: rmorgan@tonex.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA00414 for ; Wed, 14 Jan 1998 11:42:05 -0500 (EST) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA10822 for ; Wed, 14 Jan 1998 11:44:52 -0500 (EST) Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id IAA19694; Wed, 14 Jan 1998 08:25:44 -0800 (PST) Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.20/15.5+ECS 3.3) id AA014105081; Wed, 14 Jan 1998 08:24:41 -0800 Received: from dfw-ix9.ix.netcom.com (dfw-ix9.ix.netcom.com [206.214.98.9]) by hp.com (8.8.5/8.8.5tis) with ESMTP id IAA00127 for ; Wed, 14 Jan 1998 08:24:39 -0800 (PST) Received: (from smap@localhost) by dfw-ix9.ix.netcom.com (8.8.4/8.8.4) id KAA11623; Wed, 14 Jan 1998 10:14:49 -0600 (CST) Received: from whx-ca7-15.ix.netcom.com(205.187.202.47) by dfw-ix9.ix.netcom.com via smap (V1.3) id rma011594; Wed Jan 14 10:14:16 1998 Message-Id: <34BCE3C5.2B65@tonex.com> Date: Wed, 14 Jan 1998 08:11:49 -0800 From: Charles Alexi Reply-To: claexi@tonex.com Organization: TONEX Technologies, Inc. X-Mailer: Mozilla 3.0C-NC320 (Win95; U) Mime-Version: 1.0 To: ieeetcpc@ccvm.sunysb.edu, ietf-madman@innosoft.com, ietf@ns.ietf.org, ifip-emilmgt@ics.uci.edu Cc: applmib-request@emi-summit.com, snmp@psi.com, snmpv3@tis.com, rmonmib@cisco.com, ISODE-SNMPv2@ida.liu.se, hubmib@hprnd.rose.hp.com, snmp2@tis.com Subject: Sorry, Sorry, Sorry! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am very sorry for the previous commercial email sent to IETF mailing lists by mistake. I was trying to get the information to some other telecom groups by their requests (not anyone from IETF for sure). Best Regards, Ryan From list-owner-rmonmib-outgoing@cisco.com Wed Jan 14 21:54:44 1998 Delivery-Date: Wed, 14 Jan 1998 21:54:44 -0500 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA12479 for ; Wed, 14 Jan 1998 21:54:43 -0500 (EST) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA13045 for ; Wed, 14 Jan 1998 21:57:27 -0500 (EST) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id SAA19999 for Rmonmib-outgoing; Wed, 14 Jan 1998 18:48:15 -0800 (PST) Received: from beasley.cisco.com (mailgate-sj-2.cisco.com [171.69.2.135]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id SAA19990 for ; Wed, 14 Jan 1998 18:48:09 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id SAA15339 for ; Wed, 14 Jan 1998 18:48:08 -0800 (PST) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id SAA05619 for ; Wed, 14 Jan 1998 18:48:08 -0800 (PST) Received: from atlas.xylogics.com(132.245.33.7) by proxy1.cisco.com via smap (V2.0) id xma005613; Thu, 15 Jan 98 02:48:04 GMT Received: from usa.net (honeydew.xylogics.com [132.245.32.100]) by atlas.xylogics.com (8.7.3/8.7.3) with ESMTP id VAA27981; Wed, 14 Jan 1998 21:45:03 -0500 (EST) Message-ID: <34BD782D.C553F521@usa.net> Date: Wed, 14 Jan 1998 21:45:01 -0500 From: Vijay Venkatesh Organization: C y B e R h U b Inc . X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: claexi@tonex.com CC: ieeetcpc@ccvm.sunysb.edu, ietf-madman@INNOSOFT.COM, ietf@ns.ietf.org, ifip-emilmgt@ics.uci.edu, applmib-request@emi-summit.com, snmp@psi.com, snmpv3@tis.com, rmonmib@cisco.com, ISODE-SNMPv2@ida.liu.se, hubmib@hprnd.rose.hp.com, snmp2@tis.com Subject: Re: Sorry, Sorry, Sorry! References: <34BCE3C5.2B65@tonex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Relax ... nobody died here. Peace. -Vijay Charles Alexi wrote: > > I am very sorry for the previous commercial email sent to IETF mailing > lists by mistake. I was trying to get the information to some other > telecom groups by their requests (not anyone from IETF for sure). > > Best Regards, > Ryan From adm Wed Jan 14 21:50:37 1998 Delivery-Date: Wed, 14 Jan 1998 21:56:57 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id VAA12310 for ietf-outbound.10@ietf.org; Wed, 14 Jan 1998 21:50:02 -0500 (EST) Received: from atlas.xylogics.com (atlas.xylogics.com [132.245.33.7]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA12232 for ; Wed, 14 Jan 1998 21:46:32 -0500 (EST) Received: from usa.net (honeydew.xylogics.com [132.245.32.100]) by atlas.xylogics.com (8.7.3/8.7.3) with ESMTP id VAA27981; Wed, 14 Jan 1998 21:45:03 -0500 (EST) Sender: vvijay@xylogics.com Message-ID: <34BD782D.C553F521@usa.net> Date: Wed, 14 Jan 1998 21:45:01 -0500 From: Vijay Venkatesh Organization: C y B e R h U b Inc . X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: claexi@tonex.com CC: ieeetcpc@ccvm.sunysb.edu, ietf-madman@INNOSOFT.COM, ietf@ns.ietf.org, ifip-emilmgt@ics.uci.edu, applmib-request@emi-summit.com, snmp@psi.com, snmpv3@tis.com, rmonmib@cisco.com, ISODE-SNMPv2@ida.liu.se, hubmib@hprnd.rose.hp.com, snmp2@tis.com Subject: Re: Sorry, Sorry, Sorry! References: <34BCE3C5.2B65@tonex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Relax ... nobody died here. Peace. -Vijay Charles Alexi wrote: > > I am very sorry for the previous commercial email sent to IETF mailing > lists by mistake. I was trying to get the information to some other > telecom groups by their requests (not anyone from IETF for sure). > > Best Regards, > Ryan From vijay.venkatesh@usa.net Wed Jan 14 21:59:24 1998 Delivery-Date: Wed, 14 Jan 1998 21:59:25 -0500 Return-Path: vijay.venkatesh@usa.net Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA12591 for ; Wed, 14 Jan 1998 21:59:24 -0500 (EST) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA13060 for ; Wed, 14 Jan 1998 22:02:11 -0500 (EST) Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id SAA11463; Wed, 14 Jan 1998 18:54:54 -0800 (PST) Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.20/15.5+ECS 3.3) id AA083642673; Wed, 14 Jan 1998 18:51:13 -0800 Received: from atlas.xylogics.com (atlas.xylogics.com [132.245.33.7]) by hp.com (8.8.5/8.8.5tis) with ESMTP id SAA08708 for ; Wed, 14 Jan 1998 18:51:11 -0800 (PST) Received: from usa.net (honeydew.xylogics.com [132.245.32.100]) by atlas.xylogics.com (8.7.3/8.7.3) with ESMTP id VAA27981; Wed, 14 Jan 1998 21:45:03 -0500 (EST) Sender: vvijay@xylogics.com Message-Id: <34BD782D.C553F521@usa.net> Date: Wed, 14 Jan 1998 21:45:01 -0500 From: Vijay Venkatesh Organization: C y B e R h U b Inc . X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: claexi@tonex.com Cc: ieeetcpc@ccvm.sunysb.edu, ietf-madman@INNOSOFT.COM, ietf@ns.ietf.org, ifip-emilmgt@ics.uci.edu, applmib-request@emi-summit.com, snmp@psi.com, snmpv3@tis.com, rmonmib@cisco.com, ISODE-SNMPv2@ida.liu.se, hubmib@hprnd.rose.hp.com, snmp2@tis.com Subject: Re: Sorry, Sorry, Sorry! References: <34BCE3C5.2B65@tonex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Relax ... nobody died here. Peace. -Vijay Charles Alexi wrote: > > I am very sorry for the previous commercial email sent to IETF mailing > lists by mistake. I was trying to get the information to some other > telecom groups by their requests (not anyone from IETF for sure). > > Best Regards, > Ryan From owner-ion@sunroof.Eng.Sun.COM Fri Jan 23 16:44:18 1998 Delivery-Date: Fri, 23 Jan 1998 16:44:19 -0500 Return-Path: owner-ion@sunroof.Eng.Sun.COM Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id QAA05569 for ; Fri, 23 Jan 1998 16:44:18 -0500 (EST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA26194; Fri, 23 Jan 1998 13:32:12 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id NAA25677; Fri, 23 Jan 1998 13:32:09 -0800 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA10627 for ion-dist; Fri, 23 Jan 1998 13:26:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA10620 for ; Fri, 23 Jan 1998 13:26:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA24410 for ; Fri, 23 Jan 1998 13:26:45 -0800 Received: from kentrox.com (kentrox.kentrox.com [192.228.59.2]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA13267 for ; Fri, 23 Jan 1998 13:27:27 -0800 (PST) Received: from UNKNOWN(192.228.37.107), claiming to be "kentrox.com" via SMTP by kentrox.kentrox.com, id smtpdAAAa12019; Fri Jan 23 21:26:29 1998 Received: from localhost by kentrox.com (4.1/SMI-4.1_KTX1.1) id AA00445; Fri, 23 Jan 98 13:26:19 PST Date: Fri, 23 Jan 1998 13:26:19 -0800 (PST) From: Gary Hanson X-Sender: gary@skeeter To: snmpv3@tis.com Cc: ion@sunroof.Eng.Sun.COM, st-editorial@simple-times.org Subject: (ION) Putting NOTIFICATION-TYPEs in their place Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ion@sunroof.Eng.Sun.COM Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Hypermail archive at http://netlab.ucs.indiana.edu/hypermail/ion/ Hi folks, A close reading of section 8.5 of RFC 1902 and the referenced section 3.1.2 of RFC 1908 indicates that if a notification is NOT carefully placed in the OID hierarchy (i.e., if the next to last sub-identifier in the name of the notification does NOT have the value zero) then compatibility problems can result between SNMPv1 and SNMPv2 entities that use the notification. How serious is this problem in actuality? Would somebody explain the specific scenario that wouldn't work as we would expect if we were to define, for example, "fooEvent" as "{ fooMIB(1) fooNotifications(1) 1 }" instead of as "{ fooMIB(1) fooNotifications(1) fooTrapPrefix(0) 1 }". (I think this would probably be a good item for The Simple Times FAQ, so I copied the editors there, too. Perhaps it is already answered in one of the back issues....) I see a number of standards track MIBs that faithfully follow this prescription of using a zero value in the next to last sub-identifier: - ENTITY-MIB (RFC 2037) - ISDN-MIB (RFC 2127) - DIAL-CONTROL-MIB (RFC 2128) - RSVP-MIB (RFC 2206) - ATM2-MIB (draft-ietf-atommib-atm2-11.txt) - DS1-MIB (draft-ietf-trunkmib-ds1-mib-06.txt) - DS3-MIB (draft-ietf-trunkmib-ds3-mib-05.txt) - EVENT-MIB (draft-ietf-disman-event-mib-02.txt) - IPV6-MIB (draft-ietf-ipngwg-ipv6-mib-03.txt) - NOTIFICATION-MIB (draft-ietf-disman-notify-mib-01.txt) - PTOPO-MIB (draft-ietf-ptopomib-mib-01.txt) - SLP-MIB (draft-ietf-svrloc-slp-mib-00.txt) - TEST-MIB (draft-ietf-ifmib-testmib-03.txt) However, I sometimes see standards track MIB internet-drafts that do NOT follow this prescription, and I am just wondering what their fates will be if they are not nudged into compliance in this area. Some examples from the internet-drafts created by the ion WG: - IPATM-IPMC-MIB (draft-ietf-ion-mars-mib-04.txt) - IPOA-MIB (will be fixed in draft-ietf-ion-mib-06.txt) - SCHEDULE-MIB (draft-ietf-disman-schedule-mib-00.txt) - SCSP-MIB (draft-want-ion-scsp-mib-00.txt) Note that the SLP-MIB defines its NOTIFICATION-TYPE under an overlying NOTIFICATION-GROUP, which I don't think was intended, and I am not sure if it is kosher, either, although it does use the zero value prefix. I cross-posted this to the ion WG because of the exposure in that WG. I would not be surprised if there are other MIBs under development in other WGs that may need similar attention. Regards, Gary ______ | /// | TM Gary Hanson gary@kentrox.com | ADC|Kentrox 14375 NW Science Park Dr. 503-641-3321 (FAX) |______| Portland, Oregon 97229 800-733-5511 x6333 X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.Eng.Sun.COM Mon Jan 26 13:50:42 1998 Delivery-Date: Mon, 26 Jan 1998 13:50:47 -0500 Return-Path: owner-ion@sunroof.Eng.Sun.COM Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id NAA17573 for ; Mon, 26 Jan 1998 13:50:41 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA08448; Mon, 26 Jan 1998 10:45:35 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id KAA24266; Mon, 26 Jan 1998 10:45:33 -0800 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA12591 for ion-dist; Mon, 26 Jan 1998 10:40:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA12584 for ; Mon, 26 Jan 1998 10:40:04 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA26087 for ; Mon, 26 Jan 1998 10:40:01 -0800 Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA22771 for ; Mon, 26 Jan 1998 10:39:29 -0800 (PST) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id NAA09164 for ; Mon, 26 Jan 1998 13:34:59 -0500 Received: from spice.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id NAA19225; Mon, 26 Jan 1998 13:37:31 -0500 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id NAA00608; Mon, 26 Jan 1998 13:37:30 -0500 X-Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA12263 for ; Mon, 26 Jan 1998 05:46:45 -0800 (PST) X-Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA19268 for ; Mon, 26 Jan 1998 05:46:38 -0800 X-Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA00575 for ; Mon, 26 Jan 1998 05:47:14 -0800 (PST) X-Received: from molinari.ibr.cs.tu-bs.de (molinari [134.169.34.163]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id OAA11327; Mon, 26 Jan 1998 14:46:08 +0100 (MET) X-Received: from schoenw@localhost by molinari.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA11674; Mon, 26 Jan 1998 14:45:59 +0100 Date: Mon, 26 Jan 1998 14:45:59 +0100 Message-Id: <199801261345.OAA11674@molinari.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: gary@kentrox.com CC: snmpv3@tis.com, ion@sunroof.Eng.Sun.COM, st-editorial@simple-times.org In-reply-to: (message from Gary Hanson on Fri, 23 Jan 1998 13:26:19 -0800 (PST)) Subject: (ION) Re: Putting NOTIFICATION-TYPEs in their place References: Sender: owner-ion@sunroof.Eng.Sun.COM Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Hypermail archive at http://netlab.ucs.indiana.edu/hypermail/ion/ >>>>> Gary Hanson writes: Gary> A close reading of section 8.5 of RFC 1902 and the referenced Gary> section 3.1.2 of RFC 1908 indicates that if a notification is Gary> NOT carefully placed in the OID hierarchy (i.e., if the next to Gary> last sub-identifier in the name of the notification does NOT Gary> have the value zero) then compatibility problems can result Gary> between SNMPv1 and SNMPv2 entities that use the notification. Gary> How serious is this problem in actuality? Would somebody Gary> explain the specific scenario that wouldn't work as we would Gary> expect if we were to define, for example, "fooEvent" as " Gary> { fooMIB(1) fooNotifications(1) 1 }" instead of as "{ fooMIB(1) Gary> fooNotifications(1) fooTrapPrefix(0) 1 }". The most convincing reason for me why the 0 sub-identifer should be there are proxies converting SNMPv1 traps into SNMPv2 traps without MIB knowledge. Take an SMIv2 MIB, convert it to SMIv1 and implement it in an SNMPv1 agent. Now, your SNMPv1 agent sends a trap and a proxy converts this trap into a SNMPv2 trap. You only get the notification OID back if the registration has a 0 sub-identifer as the next to last subidentifier. Gary> I see a number of standards track MIBs that faithfully follow Gary> this prescription of using a zero value in the next to last Gary> sub-identifier: [snip] Gary> However, I sometimes see standards track MIB internet-drafts Gary> that do NOT follow this prescription, and I am just wondering Gary> what their fates will be if they are not nudged into compliance Gary> in this area. I think that internet-drafts not following this prescription should be fixed before they get published as RFCs. (I can assure you that the next version of the SCHEDULE-MIB contains this change.) Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From adm Wed Jan 28 11:17:29 1998 Delivery-Date: Wed, 28 Jan 1998 11:27:36 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA02468 for ietf-123-outbound.10@ietf.org; Wed, 28 Jan 1998 11:17:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29757; Wed, 28 Jan 1998 10:13:27 -0500 (EST) Message-Id: <199801281513.KAA29757@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: snmpv3@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-usm-v2-00.txt Date: Wed, 28 Jan 1998 10:13:27 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New 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) : B. Wijnen, U. Blumenthal Filename : draft-ietf-snmpv3-usm-v2-00.txt Pages : 78 Date : 27-Jan-98 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 with 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-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-usm-v2-00.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-v2-00.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: <19980127114002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-usm-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-usm-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980127114002.I-D@ietf.org> --OtherAccess-- --NextPart-- From list-owner-rmonmib-outgoing@cisco.com Tue Jun 16 21:14:28 1998 Delivery-Date: Tue, 16 Jun 1998 21:14:28 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA02191 for ; Tue, 16 Jun 1998 21:14:27 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA11794 for ; Tue, 16 Jun 1998 21:16:49 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id RAA12504 for Rmonmib-outgoing; Tue, 16 Jun 1998 17:54:03 -0700 (PDT) Received: from mailgate-rtp-1.cisco.com (mailgate-rtp-1.cisco.com [171.69.160.46]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id RAA12495 for ; Tue, 16 Jun 1998 17:53:51 -0700 (PDT) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by mailgate-rtp-1.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id UAA18452 for ; Tue, 16 Jun 1998 20:53:48 -0400 (EDT) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id RAA04716 for ; Tue, 16 Jun 1998 17:53:47 -0700 (PDT) Received: from shell16.ba.best.com(206.184.139.148) by proxy2.cisco.com via smap (V2.0) id xma004712; Wed, 17 Jun 98 00:53:46 GMT X-SMAP-Received-From: outside Received: from localhost (heard@localhost) by shell16.ba.best.com (8.8.8/8.8.BEST) with SMTP id RAA03205; Tue, 16 Jun 1998 17:53:37 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Tue, 16 Jun 1998 17:53:37 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: Harald Tveit Alvestrand cc: snmpv3@tis.com, rmonmib@cisco.com Subject: Re: An action plan for pushing the SMI to Standard In-Reply-To: <3.0.2.32.19980616090411.00c95280@dokka.maxware.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmonmib@cisco.com Precedence: bulk On Tue, 16 Jun 1998, Harald Tveit Alvestrand wrote: > The SNMP community has expressed a need to see the Structure of Management > Information (v2), RFCs 1902, 1903 and 1904, advance to Standard status. > > A number of hopefully minor issues have been raised related to these > documents; it is clear that some work, hopefully just clarifications, is > needed before we can advance the documents. > > In order to get this work done rapidly and throughly, the O&M ADs have > asked a small team to work out proposed new documents, well in advance > of the August IETF, that can be reviewed there and hopefully advanced > to Standard in a reasonably short time. > > [ ...] > > This work is NOT about adding new functionality [ ... ] In the RMONMIB WG Minutes for IETF #40 (Sun, 4 Jan 1998, from Andy Bierman) I notice this: > 2.2) Gauge64 vs. Counter64 > > The RMON MIBs define some TCs: > ZeroBasedCounter32 (based on Gauge32, defined in RMON-2) > ZeroBasedCounter64 (based on Counter64, defined in HC-RMON) > ZeroBasedGauge64 (based on Counter64, defined in HC-RMON) > > The use of Counter64 for the base type is not correct. > The correct approach for the HC-RMON MIB is to add an > unsigned 64-bit data type to the SNMP SMI. This issue has > been deferred to the SNMPv3 WG. I gather, on the basis of the words "this work is NOT about adding new functionality" that this issue (and others like it) will NOT be addressed by the SMI team. Is this inference correct? Thanks, Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com From list-owner-rmonmib-outgoing@cisco.com Wed Jun 17 03:00:22 1998 Delivery-Date: Wed, 17 Jun 1998 03:00:22 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA14302 for ; Wed, 17 Jun 1998 03:00:22 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA12581 for ; Wed, 17 Jun 1998 03:02:43 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id XAA18507 for Rmonmib-outgoing; Tue, 16 Jun 1998 23:50:48 -0700 (PDT) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id XAA18501 for ; Tue, 16 Jun 1998 23:50:44 -0700 (PDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id XAA28034 for ; Tue, 16 Jun 1998 23:50:42 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id XAA07078 for ; Tue, 16 Jun 1998 23:50:41 -0700 (PDT) Received: from dokka.maxware.no(195.139.236.69) by proxy1.cisco.com via smap (V2.0) id xma007068; Wed, 17 Jun 98 06:50:35 GMT X-SMAP-Received-From: outside Received: from alden (alvestrand.kvatro.no [193.216.167.143]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id IAA25164; Wed, 17 Jun 1998 08:48:58 +0200 Message-Id: <3.0.2.32.19980617075957.01ef64a0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 17 Jun 1998 07:59:57 +0200 To: "C. M. Heard/VVNET, Inc." From: Harald Tveit Alvestrand Subject: Re: An action plan for pushing the SMI to Standard Cc: snmpv3@tis.com, rmonmib@cisco.com In-Reply-To: References: <3.0.2.32.19980616090411.00c95280@dokka.maxware.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmonmib@cisco.com Precedence: bulk At 17:53 16.06.98 -0700, C. M. Heard/VVNET, Inc. wrote: > >> 2.2) Gauge64 vs. Counter64 >> >> The RMON MIBs define some TCs: >> ZeroBasedCounter32 (based on Gauge32, defined in RMON-2) >> ZeroBasedCounter64 (based on Counter64, defined in HC-RMON) >> ZeroBasedGauge64 (based on Counter64, defined in HC-RMON) >> >> The use of Counter64 for the base type is not correct. >> The correct approach for the HC-RMON MIB is to add an >> unsigned 64-bit data type to the SNMP SMI. This issue has >> been deferred to the SNMPv3 WG. > >I gather, on the basis of the words "this work is NOT about adding >new functionality" that this issue (and others like it) will NOT >be addressed by the SMI team. Is this inference correct? > This inference - that the SMI team will not be adding new base types to the SMI - is correct. There is another, separate activity, that I believe Jurgen will spearhead, that will collect "useful TCs" that are not part of the current set and put them separately on the standards track. Whether this activity can add new base types is something we will have to discuss; I believe new base types are "controversial"..... Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From list-owner-rmonmib-outgoing@cisco.com Wed Jun 17 12:31:51 1998 Delivery-Date: Wed, 17 Jun 1998 12:31:51 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA20121 for ; Wed, 17 Jun 1998 12:31:50 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA14411 for ; Wed, 17 Jun 1998 12:34:13 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id JAA10550 for Rmonmib-outgoing; Wed, 17 Jun 1998 09:19:18 -0700 (PDT) Received: from beasley.cisco.com (mailgate-sj-2.cisco.com [171.69.2.135]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id JAA10542 for ; Wed, 17 Jun 1998 09:19:09 -0700 (PDT) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id JAA19902 for ; Wed, 17 Jun 1998 09:19:08 -0700 (PDT) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id JAA18025 for ; Wed, 17 Jun 1998 09:19:07 -0700 (PDT) Received: from palrel1.hp.com(156.153.255.242) by proxy2.cisco.com via smap (V2.0) id xma018010; Wed, 17 Jun 98 16:19:01 GMT X-SMAP-Received-From: outside Received: from nsmdserv.cnd.hp.com (daemon@nsmdserv.cnd.hp.com [15.2.104.118]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id JAA29259; Wed, 17 Jun 1998 09:18:59 -0700 (PDT) Received: from cnd.hp.com (nautique.cnd.hp.com) by nsmdserv.cnd.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA041830328; Wed, 17 Jun 1998 10:18:48 -0600 Message-Id: <3587EC70.E1094516@cnd.hp.com> Date: Wed, 17 Jun 1998 10:18:56 -0600 From: "Brian O'Keefe" Reply-To: bok@cnd.hp.com Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Harald Tveit Alvestrand Cc: "C. M. Heard/VVNET, Inc." , snmpv3@tis.com, rmonmib@cisco.com Subject: Re: An action plan for pushing the SMI to Standard References: <3.0.2.32.19980616090411.00c95280@dokka.maxware.no> <3.0.2.32.19980617075957.01ef64a0@dokka.maxware.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Harald Tveit Alvestrand wrote: > Whether this activity can add new base types is something we will > have to discuss; I believe new base types are "controversial"..... Understood. I'm fully supportive of every effort to advance the SMIv2 to full-standard. And while there are a number of "enhancements" that I'd like to propose for SMIv3 work, the one that is absolutely critical to get on the standards track ASAP is "Unsigned64". Whether this addition can be done without setting the entire v2 SMI (and protocol - rfc1905) back to proposed is beyond my ability to say. I do know that such an addition would require modification, albeit minor, to the manager-side SNMP API/stack that I work with in order for it to become fully supported in our code. None-the-less, we need to get this on the standard track in some form ASAP. With this new SMI base type defined, separate efforts can add TC variations to one's content. But without it, MIB designers will continue to kludge up work-arounds that just make life simply difficult in the end. bok PS - will the SMIv3 effort (and mailing list) be announced on the snmp or snmpv3 list? From list-owner-rmonmib-outgoing@cisco.com Wed Jun 17 13:47:22 1998 Delivery-Date: Wed, 17 Jun 1998 13:47:23 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA20712 for ; Wed, 17 Jun 1998 13:47:22 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14754 for ; Wed, 17 Jun 1998 13:49:44 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id KAA12191 for Rmonmib-outgoing; Wed, 17 Jun 1998 10:29:25 -0700 (PDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id KAA12186 for ; Wed, 17 Jun 1998 10:29:21 -0700 (PDT) Received: (kzm@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) id KAA18162; Wed, 17 Jun 1998 10:29:23 -0700 (PDT) From: Keith McCloghrie Message-Id: <199806171729.KAA18162@foxhound.cisco.com> Subject: Re: An action plan for pushing the SMI to Standard To: bok@cnd.hp.com Date: Wed, 17 Jun 1998 10:29:23 -0700 (PDT) Cc: Harald.Alvestrand@maxware.no, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com In-Reply-To: <3587EC70.E1094516@cnd.hp.com> from "Brian O'Keefe" at Jun 17, 98 10:18:56 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Brian, What MIB designers need, so they can avoid having "to kludge up work-arounds", to be able to write SYNTAX Unsigned64 Observe that they can do this irrespective of whether Unsigned64 is defined: a) as a base SMI type or b) as a TC. Where to IMPORT it from (an SMI or a TC MIB) is the *only* difference in the MIB between these alternatives. However, using a new SMI base type would generate an on-the-wire encoding which is currently illegal, i.e., it effectively creates a new SMI, requiring a much difficult transition strategy. On the other hand, using a TC requires no changes except in consenting method routines and NMS applications. So, if you want to be able to use this anytime soon, ... Keith. PS. The same argument is true for Gauge64. > Harald Tveit Alvestrand wrote: > > Whether this activity can add new base types is something we will > > have to discuss; I believe new base types are "controversial"..... > > Understood. I'm fully supportive of every effort to advance > the SMIv2 to full-standard. And while there are a number of > "enhancements" that I'd like to propose for SMIv3 work, the > one that is absolutely critical to get on the standards track > ASAP is "Unsigned64". Whether this addition can be done > without setting the entire v2 SMI (and protocol - rfc1905) > back to proposed is beyond my ability to say. I do know that > such an addition would require modification, albeit minor, to > the manager-side SNMP API/stack that I work with in order for > it to become fully supported in our code. > > None-the-less, we need to get this on the standard track in > some form ASAP. With this new SMI base type defined, separate > efforts can add TC variations to one's content. But without > it, MIB designers will continue to kludge up work-arounds that > just make life simply difficult in the end. > > bok > > PS - will the SMIv3 effort (and mailing list) be announced > on the snmp or snmpv3 list? > From list-owner-rmonmib-outgoing@cisco.com Wed Jun 17 14:57:13 1998 Delivery-Date: Wed, 17 Jun 1998 14:57:13 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA21322 for ; Wed, 17 Jun 1998 14:57:12 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA15108 for ; Wed, 17 Jun 1998 14:59:34 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id LAA14250 for Rmonmib-outgoing; Wed, 17 Jun 1998 11:34:19 -0700 (PDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id LAA14245 for ; Wed, 17 Jun 1998 11:34:15 -0700 (PDT) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id LAA17266; Wed, 17 Jun 1998 11:33:30 -0700 (PDT) Message-Id: <3.0.5.32.19980617143127.00866440@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 17 Jun 1998 14:31:27 -0400 To: Keith McCloghrie From: Bob Stewart Subject: Re: An action plan for pushing the SMI to Standard Cc: bok@cnd.hp.com, Harald.Alvestrand@maxware.no, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com In-Reply-To: <199806171729.KAA18162@foxhound.cisco.com> References: <3587EC70.E1094516@cnd.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmonmib@cisco.com Precedence: bulk At 10:29 AM 6/17/98 -0700, Keith McCloghrie wrote: >However, using a new SMI base type would generate an on-the-wire >encoding which is currently illegal, i.e., it effectively creates a new >SMI, requiring a much difficult transition strategy. On the other >hand, using a TC requires no changes except in consenting method >routines and NMS applications. So, if you want to be able to use this >anytime soon, ... I don't see why having a new tag is any more traumatic than special-casing an old one. If anything I'd think a new tag would be cleaner and easier to implement. Without a new tag smart, helpful, general-purpose applications will mishandle 64-bit integers or unsigned, thinking they're counters and require calculating a delta. In other words, special counter semantics go with the existing tag. To use it as a 64-bit unsigned integer violates that. With a new tag we maintain a consistent, protocol-level distinction, and in *both* cases it works only between consenting, upgraded agents and applications. Bob From list-owner-rmonmib-outgoing@cisco.com Wed Jun 17 15:27:00 1998 Delivery-Date: Wed, 17 Jun 1998 15:27:01 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21525 for ; Wed, 17 Jun 1998 15:27:00 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA15266 for ; Wed, 17 Jun 1998 15:29:19 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id MAA15024 for Rmonmib-outgoing; Wed, 17 Jun 1998 12:00:02 -0700 (PDT) Received: from mailgate-rtp-1.cisco.com (mailgate-rtp-1.cisco.com [171.69.160.46]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id LAA15010 for ; Wed, 17 Jun 1998 11:59:56 -0700 (PDT) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by mailgate-rtp-1.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id OAA23738; Wed, 17 Jun 1998 14:59:51 -0400 (EDT) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id LAA20465; Wed, 17 Jun 1998 11:59:48 -0700 (PDT) Received: from palrel3.hp.com(156.153.255.226) by proxy2.cisco.com via smap (V2.0) id xma020455; Wed, 17 Jun 98 18:59:43 GMT X-SMAP-Received-From: outside Received: from nsmdserv.cnd.hp.com (daemon@nsmdserv.cnd.hp.com [15.2.104.118]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id LAA10920; Wed, 17 Jun 1998 11:59:42 -0700 (PDT) Received: from cnd.hp.com (nautique.cnd.hp.com) by nsmdserv.cnd.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA104359974; Wed, 17 Jun 1998 12:59:35 -0600 Message-Id: <3588121F.8AFAAF29@cnd.hp.com> Date: Wed, 17 Jun 1998 12:59:43 -0600 From: "Brian O'Keefe" Reply-To: bok@cnd.hp.com Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Bob Stewart Cc: Keith McCloghrie , Harald.Alvestrand@maxware.no, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com Subject: Re: An action plan for pushing the SMI to Standard References: <3587EC70.E1094516@cnd.hp.com> <3.0.5.32.19980617143127.00866440@zipper.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Bob, thank you for replying to Kieth for me!! Kieth, I agree that we're sort of in a pickle here; but TC's are defined for "refining/tightening" the semantics of the base type, not for "expanding/loosening" the semantics. Let's learn from our mistakes and be a bit more forward-looking in adding data types to the protocol and SMI, rather than taking a protectionist approach as was done in v2SMI. The new types will get used, especially in the standards track, where and when appropriate with reasonable review. After all, who woulda thought 15 years ago that a PC would need more than 640 Kbytes of RAM? bok From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 03:47:27 1998 Delivery-Date: Thu, 18 Jun 1998 03:47:27 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id DAA16332 for ; Thu, 18 Jun 1998 03:47:26 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA18025 for ; Thu, 18 Jun 1998 03:49:46 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id AAA04585 for Rmonmib-outgoing; Thu, 18 Jun 1998 00:33:48 -0700 (PDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id AAA04580 for ; Thu, 18 Jun 1998 00:33:45 -0700 (PDT) Received: (kzm@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) id AAA13196; Thu, 18 Jun 1998 00:33:38 -0700 (PDT) From: Keith McCloghrie Message-Id: <199806180733.AAA13196@foxhound.cisco.com> Subject: Re: An action plan for pushing the SMI to Standard To: bstewart@cisco.com (Bob Stewart) Date: Thu, 18 Jun 1998 00:33:38 -0700 (PDT) Cc: kzm@cisco.com, bok@cnd.hp.com, Harald.Alvestrand@maxware.no, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com In-Reply-To: <3.0.5.32.19980617143127.00866440@zipper.cisco.com> from "Bob Stewart" at Jun 17, 98 02:31:27 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Bob, > >However, using a new SMI base type would generate an on-the-wire > >encoding which is currently illegal, i.e., it effectively creates a new > >SMI, requiring a much difficult transition strategy. On the other > >hand, using a TC requires no changes except in consenting method > >routines and NMS applications. So, if you want to be able to use this > >anytime soon, ... > > I don't see why having a new tag is any more traumatic than special-casing > an old one. If anything I'd think a new tag would be cleaner and easier to > implement. I'm not talking about "cleaner and easier to implement". I'm talking about the practicality of getting products to support it. It's 5 years since Counter64 was first published in an RFC, and 2.5 years since SNMPv2c specified how it could be used with community strings. Yet, there's still lots of systems which do not support it. If a new SMI could be published by the end of this year (optimistic?), we will still have many systems in the year 2001 which won't support the new SMI. In contrast, defining a new TC does not require a new SMI, and can be supported in new method routines. New method routines get added to most products on every new release. > Without a new tag smart, helpful, general-purpose applications will > mishandle 64-bit integers or unsigned, thinking they're counters and > require calculating a delta. In other words, special counter semantics go > with the existing tag. To use it as a 64-bit unsigned integer violates that. When the SMI was first published (RFC 1065), we defined NetworkAddress. Later, we realised that this was a mistake because we couldn't keep re-issuing the SMI every time we needed a new type of NetworkAddress. Since then, we've defined things like DisplayString and RowStatus as TC's, so that they can be put in SYNTAX clauses, and applications can apply the extra semantics of the TC, even though they are sent on the wire as OCTET STRING and INTEGER repectively. Effectively, the underlying syntax specifies the means of encoding them on the wire, and the SYNTAX clause specifies the semantics. That is, calculating a delta is a function of the SYNTAX in the MIB, not what tag is used on the wire. So, while you're right that to encode a Unsigned64 as a Counter64 is a violation of the *letter* of the law, but this is a case where it will be beneficial to bend the rules a little, for reasons of practicality, and this won't be the first time that we've bent the rules a little. (How many times has the Interfaces MIB WG bent the rules ?? :-) Keith. From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 04:24:16 1998 Delivery-Date: Thu, 18 Jun 1998 04:24:17 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id EAA16405 for ; Thu, 18 Jun 1998 04:24:16 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA18094 for ; Thu, 18 Jun 1998 04:26:36 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id BAA06379 for Rmonmib-outgoing; Thu, 18 Jun 1998 01:14:13 -0700 (PDT) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id BAA06370 for ; Thu, 18 Jun 1998 01:14:09 -0700 (PDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id BAA06227; Thu, 18 Jun 1998 01:14:06 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id BAA07057; Thu, 18 Jun 1998 01:14:04 -0700 (PDT) Received: from dokka.maxware.no(195.139.236.69) by proxy3.cisco.com via smap (V2.0) id xma007027; Thu, 18 Jun 98 08:13:58 GMT X-SMAP-Received-From: outside Received: from alden ([10.128.1.78]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id KAA08596; Thu, 18 Jun 1998 10:13:05 +0200 Message-Id: <3.0.2.32.19980618091321.00c75940@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 18 Jun 1998 09:13:21 +0200 To: Bob Stewart , Keith McCloghrie From: Harald Tveit Alvestrand Subject: Re: An action plan for pushing the SMI to Standard Cc: bok@cnd.hp.com, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com In-Reply-To: <3.0.5.32.19980617143127.00866440@zipper.cisco.com> References: <199806171729.KAA18162@foxhound.cisco.com> <3587EC70.E1094516@cnd.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmonmib@cisco.com Precedence: bulk At 14:31 17.06.98 -0400, Bob Stewart wrote: >Without a new tag smart, helpful, general-purpose applications will >mishandle 64-bit integers or unsigned, thinking they're counters and >require calculating a delta. In other words, special counter semantics go >with the existing tag. To use it as a 64-bit unsigned integer violates that. Are there examples of such "helpful" applications/APIs that do things this differently for Unsigned32 and Counter32? This seems like a good argument - but if there are no existing examples, it seems to me that we might get away with just declaring the practice evil. Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 04:45:39 1998 Delivery-Date: Thu, 18 Jun 1998 04:45:43 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id EAA16451 for ; Thu, 18 Jun 1998 04:45:38 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA18148 for ; Thu, 18 Jun 1998 04:47:58 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id BAA07499 for Rmonmib-outgoing; Thu, 18 Jun 1998 01:39:16 -0700 (PDT) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id BAA07494 for ; Thu, 18 Jun 1998 01:39:13 -0700 (PDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id BAA07223; Thu, 18 Jun 1998 01:39:11 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id BAA12064; Thu, 18 Jun 1998 01:39:09 -0700 (PDT) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by proxy1.cisco.com via smap (V2.0) id xma012016; Thu, 18 Jun 98 08:39:01 GMT X-SMAP-Received-From: outside Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id KAA17004; Thu, 18 Jun 1998 10:38:42 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA06419; Thu, 18 Jun 1998 10:38:19 +0200 Date: Thu, 18 Jun 1998 10:38:19 +0200 Message-Id: <199806180838.KAA06419@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bstewart@cisco.com CC: kzm@cisco.com, bok@cnd.hp.com, Harald.Alvestrand@maxware.no, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com In-reply-to: <3.0.5.32.19980617143127.00866440@zipper.cisco.com> (message from Bob Stewart on Wed, 17 Jun 1998 14:31:27 -0400) Subject: Re: An action plan for pushing the SMI to Standard References: <3587EC70.E1094516@cnd.hp.com> <3.0.5.32.19980617143127.00866440@zipper.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-rmonmib@cisco.com Precedence: bulk >>>>> Bob Stewart writes: Bob> I don't see why having a new tag is any more traumatic than Bob> special-casing an old one. If anything I'd think a new tag would Bob> be cleaner and easier to implement. Bob> Without a new tag smart, helpful, general-purpose applications Bob> will mishandle 64-bit integers or unsigned, thinking they're Bob> counters and require calculating a delta. In other words, Bob> special counter semantics go with the existing tag. To use it as Bob> a 64-bit unsigned integer violates that. I agree that a new tag would be clean, relatively easy to implement and avoid ambiguities in cases where the SNMP manager is not capable to understand or simply does not have access to the relevant MIBs. Bob> With a new tag we maintain a consistent, protocol-level Bob> distinction, and in *both* cases it works only between Bob> consenting, upgraded agents and applications. The down-side of a new tag is that an agent which implements Unsigned64 will cause a manager which does not implement Unsigned64 to get an ASN.1 parse error. In other words: you would not be able to `walk' the "new" agent with an "existing" SNMPv2c/SNMPv3 manager. Adding a tagged Unsigned64 causes interoperability problems, even if this is the solution we really really really like to have. [The fundamental problem here is that the RFCs do no specify a "gentle way" to handle unknown tags, e.g. by saying thy should be handled as opaque values.] Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 04:47:50 1998 Delivery-Date: Thu, 18 Jun 1998 04:47:50 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id EAA16457 for ; Thu, 18 Jun 1998 04:47:49 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA18151 for ; Thu, 18 Jun 1998 04:50:10 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id BAA07560 for Rmonmib-outgoing; Thu, 18 Jun 1998 01:41:50 -0700 (PDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id BAA07536 for ; Thu, 18 Jun 1998 01:41:43 -0700 (PDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id BAA25932 for ; Thu, 18 Jun 1998 01:41:41 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id BAA09291 for ; Thu, 18 Jun 1998 01:41:40 -0700 (PDT) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by proxy3.cisco.com via smap (V2.0) id xma009285; Thu, 18 Jun 98 08:41:34 GMT X-SMAP-Received-From: outside Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id KAA17029; Thu, 18 Jun 1998 10:40:56 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA06454; Thu, 18 Jun 1998 10:40:55 +0200 Date: Thu, 18 Jun 1998 10:40:55 +0200 Message-Id: <199806180840.KAA06454@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bok@cnd.hp.com CC: Harald.Alvestrand@maxware.no, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com In-reply-to: <3587EC70.E1094516@cnd.hp.com> (bok@cnd.hp.com) Subject: Re: An action plan for pushing the SMI to Standard References: <3.0.2.32.19980616090411.00c95280@dokka.maxware.no> <3.0.2.32.19980617075957.01ef64a0@dokka.maxware.no> <3587EC70.E1094516@cnd.hp.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-rmonmib@cisco.com Precedence: bulk >>>>> Brian O'Keefe writes: Brian> PS - will the SMIv3 effort (and mailing list) be announced on Brian> the snmp or snmpv3 list? There is no SMIv3 effort as far as I know. There is a design team which is chartered to bring SMIv2 to full standard status. I received an announcement of the design team and the rules of the game over the SNMPv3 mailing list. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 10:49:35 1998 Delivery-Date: Thu, 18 Jun 1998 10:49:35 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id KAA17670 for ; Thu, 18 Jun 1998 10:49:34 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA19258 for ; Thu, 18 Jun 1998 10:51:54 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id HAA20273 for Rmonmib-outgoing; Thu, 18 Jun 1998 07:37:43 -0700 (PDT) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id HAA20114 for ; Thu, 18 Jun 1998 07:36:27 -0700 (PDT) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id GAA24325; Thu, 18 Jun 1998 06:55:02 -0700 (PDT) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id GAA02009; Thu, 18 Jun 1998 06:55:01 -0700 (PDT) Received: from palrel1.hp.com(156.153.255.242) by proxy2.cisco.com via smap (V2.0) id xma002000; Thu, 18 Jun 98 13:54:58 GMT X-SMAP-Received-From: outside Received: from nsmdserv.cnd.hp.com (daemon@nsmdserv.cnd.hp.com [15.2.104.118]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id GAA08189; Thu, 18 Jun 1998 06:54:57 -0700 (PDT) Received: from cnd.hp.com (nautique.cnd.hp.com) by nsmdserv.cnd.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA260168088; Thu, 18 Jun 1998 07:54:48 -0600 Message-Id: <35891C32.4B8815A8@cnd.hp.com> Date: Thu, 18 Jun 1998 07:54:58 -0600 From: "Brian O'Keefe" Reply-To: bok@cnd.hp.com Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Keith McCloghrie Cc: Bob Stewart , Harald.Alvestrand@maxware.no, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com Subject: Re: An action plan for pushing the SMI to Standard References: <199806180733.AAA13196@foxhound.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Keith McCloghrie wrote: > So, while you're right that to encode a Unsigned64 as a Counter64 is > a violation of the *letter* of the law, but this is a case where it will > be beneficial to bend the rules a little, for reasons of practicality, > and this won't be the first time that we've bent the rules a little. > (How many times has the Interfaces MIB WG bent the rules ?? :-) ...and I'm feeling the pains of several of those IF-MIB bends. It must be coincidence that I was just referring to these IF-MIB pains in a conversation I had yesterday about this SMI / new data type topic. A number of applications that we ship no longer work because the semantics of several objects have been *changed*, or objects that used to be supported (and adapted) to all interface types are no longer supported by certain classes of interface types. But I'll elaborate on the IF-MIB mailing list. Looking forward and positive... I would be supportive of a TC approach to get Unsigned64 and Gauage64 into deployment asap; but I do not support approaches that break backwards compatibility. Overall, I see two alternatives: 1. a TC approach such as Dave Perkins has been investigating w.r.t. wrapping the new data types in OPAQUE; or 2. adding an explicit new application-tag for Integer64, Unsigned64 (and maybe other forseen important base types, e.g., float and/or double-float) to both a SNMPv3 SMI and updated SNMP protocol spec. Gauge64 can & should simply be a TC based on Unsigned64. The SNMPv3 Security work is at proposed, get rfc1905 updated asap and re-submitted as proposed so that all the SNMPv3 security mplementations underway can roll in the new data types NOW. bok From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 10:52:48 1998 Delivery-Date: Thu, 18 Jun 1998 10:52:49 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id KAA17701 for ; Thu, 18 Jun 1998 10:52:48 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA19285 for ; Thu, 18 Jun 1998 10:55:08 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id HAA20660 for Rmonmib-outgoing; Thu, 18 Jun 1998 07:44:08 -0700 (PDT) Received: from beasley.cisco.com (mailgate-sj-2.cisco.com [171.69.2.135]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id HAA20517 for ; Thu, 18 Jun 1998 07:43:04 -0700 (PDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id GAA25258; Thu, 18 Jun 1998 06:37:12 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id GAA13454; Thu, 18 Jun 1998 06:37:11 -0700 (PDT) Received: from palrel3.hp.com(156.153.255.226) by proxy1.cisco.com via smap (V2.0) id xma013452; Thu, 18 Jun 98 13:37:08 GMT X-SMAP-Received-From: outside Received: from nsmdserv.cnd.hp.com (daemon@nsmdserv.cnd.hp.com [15.2.104.118]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id GAA16258; Thu, 18 Jun 1998 06:37:07 -0700 (PDT) Received: from cnd.hp.com (nautique.cnd.hp.com) by nsmdserv.cnd.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA255257013; Thu, 18 Jun 1998 07:36:54 -0600 Message-Id: <358917FF.CB46B079@cnd.hp.com> Date: Thu, 18 Jun 1998 07:37:03 -0600 From: "Brian O'Keefe" Reply-To: bok@cnd.hp.com Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Harald Tveit Alvestrand Cc: Bob Stewart , Keith McCloghrie , heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com Subject: Re: An action plan for pushing the SMI to Standard References: <199806171729.KAA18162@foxhound.cisco.com> <3587EC70.E1094516@cnd.hp.com> <3.0.2.32.19980618091321.00c75940@dokka.maxware.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Harald Tveit Alvestrand wrote: > > At 14:31 17.06.98 -0400, Bob Stewart wrote: > >Without a new tag smart, helpful, general-purpose applications will > >mishandle 64-bit integers or unsigned, thinking they're counters and > >require calculating a delta. In other words, special counter semantics go > >with the existing tag. To use it as a 64-bit unsigned integer violates that. > > Are there examples of such "helpful" applications/APIs that do > things this differently for Unsigned32 and Counter32? Yes. The OpenView Network Node Manager grapher and data collector for example. Both look at the data type of the queried object. Integers, Unsigned32's and Gauge32's are plotted/stored as actual values. Counter32's and Counter64's are automatically translated to rate of change and plotted/stored as such. Now there is a configuration file that can be used to "coerce" the data type of specific mib objects. However, there's not a plain ole Unsigned64 data type to coerce not-really-counter64 objects to, so the existing installed base would mis-handle all these not-really-counter64s. We could add this in a future release, but that doesn't help the installed base (backward compatibility). > > This seems like a good argument - but if there are no existing examples, > it seems to me that we might get away with just declaring the practice evil. I'd say that OpenView NNM is fairly widely deployed. It has supported Counter64 for apx 2 years now (circa SNMPv2c intro). Further, this is *not* an "evil practice". It is in fact a "smart, helpful, general-purpose application" that releives the end user and other applications from having to do this on their own. bok From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 10:52:49 1998 Delivery-Date: Thu, 18 Jun 1998 10:52:49 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id KAA17704 for ; Thu, 18 Jun 1998 10:52:48 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA19286 for ; Thu, 18 Jun 1998 10:55:08 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id HAA20695 for Rmonmib-outgoing; Thu, 18 Jun 1998 07:44:51 -0700 (PDT) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id HAA20683 for ; Thu, 18 Jun 1998 07:44:43 -0700 (PDT) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id HAA28808 for ; Thu, 18 Jun 1998 07:33:11 -0700 (PDT) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id HAA08051 for ; Thu, 18 Jun 1998 07:32:50 -0700 (PDT) Received: from palrel1.hp.com(156.153.255.242) by proxy2.cisco.com via smap (V2.0) id xma008042; Thu, 18 Jun 98 14:32:47 GMT X-SMAP-Received-From: outside Received: from nsmdserv.cnd.hp.com (daemon@nsmdserv.cnd.hp.com [15.2.104.118]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id HAA23013; Thu, 18 Jun 1998 07:32:46 -0700 (PDT) Received: from cnd.hp.com (darren.cnd.hp.com) by nsmdserv.cnd.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA296310357; Thu, 18 Jun 1998 08:32:37 -0600 Message-Id: <3589250C.1FB830E6@cnd.hp.com> Date: Thu, 18 Jun 1998 08:32:44 -0600 From: "Darren D. Smith" Organization: OVSD, HP X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: snmpv3@tis.com Cc: bok@cnd.hp.com, rmonmib@cisco.com Subject: Re: An action plan for pushing the SMI to Standard References: <199806171729.KAA18162@foxhound.cisco.com> <3587EC70.E1094516@cnd.hp.com> <3.0.2.32.19980618091321.00c75940@dokka.maxware.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Harald Tveit Alvestrand wrote: > Are there examples of such "helpful" applications/APIs that do > things this differently for Unsigned32 and Counter32? > > This seems like a good argument - but if there are no existing examples, > it seems to me that we might get away with just declaring the practice evil. Just as an example, HP OpenView NNM has graphing functions that look at whether it is a counter or a guage, and behave differently. Currently these functions don't have to look at the MIB syntax to know what to do. If Unsigned64 and Gauge64 are implemented as textual conventions, these routines will have to access the MIB meta-data to understand and graph a MIB value. This means that the MIB modules have to be loaded into our data store, and numerous other things. There is no doubt implementation wise that *for us* doing the "right" thing is to implement the 64-bit integers the same as the 32 bit integers. As far as the backwards compatiability issue with new agents breaking old managers, this is a true issue. However, new managers can typically be rolled into the environment much easier than rolling all the agents in the environment. On the other hand, it could be possible for a manager to also get a parse error from an old agent, but that seems easier to handle on the management side, which has to handle potential missing objects anyway. -- Darren D. Smith darren_smith@hp.com OVSD, HP -- From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 17:09:35 1998 Delivery-Date: Thu, 18 Jun 1998 17:09:35 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA22518 for ; Thu, 18 Jun 1998 17:09:34 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA21376 for ; Thu, 18 Jun 1998 17:11:55 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id NAA29857 for Rmonmib-outgoing; Thu, 18 Jun 1998 13:52:00 -0700 (PDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id NAA29852 for ; Thu, 18 Jun 1998 13:51:57 -0700 (PDT) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id MAA11938 for ; Thu, 18 Jun 1998 12:32:22 -0700 (PDT) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id MAA08104 for ; Thu, 18 Jun 1998 12:32:20 -0700 (PDT) Received: from shell16.ba.best.com(206.184.139.148) by proxy2.cisco.com via smap (V2.0) id xma008094; Thu, 18 Jun 98 19:32:17 GMT X-SMAP-Received-From: outside Received: from localhost (heard@localhost) by shell16.ba.best.com (8.8.8/8.8.BEST) with SMTP id MAA10305; Thu, 18 Jun 1998 12:32:12 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Thu, 18 Jun 1998 12:32:12 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: Harald.Alvestrand@maxware.no cc: snmpv3@tis.com, rmonmib@cisco.com Subject: Re: An action plan for pushing the SMI to Standard In-Reply-To: <35891C32.4B8815A8@cnd.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmonmib@cisco.com Precedence: bulk [ since I started this thread ... ] Keith McCloghrie wrote: kzm> It's 5 years since Counter64 was first published in an RFC, and 2.5 kzm> years since SNMPv2c specified how it could be used with community kzm> strings. Yet, there's still lots of systems which do not support it. That's true. But is it not also true that the majority of the systems now deployed support only SNMPv1, which does not support Counter64, and not the now historic SNMPv2p (with which Counter64 was originally specified) nor SNMPv2C (which is not on the standards track)? Brian O'Keefe wrote: bok> I would be supportive of a TC approach to get Unsigned64 and bok> Gauage64 into deployment asap; but I do not support approaches bok> that break backwards compatibility. I agree. bok> Overall, I see two alternatives: bok> bok> 1. a TC approach such as Dave Perkins has been investigating bok> w.r.t. wrapping the new data types in OPAQUE; or bok> bok> 2. adding an explicit new application-tag for Integer64, bok> Unsigned64 (and maybe other forseen important base types, bok> e.g., float and/or double-float) to both a SNMPv3 SMI and bok> updated SNMP protocol spec. Gauge64 can & should simply be bok> a TC based on Unsigned64. The SNMPv3 Security work is at bok> proposed, get rfc1905 updated asap and re-submitted as bok> proposed so that all the SNMPv3 security mplementations bok> underway can roll in the new data types NOW. I would prefer to see alternative 1 -- rehabilitation of the Opaque type, and wrapping new data types in it -- rather than the use of new application tags, because it addresses the following points raised by Juergen Schoenwaelder: Juergen> The down-side of a new tag is that an agent which implements Juergen> Unsigned64 will cause a manager which does not implement Unsigned64 to Juergen> get an ASN.1 parse error. In other words: you would not be able to Juergen> `walk' the "new" agent with an "existing" SNMPv2c/SNMPv3 manager. Juergen> Adding a tagged Unsigned64 causes interoperability problems, even if Juergen> this is the solution we really really really like to have. Juergen> Juergen> [The fundamental problem here is that the RFCs do no specify a "gentle Juergen> way" to handle unknown tags, e.g. by saying thy should be handled as Juergen> opaque values.] Double-wrapping new types behind an Opaque tag avoids this, and has the additional advantage of being usable with SNMPv1. That is no small consideration, because SNMPv1 in all likelihood will be with us for years. In saying this let me hasten to add that carefully specifying what is allowed in the sequence of octets inside the Opaque wrapper is an _essential_ part of its rehabilitation [I believe Dave Perkins uses the word "domestication"]. In particular, one must not only specify that a valid BER encoding is required, but must also specify which tags are reserved for future standardization and which (if any) are fair game for private use. Dave Perkins has addressed these points and has made some specific proposals in draft-perkins-opaque-01.txt (available at http://www.snmpinfo.com/sismiclr.htm). It is true that domesticating the Opaque type can only be done by revising the the SMI as it is currently written in a way that is not strictly backward compatible. But so would adding a TC that allows a Gauge64 type to be encoded with a Counter64 tag. I would expect that the latter change would be much more likely to cause backward compatibility problems with existing applications because Counter64 is used in a number standard MIBs, whereas Opaque is not used in any. Also, it is not difficult to find private enterprise MIBs which use Counter64, but only once have I seen an Opaque type. One of the reasons that I started this discussion is that I am working _right now_ on an (SNMPv1-based) system that has a substantial number of Gauge64-type objects in its private enterprise MIB. The approach I have taken is encode them like they were integers, but tag them as octet strings. I have done this rather than double-wrapping them behind an Opaque tag because the existing undomesticated Opaque type offers me no advantage over an octet string (and might even have slightly more risk of causing a management application to fail). However, if a domesticated Opaque type offered a standard way to have a Gause64 I'd adopt it in a heartbeat and junk my current octet string-based TC. By changing the SMI rules to rehabilitate the Opaque type we have an opportunity to solve once and for all the fundamental problem that Juergen so eloquently pointed out -- Juergen> [The fundamental problem here is that the RFCs do no specify a "gentle Juergen> way" to handle unknown tags, e.g. by saying thy should be handled as Juergen> opaque values.] There is an identified need today for an Unsigned64 type, and the need for other base types is likely to arise in the future. I strongly feel that addressing these problems should take higher precedence than advancing SMIv2 to full standard, and indeed, one could argue that their existence is evidence that such advancement is premature. I respectfully urge the ADs to reconsider their position the work of the SMI team "is NOT about adding new functionality". Thanks, Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 17:26:12 1998 Delivery-Date: Thu, 18 Jun 1998 17:26:13 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA22662 for ; Thu, 18 Jun 1998 17:26:11 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA21476 for ; Thu, 18 Jun 1998 17:28:33 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id OAA01144 for Rmonmib-outgoing; Thu, 18 Jun 1998 14:21:26 -0700 (PDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id OAA01139 for ; Thu, 18 Jun 1998 14:21:22 -0700 (PDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id OAA22021 for ; Thu, 18 Jun 1998 14:21:18 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id OAA10978 for ; Thu, 18 Jun 1998 14:21:17 -0700 (PDT) Received: from shell16.ba.best.com(206.184.139.148) by proxy3.cisco.com via smap (V2.0) id xma010940; Thu, 18 Jun 98 21:21:13 GMT X-SMAP-Received-From: outside Received: from localhost (heard@localhost) by shell16.ba.best.com (8.8.8/8.8.BEST) with SMTP id OAA27102; Thu, 18 Jun 1998 14:20:34 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Thu, 18 Jun 1998 14:20:34 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: Bob Natale cc: snmpv3@tis.com, rmonmib@cisco.com, smi-dt@ops.ietf.org Subject: Re: An action plan for pushing the SMI to Standard In-Reply-To: <3.0.5.32.19980618114316.009a2b10@nips.acec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmonmib@cisco.com Precedence: bulk Hi Bob, On Thu, 18 Jun 1998, you wrote: bob> >At 07:54 AM 6/18/98 -0600, bok wrote: bob> bob> <...> bob> >Overall, I see two alternatives: bob> > bob> > 1. a TC approach such as Dave Perkins has been investigating bob> > w.r.t. wrapping the new data types in OPAQUE; bob> bob> Shudder [wrt OPAQUE]. On the surface, that looks potentially messy. bob> Under the surface...it looks a lot worse. It is a clever idea, I bob> agree...but clever doesn't always equate to good. I feel very strongly that we need to do something about the problem that Juergen so eloquently pointed out -- Juergen> [The fundamental problem here is that the RFCs do no specify a "gentle Juergen> way" to handle unknown tags, e.g. by saying thy should be handled as Juergen> opaque values.] Without addressing this problem in some way it is not possible to add new base types to the SMI without changing the protocol at the same time. The deployment headaches that would result from changing the protocol to accept new tags are likely to be much worse than mere annoyances: there could be "black hole" communication failures if the protocol version number were not changed (messages dropped by older implementations which get ASN.1 parse failures), but on the other hand changing the version number (and supporting multiple versions during a transition) is not without significant cost. Letting new types hide behind an Opaque tag, on the other hand, _will_ allow new types to be added without changing the protocol, because the current protocol(s) all recognize Opaque as a valid (although disgusting) type. Of course, this idea won't work well unless the SMI is changed so that the stuff hiding behing the Opaque tag is well-defined. But that is a change which can be deployed incrementally, and which I think can be done at much less cost than supporting a new protocol version. I will concede that hiding stuff behind an Opaque tag is rather ugly. In hindsight, defining the protocol so that unknown application tags are skipped rather than causing ASN.1 parse errors might have been a better idea. But it is too late for that. I, for one, fail to see why this idea has met with such an unfavorable reception. It seems to me to be a practical and relatively low-cost solution to a real problem, and I think that outweighs it ugliness. If there is something I am missing please feel free to correct me. Thanks, Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 17:40:30 1998 Delivery-Date: Thu, 18 Jun 1998 17:40:30 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA22762 for ; Thu, 18 Jun 1998 17:40:29 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA21661 for ; Thu, 18 Jun 1998 17:42:50 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id OAA01538 for Rmonmib-outgoing; Thu, 18 Jun 1998 14:33:15 -0700 (PDT) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id OAA01533 for ; Thu, 18 Jun 1998 14:33:10 -0700 (PDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id KAA22324 for ; Thu, 18 Jun 1998 10:38:29 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id KAA01201 for ; Thu, 18 Jun 1998 10:38:26 -0700 (PDT) Received: from f11.hotmail.com(207.82.250.22) by proxy1.cisco.com via smap (V2.0) id xma001182; Thu, 18 Jun 98 17:38:22 GMT X-SMAP-Received-From: outside Received: (qmail 20047 invoked by uid 0); 18 Jun 1998 17:38:20 -0000 Message-ID: <19980618173820.20046.qmail@hotmail.com> Received: from 199.99.177.2 by www.hotmail.com with HTTP; Thu, 18 Jun 1998 10:38:20 PDT X-Originating-IP: [199.99.177.2] From: "Abhay Shriramwar" To: bstewart@cisco.com, schoenw@ibr.cs.tu-bs.de Cc: kzm@cisco.com, bok@cnd.hp.com, Harald.Alvestrand@maxware.no, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com Subject: Re: An action plan for pushing the SMI to Standard Content-Type: text/plain Date: Thu, 18 Jun 1998 10:38:20 PDT Sender: owner-rmonmib@cisco.com Precedence: bulk I agree with interoperability and support to existing SMI must be important consideration. Thanks regards Abhay S. >From list-owner-rmonmib-outgoing@cisco.com Thu Jun 18 04:13:56 1998 >Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id BAA07499 for Rmonmib-outgoing; Thu, 18 Jun 1998 01:39:16 -0700 (PDT) >Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id BAA07494 for ; Thu, 18 Jun 1998 01:39:13 -0700 (PDT) >Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id BAA07223; Thu, 18 Jun 1998 01:39:11 -0700 (PDT) >Received: (from smap@localhost) > by proxy1.cisco.com (8.8.7/8.8.5) id BAA12064; > Thu, 18 Jun 1998 01:39:09 -0700 (PDT) >Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by proxy1.cisco.com via smap (V2.0) > id xma012016; Thu, 18 Jun 98 08:39:01 GMT >X-SMAP-Received-From: outside >Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) > by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id KAA17004; > Thu, 18 Jun 1998 10:38:42 +0200 (MET DST) >Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA06419; Thu, 18 Jun 1998 10:38:19 +0200 >Date: Thu, 18 Jun 1998 10:38:19 +0200 >Message-Id: <199806180838.KAA06419@henkell.ibr.cs.tu-bs.de> >From: Juergen Schoenwaelder >To: bstewart@cisco.com >CC: kzm@cisco.com, bok@cnd.hp.com, Harald.Alvestrand@maxware.no, > heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com >In-reply-to: <3.0.5.32.19980617143127.00866440@zipper.cisco.com> (message from > Bob Stewart on Wed, 17 Jun 1998 14:31:27 -0400) >Subject: Re: An action plan for pushing the SMI to Standard >References: <3587EC70.E1094516@cnd.hp.com> <3.0.5.32.19980617143127.00866440@zipper.cisco.com> >Mime-Version: 1.0 (generated by tm-edit 7.106) >Content-Type: text/plain; charset=US-ASCII >Sender: owner-rmonmib@cisco.com >Precedence: bulk > > >>>>>> Bob Stewart writes: > >Bob> I don't see why having a new tag is any more traumatic than >Bob> special-casing an old one. If anything I'd think a new tag would >Bob> be cleaner and easier to implement. > >Bob> Without a new tag smart, helpful, general-purpose applications >Bob> will mishandle 64-bit integers or unsigned, thinking they're >Bob> counters and require calculating a delta. In other words, >Bob> special counter semantics go with the existing tag. To use it as >Bob> a 64-bit unsigned integer violates that. > >I agree that a new tag would be clean, relatively easy to implement >and avoid ambiguities in cases where the SNMP manager is not capable >to understand or simply does not have access to the relevant MIBs. > >Bob> With a new tag we maintain a consistent, protocol-level >Bob> distinction, and in *both* cases it works only between >Bob> consenting, upgraded agents and applications. > >The down-side of a new tag is that an agent which implements >Unsigned64 will cause a manager which does not implement Unsigned64 to >get an ASN.1 parse error. In other words: you would not be able to >`walk' the "new" agent with an "existing" SNMPv2c/SNMPv3 manager. >Adding a tagged Unsigned64 causes interoperability problems, even if >this is the solution we really really really like to have. > >[The fundamental problem here is that the RFCs do no specify a "gentle >way" to handle unknown tags, e.g. by saying thy should be handled as >opaque values.] > Juergen > >Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw >Technical University Braunschweig, Dept. Operating Systems & Computer Networks >Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From list-owner-rmonmib-outgoing@cisco.com Fri Jun 19 03:50:13 1998 Delivery-Date: Fri, 19 Jun 1998 03:50:14 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id DAA05907 for ; Fri, 19 Jun 1998 03:50:13 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA23115 for ; Fri, 19 Jun 1998 03:52:34 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id AAA24744 for Rmonmib-outgoing; Fri, 19 Jun 1998 00:42:16 -0700 (PDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id AAA24720 for ; Fri, 19 Jun 1998 00:42:10 -0700 (PDT) Received: (kzm@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) id AAA09250; Fri, 19 Jun 1998 00:42:12 -0700 (PDT) From: Keith McCloghrie Message-Id: <199806190742.AAA09250@foxhound.cisco.com> Subject: Re: An action plan for pushing the SMI to Standard To: bok@cnd.hp.com Date: Fri, 19 Jun 1998 00:42:12 -0700 (PDT) Cc: Harald.Alvestrand@maxware.no, bstewart@cisco.com, kzm@cisco.com, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com In-Reply-To: <358917FF.CB46B079@cnd.hp.com> from "Brian O'Keefe" at Jun 18, 98 07:37:03 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Brian, > > Are there examples of such "helpful" applications/APIs that do > > things this differently for Unsigned32 and Counter32? > > Yes. The OpenView Network Node Manager grapher and data collector > for example. Both look at the data type of the queried object. > Integers, Unsigned32's and Gauge32's are plotted/stored as actual > values. Counter32's and Counter64's are automatically translated > to rate of change and plotted/stored as such. The snmptcl applications that Marshall and I wrote do the same thing. However, defining Unsigned64 and Guage64 as TC's based on Counter64 will *not* break these snmptcl applications, because the applications determine the data type by examining the SYNTAX clause in the MIB, not by examining the ASN.1 tag on the wire. I'd be surprised if your applications were different. Keith. From list-owner-rmonmib-outgoing@cisco.com Mon Jun 22 09:47:53 1998 Delivery-Date: Mon, 22 Jun 1998 09:47:53 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id WAA03377 for ; Sun, 21 Jun 1998 22:38:01 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA01693 for ; Sun, 21 Jun 1998 22:40:23 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id TAA00532 for Rmonmib-outgoing; Sun, 21 Jun 1998 19:27:39 -0700 (PDT) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id TAA00527 for ; Sun, 21 Jun 1998 19:27:35 -0700 (PDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id TAA28294; Sun, 21 Jun 1998 19:27:07 -0700 (PDT) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id TAA08399; Sun, 21 Jun 1998 19:27:05 -0700 (PDT) Received: from concord.com(192.124.15.3) by proxy1.cisco.com via smap (V2.0) id xma008394; Mon, 22 Jun 98 02:27:04 GMT X-SMAP-Received-From: outside Received: from marvin.concord.com by concord.com (4.1/SMI-4.1) id AA16558; Sun, 21 Jun 98 22:26:47 EDT Received: from capn by marvin.concord.com (SMI-8.6/SMI-SVR4) id WAA24691; Sun, 21 Jun 1998 22:26:32 -0400 Message-Id: <3.0.3.32.19980621222320.00a983c0@marvin.concord.com> X-Sender: sylor@marvin.concord.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 21 Jun 1998 22:23:20 -0400 To: Keith McCloghrie , bok@cnd.hp.com From: Mark Sylor Subject: Re: An action plan for pushing the SMI to Standard Cc: Harald.Alvestrand@maxware.no, bstewart@cisco.com, kzm@cisco.com, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com In-Reply-To: <199806190742.AAA09250@foxhound.cisco.com> References: <358917FF.CB46B079@cnd.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmonmib@cisco.com Precedence: bulk Our application works much as Keith describes. It distinguishes between Gauges and Counters based on the SYNTAX in the MIB, not the tag. I believe Keith's suggestion is equivalent to redefining the meaning of the Counter64 tag to mean Unsigned64 (the more primitive type), and then having TCs for Counter64 (it wraps modulo 2^64) and Gauge64 (it latches if it reaches 2^64-1). That would simplify implementations, and is preferable to adding yet another tag. Of course the problems of getting that to standard status need to be considered. Mark At 12:42 AM 6/19/98 -0700, Keith McCloghrie wrote: >Brian, > >> > Are there examples of such "helpful" applications/APIs that do >> > things this differently for Unsigned32 and Counter32? >> >> Yes. The OpenView Network Node Manager grapher and data collector >> for example. Both look at the data type of the queried object. >> Integers, Unsigned32's and Gauge32's are plotted/stored as actual >> values. Counter32's and Counter64's are automatically translated >> to rate of change and plotted/stored as such. > >The snmptcl applications that Marshall and I wrote do the same thing. >However, defining Unsigned64 and Guage64 as TC's based on Counter64 >will *not* break these snmptcl applications, because the applications >determine the data type by examining the SYNTAX clause in the MIB, not >by examining the ASN.1 tag on the wire. I'd be surprised if your >applications were different. > >Keith. > > From list-owner-rmonmib-outgoing@cisco.com Mon Jun 22 09:52:46 1998 Delivery-Date: Mon, 22 Jun 1998 09:52:47 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id JAA01710 for ; Mon, 22 Jun 1998 09:52:46 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA03378 for ; Mon, 22 Jun 1998 09:55:11 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id GAA25439 for Rmonmib-outgoing; Mon, 22 Jun 1998 06:47:57 -0700 (PDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id GAA25434 for ; Mon, 22 Jun 1998 06:47:51 -0700 (PDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id GAA11918; Mon, 22 Jun 1998 06:47:47 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id GAA02094; Mon, 22 Jun 1998 06:47:43 -0700 (PDT) Received: from palrel3.hp.com(156.153.255.226) by proxy3.cisco.com via smap (V2.0) id xma002086; Mon, 22 Jun 98 13:47:38 GMT X-SMAP-Received-From: outside Received: from nsmdserv.cnd.hp.com (daemon@nsmdserv.cnd.hp.com [15.2.104.118]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id GAA23687; Mon, 22 Jun 1998 06:47:37 -0700 (PDT) Received: from cnd.hp.com (nautique.cnd.hp.com) by nsmdserv.cnd.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA284033253; Mon, 22 Jun 1998 07:47:33 -0600 Message-Id: <358E6079.3DBA00E5@cnd.hp.com> Date: Mon, 22 Jun 1998 07:47:37 -0600 From: "Brian O'Keefe" Reply-To: bok@cnd.hp.com Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Keith McCloghrie Cc: Harald.Alvestrand@maxware.no, bstewart@cisco.com, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com Subject: Re: An action plan for pushing the SMI to Standard References: <199806190742.AAA09250@foxhound.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Keith McCloghrie wrote: > I'd be surprised if your > applications were different. Surprise. Our application is based on the notion that a TC can only refine the base type, not expand it. >From RFC 1903: "When designing a MIB module, it is often useful to define new types similar to those defined in the SMI. In comparison to a type defined in the SMI, each of these new types has a different name, a similar syntax, but a more precise semantics." We interpret this to mean that a TC is to its base type, as a derived class is to its base class in OO programming. That is, all of the operations you can do to the base class can also be done with meaningful results to the derived class. Casting Counter64 into a more general Unsigned64 is NOT making the semantics more precise. In fact, it broadens or loosens the semantics. Gauge64 simply changes the semantics completely. This means that the "rateOfChange()" operation, which is the only sensible operation for interpreting a Counter64, would no longer yield meaningful results for the derived class/type. At what point does "bending the rules" degenerate into "there are no rules"? bok From list-owner-rmonmib-outgoing@cisco.com Mon Jun 22 10:13:06 1998 Delivery-Date: Mon, 22 Jun 1998 10:13:07 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id KAA01989 for ; Mon, 22 Jun 1998 10:13:06 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA03503 for ; Mon, 22 Jun 1998 10:15:31 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id HAA25893 for Rmonmib-outgoing; Mon, 22 Jun 1998 07:08:24 -0700 (PDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id HAA25873 for ; Mon, 22 Jun 1998 07:08:14 -0700 (PDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id HAA13368; Mon, 22 Jun 1998 07:08:11 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id HAA05289; Mon, 22 Jun 1998 07:08:08 -0700 (PDT) Received: from palrel1.hp.com(156.153.255.242) by proxy3.cisco.com via smap (V2.0) id xma005267; Mon, 22 Jun 98 14:08:04 GMT X-SMAP-Received-From: outside Received: from nsmdserv.cnd.hp.com (daemon@nsmdserv.cnd.hp.com [15.2.104.118]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id HAA16421; Mon, 22 Jun 1998 07:07:55 -0700 (PDT) Received: from cnd.hp.com (nautique.cnd.hp.com) by nsmdserv.cnd.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA289594471; Mon, 22 Jun 1998 08:07:51 -0600 Message-Id: <358E6539.FEF23F90@cnd.hp.com> Date: Mon, 22 Jun 1998 08:07:53 -0600 From: "Brian O'Keefe" Reply-To: bok@cnd.hp.com Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Mark Sylor Cc: Keith McCloghrie , Harald.Alvestrand@maxware.no, bstewart@cisco.com, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com Subject: Re: An action plan for pushing the SMI to Standard References: <358917FF.CB46B079@cnd.hp.com> <3.0.3.32.19980621222320.00a983c0@marvin.concord.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Mark Sylor wrote: > I believe Keith's suggestion is equivalent to redefining the meaning of the > Counter64 tag to mean Unsigned64 (the more primitive type), and then having > TCs for Counter64 (it wraps modulo 2^64) and Gauge64 (it latches if it > reaches 2^64-1). That would simplify implementations, and is preferable to > adding yet another tag. I agree that this is how things SHOULD HAVE BEEN defined from the beginning; at at least when reviewing RFC 1443 for advancement as 1902. However, if I may take your analogy a step further... how would you accomplish such a redefinition? You'd have to edit rfc 1905 to change the name and semantics of the Counter64 application tag to Unsigned64. This change requires publishing a new document. At what level? PROPOSED-STANDARD. Now, given that RFC 1905 references Counter64 as its old semantics, it too would have to roll back to PROPOSED-STANDARD. So where has this gotten us? Back to square one. ... Now on a more positive note, if you all wanted to "bend the rules" we could *probably* respond in fairly short order with updates to our next product release and maybe even patches for existing/deployed releases. However, what is the difference between this course and defining a new application tag for Unsigned64 (leaving Counter64 as is for backwards compatibility), rolling the Pdu version number, and getting the whole thing rolled out in about the same timeframe. The only difference I see is that one is "bending the rules" and one is "playing by the rules". bok From list-owner-rmonmib-outgoing@cisco.com Mon Jun 29 08:49:31 1998 Delivery-Date: Mon, 29 Jun 1998 08:49:46 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA11553 for ; Mon, 29 Jun 1998 08:49:16 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA03617 for ; Mon, 29 Jun 1998 08:51:35 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id FAA26134 for Rmonmib-outgoing; Mon, 29 Jun 1998 05:28:18 -0700 (PDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id FAA26067 for ; Mon, 29 Jun 1998 05:27:02 -0700 (PDT) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id FAA10579 for ; Mon, 29 Jun 1998 05:27:00 -0700 (PDT) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id FAA25637 for ; Mon, 29 Jun 1998 05:26:59 -0700 (PDT) Received: from web2.rocketmail.com(205.180.57.68) by proxy2.cisco.com via smap (V2.0) id xma025623; Mon, 29 Jun 98 12:26:57 GMT X-SMAP-Received-From: outside Message-ID: <19980629123504.29311.rocketmail@web2.rocketmail.com> Received: from [192.117.240.3] by web2; Mon, 29 Jun 1998 05:35:04 PDT Date: Mon, 29 Jun 1998 05:35:04 -0700 (PDT) From: Benichou Shimon Subject: Rmon2 -Address Map Group To: kzm@cisco.com Cc: heard@shelll6.ba.best.com, bstewart@cisco.com, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com, bob@cnd.hp.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-rmonmib@cisco.com Precedence: bulk Hi , Working with the HpOpen View SNMP Browser ,I'm trying to get some information from the AddressMap group. Nothing appears . I tried also with the 3com Transcend monitor ,and the same results. It seems that I forget to make some changes on some objects elsewhere. Can you help me in getting a list of relational Mac address and network addresses ? what do I have to do ,for that ? Thanks. Shimon _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From list-owner-rmonmib-outgoing@cisco.com Mon Jun 29 15:12:41 1998 Delivery-Date: Mon, 29 Jun 1998 15:12:46 -0400 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA23155 for ; Mon, 29 Jun 1998 15:12:39 -0400 (EDT) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA06171 for ; Mon, 29 Jun 1998 15:14:59 -0400 (EDT) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id MAA06628 for Rmonmib-outgoing; Mon, 29 Jun 1998 12:03:21 -0700 (PDT) Received: from beasley.cisco.com (mailgate-sj-2.cisco.com [171.69.2.135]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id MAA06611 for ; Mon, 29 Jun 1998 12:02:55 -0700 (PDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id MAA27981; Mon, 29 Jun 1998 12:02:46 -0700 (PDT) From: Robin_Iddon@3com.com Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id MAA24818; Mon, 29 Jun 1998 12:02:45 -0700 (PDT) Received: from seattle.3com.com(129.213.128.97) by proxy1.cisco.com via smap (V2.0) id xma024807; Mon, 29 Jun 98 19:02:42 GMT X-SMAP-Received-From: outside Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA09293; Mon, 29 Jun 1998 12:02:31 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id MAA17695; Mon, 29 Jun 1998 12:02:30 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 88256632.00689AED ; Mon, 29 Jun 1998 12:02:34 -0700 X-Lotus-FromDomain: 3COM To: Benichou Shimon cc: kzm@cisco.com, heard@shelll6.ba.best.com, bstewart@cisco.com, heard@vvnet.com, snmpv3@tis.com, rmonmib@cisco.com, bob@cnd.hp.com Message-ID: <80256632.0066C5AC.00@hqoutbound.ops.3com.com> Date: Mon, 29 Jun 1998 20:07:46 +0100 Subject: Re: Rmon2 -Address Map Group Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-rmonmib@cisco.com Precedence: bulk Hi, You don't mention the type of probe you are using - that would be helpful. Anyway the addressMapTable will only be populated under certain conditions: (1) The probe must support the table; check with vendor, or do some probing to see if any of the objects are present. addressMapInserts/addressMapDeletes/addressMapMaxDesiredEntries are all scalars and should be present if the agent supports this table. Also probeCapabilities, bit 20, should be set if the agent supports address mapping in principle. (2) The table must be enabled on the interface which you are trying to monitor. Let's assume that is ifIndex.1 then there must be a row in the addressMapControlTable like this (X is any number between 1..65535): addressMapControlDataSource.X = ifIndex.1 addressMapControlDroppedFrames.X = random counter32 value. addressMapControlOwner.X = random owner string (maybe "monitor"). addressMapControlStatus = active(1). The first and last ones are the only ones that matter; the dataSource must point at your interface, the controlStatus must be active(1). If this row does not exist, create it. Check for error returns and ignored sets afterwards (who knows, the agent may appear to accept your request, only to ignore it - it happens!). Also in order for any data to be collected addressMapMaxDesiredEntries should be some non-zero number, preferably quite large; for testing 100 should be fine. (3) The protocols of significance must also have address mapping supported and enabled. This is the hardest thing to explain in detail, but in principle you need to scan the protocol directory looking for the network layers you care about (i.e. IP :-) and then make sure that the protocolDirAddressMapConfig object for those rows has the value supportedOn(3). If it is supportedOff(2) change it; if it is notSupported(1) there is nothing you can do. The easiest way to scan the protocol directory, assuming you do not have a good tool to do it, is to walk protocolDirDescr and protocolDirAddressMapConfig and hope that the vendor's description strings mean something to you. For example from a probe on my network, all rows which have protocolDirAddressMapConfig = supportedOn(3): Descr AddressMapConfig *.idp supportedOn(3) *.ip supportedOn(3) *.vip supportedOn(3) *.drp supportedOn(3) *.atalk supportedOn(3) *.ipx supportedOn(3) ... which is the obvious set. (4) The probe has enough memory left to populate the table; I would reboot it if in doubt. Hope this helps, Robin From maria@xedia.com Fri Jul 3 11:37:26 1998 Delivery-Date: Fri, 03 Jul 1998 11:37:26 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA27367 for ; Fri, 3 Jul 1998 11:37:25 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA25216 for ; Fri, 3 Jul 1998 11:39:46 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id JAA11042 for ; Fri, 3 Jul 1998 09:38:13 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id JAA12611 for ; Fri, 3 Jul 1998 09:38:07 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id PAA09308; Fri, 3 Jul 1998 15:38:04 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA12263; Fri, 3 Jul 1998 15:38:02 +0200 Date: Fri, 3 Jul 1998 15:38:02 +0200 Message-Id: <199807031338.PAA12263@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: disman@nexen.com, snmpv3@tis.com Subject: VACM and DISMAN Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII I am trying to find `good' VACM configurations for the Script MIB. And it turns out that this is more complex than I thought. What I would like to have for the Script MIB is what people usually call "role based access control" (RBAC): A user (a snmpSecurityName in RFC 2271 speak) maps to one of more roles he has (e.g. routing administrator, web service manager, data collector) and each role has associated "transactions" that can be called in order to fulfill the tasks for a given role. Transactions are either SNMP operations (in case of traditional agents) or more complex management functions implemented via scripts. It would be cool if VACM could be configured so that we get something pretty similar to the RBAC model described above. In an ideal world, the security administrator would configure VACM so that it is pretty easy to assign user "joe" the role of a "routing administrator and data collector" and user "lara" the role of a "web service manager and data collector". I started to look deeper into VACM and I finally realized that VACM is not ideal with regard to the RBAC model described above: 1) At first glance, it looks like if the VACM group can be used to describe roles. However, a given user (identified by securityName and securityModel) can only be in a single group, which makes it impossible to assign multiple "roles" to a user. This means that in the example above, I have to create a group "routing administrator and data collector" and another group "web service manager and data collector". An alternative would be to give the principals "joe" and "lara" two snmpSecurityNames and tell them that they are responsible to select the right name for a given task. 2) Having to define lots of groups would not be that bad if one could at least share common view tree family definitions. However, VACM does not allow to do that. So, in the example, I would have to duplicate the tree family entries needed to be a data collector for the groups "routing administrator and data collector" and "web service manager and data collector", which does not look very attractive. Things get really worse if you have a DISMAN environment and you want to give users their own "sandboxes" where they can install scripts of expressions to be evalutated. You either end up doing a one-to-one mapping between securityNames and VACM groups (thus rendering VACM groups useless and duplicating entries in the tree family table) or you hand out another securityName which is used to select the private "sandbox". Please let me know if I have just overlooked something in RFC 2275. If my interpretation of RFC 2275 is correct, I would argue that VACM might work pretty well to protect small agents without many control objects. But VACM has a pretty serious scalability problems for agents where you need different but similar levels of access control of multiple users, like the Script MIB. Are there already fielded implementations of VACM? Are there any experiences or guidelines how to use it without creating huge MIB tables? Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From maria@xedia.com Fri Jul 3 16:15:59 1998 Delivery-Date: Fri, 03 Jul 1998 16:15:59 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA28529 for ; Fri, 3 Jul 1998 16:15:58 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA25644 for ; Fri, 3 Jul 1998 16:18:15 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id OAA14635 for ; Fri, 3 Jul 1998 14:22:34 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id OAA12878 for ; Fri, 3 Jul 1998 14:22:33 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA09960; Fri, 3 Jul 1998 14:22:22 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA15952; Fri, 3 Jul 1998 14:22:21 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA30164; Fri, 3 Jul 1998 14:22:17 -0400 From: Uri Blumenthal Message-Id: <9807031822.AA30164@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder) Date: Fri, 3 Jul 1998 14:22:16 -0400 (EDT) Cc: disman@nexen.com, snmpv3@tis.com In-Reply-To: <199807031338.PAA12263@henkell.ibr.cs.tu-bs.de> from "Juergen Schoenwaelder" at Jul 3, 98 03:38:02 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Juergen Schoenwaelder says: > I am trying to find `good' VACM configurations for the Script MIB. And > it turns out that this is more complex than I thought. What I would > like to have for the Script MIB is what people usually call "role > based access control" (RBAC): IMHO, VACM was not designed to accomodate it. One *can* use it that way by modifying the "match" criteria. > I started to look deeper into VACM and I finally realized that VACM is > not ideal with regard to the RBAC model described above: > > 1) At first glance, it looks like if the VACM group can be used to > describe roles. However, a given user (identified by securityName > and securityModel) can only be in a single group, which makes it > impossible to assign multiple "roles" to a user. If a principal can be a member of more than one group, the main obstacle is how to choose which group to use for access control decisions? > This means that in > the example above, I have to create a group "routing administrator > and data collector" and another group "web service manager and data > collector". Whch is no big deal, except how would you convey which group to use? > An alternative would be to give the principals "joe" > and "lara" two snmpSecurityNames and tell them that they are > responsible to select the right name for a given task. It works now, but it is ugly. > Please let me know if I have just overlooked something in RFC 2275. If > my interpretation of RFC 2275 is correct, I would argue that VACM > might work pretty well to protect small agents without many control > objects. Partially disagree. VACM was to protect small agents with limited resources, but not necessarily few control objects... What is needed is some way to deal with one-principal-in-many-groups issue. Do you add a group or a role to the PDU? Do you modify the matching algorithm (if so - how)? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Sat Jul 4 16:10:09 1998 Delivery-Date: Sat, 04 Jul 1998 16:10:10 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA15963 for ; Sat, 4 Jul 1998 16:10:08 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA27121 for ; Sat, 4 Jul 1998 16:12:29 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id NAA01198 for ; Sat, 4 Jul 1998 13:56:51 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id NAA12216 for ; Sat, 4 Jul 1998 13:56:49 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id TAA22372; Sat, 4 Jul 1998 19:56:47 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id TAA23362; Sat, 4 Jul 1998 19:56:42 +0200 Date: Sat, 4 Jul 1998 19:56:42 +0200 Message-Id: <199807041756.TAA23362@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: uri@watson.ibm.com CC: disman@nexen.com, snmpv3@tis.com In-reply-to: <9807031822.AA30164@watpub1.watson.ibm.com> (message from Uri Blumenthal on Fri, 3 Jul 1998 14:22:16 -0400 (EDT)) Subject: Re: VACM and DISMAN References: <9807031822.AA30164@watpub1.watson.ibm.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Uri Blumenthal writes: >> I started to look deeper into VACM and I finally realized that VACM >> is not ideal with regard to the RBAC model described above: >> >> 1) At first glance, it looks like if the VACM group can be used to >> describe roles. However, a given user (identified by securityName >> and securityModel) can only be in a single group, which makes it >> impossible to assign multiple "roles" to a user. Uri> If a principal can be a member of more than one group, the main Uri> obstacle is how to choose which group to use for access control Uri> decisions? Depends on the semantics you use. For DISMAN, something similar to the UNIX model would be suitable where the access rigths are actually the union of the access rights for each group. You simply loop over all the groups for a given pair and you return "access allowed" as soon as you got a positive match. If the loop completes without a match, you return "access denied". This is only an example. You can define more complicated functions. It is all a matter of what the semantics should be of being in multiple groups. >> This means that in the example above, I have to create a group >> "routing administrator and data collector" and another group "web >> service manager and data collector". Uri> Whch is no big deal, except how would you convey which group to Uri> use? You are right that a strict RBAC model would need to convey the role. I am not saying that we have to have a strict RBAC model. I am saying that a reasonable and scalable VACM configuration for the DISMAN Script MIB does not seem to be possible without creating several snmpSecurityNames for a user and lots of repeated entries in the view family tables. Sure, VACM can be modified to solve that problem. The SNMPv3 WG has to decide what to do. But you can be sure that I will be back when people want to gather operational experiences. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From maria@xedia.com Sun Jul 5 20:56:00 1998 Delivery-Date: Sun, 05 Jul 1998 20:56:01 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA08095 for ; Sun, 5 Jul 1998 20:55:59 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA01247 for ; Sun, 5 Jul 1998 20:58:21 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id SAA21239 for ; Sun, 5 Jul 1998 18:35:31 -0400 (EDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id SAA15522 for ; Sun, 5 Jul 1998 18:35:30 -0400 (EDT) Received: (kzm@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) id PAA22692; Sun, 5 Jul 1998 15:34:15 -0700 (PDT) From: Keith McCloghrie Message-Id: <199807052234.PAA22692@foxhound.cisco.com> Subject: Re: VACM and DISMAN To: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder) Date: Sun, 5 Jul 1998 15:34:15 -0700 (PDT) Cc: uri@watson.ibm.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: <199807041756.TAA23362@henkell.ibr.cs.tu-bs.de> from "Juergen Schoenwaelder" at Jul 4, 98 07:56:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >> I started to look deeper into VACM and I finally realized that VACM > >> is not ideal with regard to the RBAC model described above: > >> > >> 1) At first glance, it looks like if the VACM group can be used to > >> describe roles. However, a given user (identified by securityName > >> and securityModel) can only be in a single group, which makes it > >> impossible to assign multiple "roles" to a user. > > Uri> If a principal can be a member of more than one group, the main > Uri> obstacle is how to choose which group to use for access control > Uri> decisions? > > Depends on the semantics you use. For DISMAN, something similar to the > UNIX model would be suitable where the access rigths are actually the > union of the access rights for each group. You simply loop over all > the groups for a given pair and you > return "access allowed" as soon as you got a positive match. If the > loop completes without a match, you return "access denied". This loop will have a performance impact. It's already the case that a GetNext can take a significant amount of processing due to access-control checking; your loop has a multiplicative effect on that. An implementation could pre-compute the tree for each user, but that could require a significant amount of memory. > This is only an example. You can define more complicated functions. > It is all a matter of what the semantics should be of being in > multiple groups. I understand it was only an example. Hopefully, there's another example which has a lesser performance impact. Keith. From maria@xedia.com Mon Jul 6 06:27:15 1998 Delivery-Date: Mon, 06 Jul 1998 06:27:16 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA21627 for ; Mon, 6 Jul 1998 06:27:13 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA02022 for ; Mon, 6 Jul 1998 06:29:33 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id EAA28548 for ; Mon, 6 Jul 1998 04:29:10 -0400 (EDT) Received: from jyracomms.jyra.com (mail.jyra.com [193.117.248.2]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id EAA18182 for ; Mon, 6 Jul 1998 04:29:05 -0400 (EDT) Received: from jyrapete (192.168.42.72) by jyracomms.jyra.com (Worldmail 1.3.167); 6 Jul 1998 09:28:18 +0100 Received: by localhost with Microsoft MAPI; Mon, 6 Jul 1998 09:28:32 +0100 Message-ID: <01BDA8C0.7140C7E0.pete@jyra.com> From: Pete Lynch To: "'Juergen Schoenwaelder'" , "disman@nexen.com" , "snmpv3@tis.com" Subject: RE: VACM and DISMAN Date: Mon, 6 Jul 1998 09:28:29 +0100 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Can't the user/group identity stuff be done at the client: - leave VACM as it is. Have your client establish one user ID for each user or group - maintain the membership records at the client - try to access view under user id alone - try to access view under each group id in turn - cache "best" result for remainder of "management session" or until you feel the world may have changed That achieves the end result for the time being without changing SNMPv3. The user/group mapping may be done completely independently (for example, in an LDAP directory), reducing the complexity of security administration. That said, given that the performance penalty only really exists when a user is a member of many groups, and is thus capable of being worked around. I would be comfortable with changing the spec. Pete -----Original Message----- From: Juergen Schoenwaelder [SMTP:schoenw@ibr.cs.tu-bs.de] Sent: Friday, July 03, 1998 14:38 To: disman@nexen.com; snmpv3@tis.com Subject: VACM and DISMAN I am trying to find `good' VACM configurations for the Script MIB. And it turns out that this is more complex than I thought. What I would like to have for the Script MIB is what people usually call "role based access control" (RBAC): A user (a snmpSecurityName in RFC 2271 speak) maps to one of more roles he has (e.g. routing administrator, web service manager, data collector) and each role has associated "transactions" that can be called in order to fulfill the tasks for a given role. Transactions are either SNMP operations (in case of traditional agents) or more complex management functions implemented via scripts. It would be cool if VACM could be configured so that we get something pretty similar to the RBAC model described above. In an ideal world, the security administrator would configure VACM so that it is pretty easy to assign user "joe" the role of a "routing administrator and data collector" and user "lara" the role of a "web service manager and data collector". I started to look deeper into VACM and I finally realized that VACM is not ideal with regard to the RBAC model described above: 1) At first glance, it looks like if the VACM group can be used to describe roles. However, a given user (identified by securityName and securityModel) can only be in a single group, which makes it impossible to assign multiple "roles" to a user. This means that in the example above, I have to create a group "routing administrator and data collector" and another group "web service manager and data collector". An alternative would be to give the principals "joe" and "lara" two snmpSecurityNames and tell them that they are responsible to select the right name for a given task. 2) Having to define lots of groups would not be that bad if one could at least share common view tree family definitions. However, VACM does not allow to do that. So, in the example, I would have to duplicate the tree family entries needed to be a data collector for the groups "routing administrator and data collector" and "web service manager and data collector", which does not look very attractive. Things get really worse if you have a DISMAN environment and you want to give users their own "sandboxes" where they can install scripts of expressions to be evalutated. You either end up doing a one-to-one mapping between securityNames and VACM groups (thus rendering VACM groups useless and duplicating entries in the tree family table) or you hand out another securityName which is used to select the private "sandbox". Please let me know if I have just overlooked something in RFC 2275. If my interpretation of RFC 2275 is correct, I would argue that VACM might work pretty well to protect small agents without many control objects. But VACM has a pretty serious scalability problems for agents where you need different but similar levels of access control of multiple users, like the Script MIB. Are there already fielded implementations of VACM? Are there any experiences or guidelines how to use it without creating huge MIB tables? Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From maria@xedia.com Mon Jul 6 07:36:59 1998 Delivery-Date: Mon, 06 Jul 1998 07:36:59 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA21897 for ; Mon, 6 Jul 1998 07:36:59 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA02177 for ; Mon, 6 Jul 1998 07:39:00 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id EAA28576 for ; Mon, 6 Jul 1998 04:33:54 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id EAA00750 for ; Mon, 6 Jul 1998 04:33:52 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id KAA03446; Mon, 6 Jul 1998 10:33:40 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA10366; Mon, 6 Jul 1998 10:33:40 +0200 Date: Mon, 6 Jul 1998 10:33:40 +0200 Message-Id: <199807060833.KAA10366@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: kzm@cisco.com CC: disman@nexen.com, snmpv3@tis.com In-reply-to: <199807052234.PAA22692@foxhound.cisco.com> (message from Keith McCloghrie on Sun, 5 Jul 1998 15:34:15 -0700 (PDT)) Subject: Re: VACM and DISMAN References: <199807052234.PAA22692@foxhound.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Keith McCloghrie writes: Keith> This loop will have a performance impact. It's already the Keith> case that a GetNext can take a significant amount of processing Keith> due to access-control checking; your loop has a multiplicative Keith> effect on that. An implementation could pre-compute the tree Keith> for each user, but that could require a significant amount of Keith> memory. I disaggree that allowiong a user to be a member in multiple groups has a multiplicative effect on the getnext/getbulk performance. VACM currently requires the security administrator to configure the pre-computed trees for all group combinations. This means lots of VACM tree family entries while the time to do access control checking (which is essentially the number of discarded getnexts/getbulks) will be roughly the same. The performance penalty is a function of the access control rules in place. It is IMHO only marginally influenced by the scheme you use to describe the access control rules. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From maria@xedia.com Mon Jul 6 15:36:20 1998 Delivery-Date: Mon, 06 Jul 1998 15:36:21 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28501 for ; Mon, 6 Jul 1998 15:36:20 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04900 for ; Mon, 6 Jul 1998 15:38:41 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id NAA11196 for ; Mon, 6 Jul 1998 13:19:03 -0400 (EDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id NAA02267 for ; Mon, 6 Jul 1998 13:19:02 -0400 (EDT) Received: (kzm@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) id KAA11219; Mon, 6 Jul 1998 10:18:00 -0700 (PDT) From: Keith McCloghrie Message-Id: <199807061718.KAA11219@foxhound.cisco.com> Subject: Re: VACM and DISMAN To: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder) Date: Mon, 6 Jul 1998 10:17:59 -0700 (PDT) Cc: kzm@cisco.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: <199807060833.KAA10366@henkell.ibr.cs.tu-bs.de> from "Juergen Schoenwaelder" at Jul 6, 98 10:33:40 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Keith> This loop will have a performance impact. It's already the > Keith> case that a GetNext can take a significant amount of processing > Keith> due to access-control checking; your loop has a multiplicative > Keith> effect on that. An implementation could pre-compute the tree > Keith> for each user, but that could require a significant amount of > Keith> memory. > > I disaggree that allowiong a user to be a member in multiple groups > has a multiplicative effect on the getnext/getbulk performance. As I understood your proposal, each iteration of the "loop" that you proposed was to test a particular group's access privileges, so that the number of times around the loop is the number of groups that a user is in, i.e., denying an access for a user in N groups is N times as much checking as denying a user in one group. That's what I meant by multiplicative. This is independent of GetNext/GetBulk. However, N times a larger number is a larger absolute/more noticeable increase, and so it's GetNext performance which appears to suffer most. Did I misunderstand ? > VACM currently requires the security administrator to configure the > pre-computed trees for all group combinations. This means lots of VACM > tree family entries while the time to do access control checking > (which is essentially the number of discarded getnexts/getbulks) will > be roughly the same. > > The performance penalty is a function of the access control rules in > place. It is IMHO only marginally influenced by the scheme you use to > describe the access control rules. Right, putting users in multiple groups has performance implications, which is the point I was trying to make in my original message. Keith. From maria@xedia.com Mon Jul 6 16:50:50 1998 Delivery-Date: Mon, 06 Jul 1998 16:50:50 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA00480 for ; Mon, 6 Jul 1998 16:50:49 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05288 for ; Mon, 6 Jul 1998 16:53:11 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id OAA12926 for ; Mon, 6 Jul 1998 14:03:50 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA21609 for ; Mon, 6 Jul 1998 14:03:49 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id UAA21615; Mon, 6 Jul 1998 20:03:47 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id UAA24883; Mon, 6 Jul 1998 20:03:46 +0200 Date: Mon, 6 Jul 1998 20:03:46 +0200 Message-Id: <199807061803.UAA24883@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: kzm@cisco.com CC: disman@nexen.com, snmpv3@tis.com In-reply-to: <199807061718.KAA11219@foxhound.cisco.com> (message from Keith McCloghrie on Mon, 6 Jul 1998 10:17:59 -0700 (PDT)) Subject: Re: VACM and DISMAN References: <199807061718.KAA11219@foxhound.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Keith McCloghrie writes: Keith> As I understood your proposal, each iteration of the "loop" Keith> that you proposed was to test a particular group's access Keith> privileges, so that the number of times around the loop is the Keith> number of groups that a user is in, i.e., denying an access for Keith> a user in N groups is N times as much checking as denying a Keith> user in one group. That's what I meant by multiplicative. Keith> This is independent of GetNext/GetBulk. However, N times a Keith> larger number is a larger absolute/more noticeable increase, Keith> and so it's GetNext performance which appears to suffer most. You are right that a user in N groups requires to repeat the check N times in the worst case. So you will have N * M checks in the worst case if the average number of subtrees defined for each group is M. However, I argue that without having this feature, people will be forced to create VACM configurations with N * M subtree definitions for a given user since you can not share definitions. So you will gain nothing in the isAccessAllowed() function (you still need to do N * M tests in the worst case) but you will pay be a high price in terms of the total number of VACM MIB entries needed and the complexity a security administrator has to deal with. I would also expect that the number of discarded method function calls during GetNext processing defines the performance bottleneck and not the number of access control rules you have to check. (The later one is a tight loop while the method function calls very likely include costly interactions with a hardware device or a subagent.) And the number of discarded method function calls depends on how simple or complex the access control configuration is and how intelligent the agent is to skip method function calls that are known to be out of scope with regard to the access control rules. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From maria@xedia.com Mon Jul 6 21:57:10 1998 Delivery-Date: Mon, 06 Jul 1998 21:57:11 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA03363 for ; Mon, 6 Jul 1998 21:57:10 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA06215 for ; Mon, 6 Jul 1998 21:59:30 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id UAA21810 for ; Mon, 6 Jul 1998 20:15:49 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id UAA03711 for ; Mon, 6 Jul 1998 20:15:48 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA21152 for ; Mon, 6 Jul 1998 19:15:46 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021147; Mon, 6 Jul 98 19:15:42 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA22729 for ; Mon, 6 Jul 1998 19:15:09 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma022668; Mon, 6 Jul 98 19:14:51 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA02490; Mon, 6 Jul 1998 19:15:21 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17489; Mon, 6 Jul 1998 17:15:20 -0700 (PDT) Date: Mon, 6 Jul 1998 17:15:20 -0700 (PDT) From: Randy Presuhn Message-Id: <199807070015.RAA17489@dorothy.bmc.com> To: disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi- > Date: Mon, 6 Jul 1998 20:03:46 +0200 > From: Juergen Schoenwaelder > To: kzm@cisco.com > CC: disman@nexen.com, snmpv3@tis.com > Subject: Re: VACM and DISMAN > References: <199807061718.KAA11219@foxhound.cisco.com> > > > >>>>> Keith McCloghrie writes: > > Keith> As I understood your proposal, each iteration of the "loop" > Keith> that you proposed was to test a particular group's access > Keith> privileges, so that the number of times around the loop is the > Keith> number of groups that a user is in, i.e., denying an access for > Keith> a user in N groups is N times as much checking as denying a > Keith> user in one group. That's what I meant by multiplicative. > Keith> This is independent of GetNext/GetBulk. However, N times a > Keith> larger number is a larger absolute/more noticeable increase, > Keith> and so it's GetNext performance which appears to suffer most. > > You are right that a user in N groups requires to repeat the check N > times in the worst case. So you will have N * M checks in the worst > case if the average number of subtrees defined for each group is M. > > However, I argue that without having this feature, people will be > forced to create VACM configurations with N * M subtree definitions > for a given user since you can not share definitions. So you will gain > nothing in the isAccessAllowed() function (you still need to do N * M > tests in the worst case) but you will pay be a high price in terms of > the total number of VACM MIB entries needed and the complexity a > security administrator has to deal with. ... It seems like the other appropach you outlined makes more sense, where the administrator defines for each user a set of _in_ securityNames with the supporting USM entries and vacmSecurityToGroupEntries. In this case, one would only need groups and avoid excessive duplication of subtree information. The downside is that the command generator would have to be explicit about the role in which the user is acting, and the security administrator would need to be aware of those roles. This is probably not a bad thing. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Tue Jul 7 11:20:32 1998 Delivery-Date: Tue, 07 Jul 1998 11:20:33 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04252 for ; Tue, 7 Jul 1998 11:20:27 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03186 for ; Tue, 7 Jul 1998 11:22:42 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id IAA00926 for ; Tue, 7 Jul 1998 08:05:15 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id IAA04831 for ; Tue, 7 Jul 1998 08:05:15 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQewzo16983; Tue, 7 Jul 1998 08:05:13 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQewzo24798; Tue, 7 Jul 1998 08:05:12 -0400 (EDT) Message-Id: To: "Bert Wijnen" cc: schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 07 Jul 1998 11:50:54 +0700." <199807070946.FAA18537@relay.hq.tis.com> Date: Tue, 07 Jul 1998 08:05:12 -0400 From: "Mike O'Dell" for my money (and UUNET's), we believe that time-varying role-based security policy is the only way you deal with humans, which is very distinct from network elements. for example, a network operator on duty may have significant access rights to test and reconfigure a network element, but when the person goes off-shift, they must lose those rights. the only way to do this rationally is to do the mapping of person-role-time-rights *mostly* in NMS software which sits between the operator and the network elements. the machinery in SNMPv3 supports identity-rights mappings, and that is sufficient given the interposed NMS software which uses a set of identities instantiated in the network elements to map a given person performing a specific role at a certain time into a set of required access rights. Note that the "time" part is *only* done in the NMS - that's waaaaay too messy to put in network elements because of things like time zones, shift changes, etc, etc. while one can describe all kinds of access control policies, the question is one of partitioning - how much is supported directly by the network element and how much by layered NMS functionality. Until proven otherwise, we are proceeding with the firm belief that what's currently in SNMPv3 is enough mechanism upon which to build the complex policy machinery we need using external software, and that making the mechanism inside the network elements more complex is probably at the point of diminishing returns, for all the reasons Bert mentioned. -mo From maria@xedia.com Wed Jul 15 16:35:27 1998 Delivery-Date: Wed, 15 Jul 1998 16:35:28 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA25107 for ; Wed, 15 Jul 1998 16:35:26 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA17268 for ; Wed, 15 Jul 1998 16:35:25 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id NAA01194 for ; Wed, 15 Jul 1998 13:55:25 -0400 (EDT) Received: from ALPHA1.RESTON.MCI.NET (alpha1.Reston.mci.net [204.70.128.80]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA10595 for ; Wed, 15 Jul 1998 14:40:33 -0400 (EDT) Received: from rfrye.reston.mci.net ([166.45.4.242]) by ALPHA1.RESTON.MCI.NET (PMDF V5.2-22 #3857) with SMTP id <01IZFLPOBVHQ00022O@ALPHA1.RESTON.MCI.NET> for disman@nexen.com; Wed, 15 Jul 1998 14:40:20 EDT Date: Wed, 15 Jul 1998 13:56:09 -0400 From: Rob Frye Subject: Re: VACM and DISMAN In-reply-to: X-Sender: rfrye@alpha1.reston.mci.net To: "Mike O'Dell" , Bert Wijnen Cc: disman@nexen.com, snmpv3@tis.com Message-id: MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" References: <"Your message of Tue, 07 Jul 1998 11:50:54 +0700." <199807070946.FAA18537@relay.hq.tis.com> At 08:05 AM 7/7/98 , Mike O'Dell wrote: >for my money (and UUNET's), we believe that time-varying >role-based security policy is the only way you deal with >humans, which is very distinct from network elements. Agreed, Mike. Bert Wijnen said: >I know that SNMpv3 allows me to add/delete users via SNMP. >Now imagine, that I get a new employee Joe. WHat do I do? >Do I want to add user Joe to all my SNMP engines (say some 10 or 100 >thousand)? That may take a while before it is complete. >Then... after a few months, Joe decides to go and work somewhere else. >Do I then delete user Joe at those 10 or 100 thousand SNMP engines? > >I would rather have a NMS that internally uses SNMP-users in the form >of "operator-role", "networ-admin-role", "senior-role", "junior-role", >"security-admin-role" and so on. I would then want the NMS to >let me add a user Joe and tell the NMS that Joe gets to work with >the "junior-role" for now... maybe later as the "senior-role" once he >proves he is good and can be trusted. and Mike: >the only way to do this rationally is to do the mapping of >person-role-time-rights *mostly* in NMS software which sits >between the operator and the network elements. One problem with relying on the NMS software to translate "joe" to "junior-role", "operator-role" or "senior-role" is that it is also doing that for users "fred", "sam", "sally" and the rest. Unless the NMS is the only way that these users can and do access the network elements (not counting your 3rd-level network gurus who telnet in when all else fails), you have somewhat of an audit trail problem. If the agent records the fact that "senior-role" changed X to Y at time T, and someone is pulling out their hair trying to figure out why the network went down at time T, it's awfully hard to find out it was "joe" rather than "sam". And for a "real network-manager" in a BIG company (per Bert), the ability to know who changed what when is important. I agree that the NMS needs to handle the time domain aspects, and that the roles and individuals are known there. But I don't like having all users mapped to roles, where only the role-level security is known to the Agents. The configuration complexities have been noted by Juergen, T. Max, Keith and others; my reading says its a fairly close tradeoff, with more and more complexity using group mappings in a fluid environment. -- Rob. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rob Frye ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sr. Network Management Architect Email: rfrye@mci.net MCI Telecommunications Corp. Phone: +1-703-715-7225/V272-7225 2100 Reston Parkway, Suite 600 Fax: +1-703-715-7436 Reston, VA 20191 Pager: +1-888-270-1537 ~~~~~~~~~~~~~~~~~~~~~~~~Procrastinate Later~~~~~~~~~~~~~~~~~~~~~~~~ From maria@xedia.com Wed Jul 15 16:36:09 1998 Delivery-Date: Wed, 15 Jul 1998 16:36:09 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA25122 for ; Wed, 15 Jul 1998 16:36:08 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA17271 for ; Wed, 15 Jul 1998 16:36:07 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id OAA01478 for ; Wed, 15 Jul 1998 14:04:36 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id OAA07970 for ; Wed, 15 Jul 1998 14:50:07 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeyed17648; Wed, 15 Jul 1998 14:50:05 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQeyed26145; Wed, 15 Jul 1998 14:50:03 -0400 (EDT) Message-Id: To: Rob Frye cc: "Mike O'Dell" , Bert Wijnen , disman@nexen.com, snmpv3@tis.com, mo@UU.NET Subject: Re: VACM and DISMAN In-reply-to: Your message of "Wed, 15 Jul 1998 13:56:09 EDT." Date: Wed, 15 Jul 1998 14:50:03 -0400 From: "Mike O'Dell" if the NMS is doing the authority mapping and not keeping audit trails, the implementation is deeply defective -mo From maria@xedia.com Wed Jul 15 17:32:11 1998 Delivery-Date: Wed, 15 Jul 1998 17:32:11 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA26342 for ; Wed, 15 Jul 1998 17:32:11 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA17582 for ; Wed, 15 Jul 1998 17:32:08 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id OAA02411 for ; Wed, 15 Jul 1998 14:32:38 -0400 (EDT) Received: from ALPHA1.RESTON.MCI.NET (alpha1.Reston.mci.net [204.70.128.80]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA10970 for ; Wed, 15 Jul 1998 15:19:18 -0400 (EDT) Received: from rfrye.reston.mci.net ([166.45.4.242]) by ALPHA1.RESTON.MCI.NET (PMDF V5.2-22 #3857) with SMTP id <01IZFN302LKM000288@ALPHA1.RESTON.MCI.NET> for disman@nexen.com; Wed, 15 Jul 1998 15:19:16 EDT Date: Wed, 15 Jul 1998 15:09:49 -0400 From: Rob Frye Subject: Re: VACM and DISMAN X-Sender: rfrye@alpha1.reston.mci.net To: "Mike O'Dell" Cc: "Mike O'Dell" , Bert Wijnen , disman@nexen.com, snmpv3@tis.com, mo@UU.NET Message-id: <01IZFN303GNS000288@ALPHA1.RESTON.MCI.NET> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" At 02:50 PM 7/15/98 , Mike O'Dell wrote: >if the NMS is doing the authority mapping and not keeping >audit trails, the implementation is deeply defective Agreed. The problem is >Unless the NMS is the only way that these users can >and do access the network elements... If there are multiple independent systems, then there needs to be a mechanism to consolidate the audit info from them all. -- Rob. From maria@xedia.com Wed Jul 15 19:17:44 1998 Delivery-Date: Wed, 15 Jul 1998 19:17:44 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA27922 for ; Wed, 15 Jul 1998 19:17:43 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA17995 for ; Wed, 15 Jul 1998 19:17:38 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id QAA06063 for ; Wed, 15 Jul 1998 16:48:12 -0400 (EDT) Received: from apollo.scram.de (apollo.scram.de [194.162.91.67]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA11894 for ; Wed, 15 Jul 1998 17:40:09 -0400 (EDT) Received: from neptun.nwe.de ([192.168.99.20]) by apollo.scram.de (8.9.0/8.9.0) with ESMTP id XAA17471; Wed, 15 Jul 1998 23:40:12 +0200 (MESZ) Received: from localhost (localhost [[UNIX: localhost]]) by neptun.nwe.de (8.8.8/8.8.8) with SMTP id XAA14226; Wed, 15 Jul 1998 23:40:01 +0200 (CEST) Date: Wed, 15 Jul 1998 23:40:00 +0200 (CEST) From: Jochen Friedrich X-Sender: jochen@neptun.nwe.de To: "Mike O'Dell" cc: Rob Frye , Bert Wijnen , disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Jul 1998, Mike O'Dell wrote: > if the NMS is doing the authority mapping and not keeping > audit trails, the implementation is deeply defective Sure. But now these NMS audit trails become very important. If they get lost (either by accident or on purpose), it's no longer possible to trace back to the original user. In the case of the agents doing the mapping, it's much harder to manipulate all audit trails. Jochen From maria@xedia.com Wed Jul 15 19:23:00 1998 Delivery-Date: Wed, 15 Jul 1998 19:23:00 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA27956 for ; Wed, 15 Jul 1998 19:23:00 -0400 (EDT) Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA18011 for ; Wed, 15 Jul 1998 19:22:55 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id QAA06060 for ; Wed, 15 Jul 1998 16:48:02 -0400 (EDT) Received: from relay8.uu.net (relay8.uu.net [192.48.96.84]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA11878 for ; Wed, 15 Jul 1998 17:40:00 -0400 (EDT) Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeyeo13848; Wed, 15 Jul 1998 17:39:53 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQeyeo07527; Wed, 15 Jul 1998 17:39:52 -0400 (EDT) Message-Id: To: Rob Frye cc: "Mike O'Dell" , Bert Wijnen , disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Wed, 15 Jul 1998 15:09:49 EDT." <01IZFN303GNS000288@ALPHA1.RESTON.MCI.NET> Date: Wed, 15 Jul 1998 17:39:52 -0400 From: "Mike O'Dell" "Doctor! Doctor! It hurts when I do this!" "Then don't do that!" -mo From aileen@thumper.bellcore.com Thu Jul 16 16:59:39 1998 Delivery-Date: Thu, 16 Jul 1998 16:59:39 -0400 Return-Path: aileen@thumper.bellcore.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA22082 for ; Thu, 16 Jul 1998 16:59:38 -0400 (EDT) Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA23067 for ; Thu, 16 Jul 1998 16:59:34 -0400 (EDT) Received: from bulkrate.cc.bellcore.com (bulkrate.cc.bellcore.com [128.96.96.96]) by thumper.bellcore.com (8.8.8/8.8.8) with SMTP id PAA02928 for ; Thu, 16 Jul 1998 15:33:48 -0400 (EDT) Received: from shultz.argon.com by bulkrate.cc.bellcore.com with SMTP id AA14605 (5.67b/IDA-1.5 for ); Thu, 16 Jul 1998 15:40:01 -0400 Received: from aruba (aruba.argon.com [208.234.161.60]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id PAA04067; Thu, 16 Jul 1998 15:24:39 -0400 (EDT) Message-Id: <3.0.32.19980716152359.00adb560@shultz.argon.com> X-Sender: kchapman@shultz.argon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 16 Jul 1998 15:24:07 -0400 To: Kaj Tesink , atommib@thumper.bellcore.com From: Ken Chapman Subject: Re: draft to RFC ? Cc: snmpv3@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I have an issue that is more an SNMP SMI than an ATM issue. I noticed that RFC 1695 has a DEFVAL for most of the OBJECT-TYPEs that are of SYNTAX RowStatus. (And this persists into atm1ng-04.) This, IMHO, is broken. It is defeating much of the semantics of RowStatus. For example, if an NMS sends a set to an agent with just one varbind to any one of the columns in a atmTrafficDescrParamTable for a row that does not exist, then the row will be created and activated, and no atmTrafficDescrRowStatus is needed (since it has a DEFVAL of active). I would like to know if that was the intent. Do others think this is "broken"? If it is broken then it should be fixed *before going to RFC*. There are several options; here are a couple: 1) remove the DEFVALs. 2) deprecate the RowStatus variables, add new variables using a new textual convention that defines the intended behavior. If the WG votes that the behavoir is ok, then the behavior should be correctly documenting *before going to RFC*. In either case, I don't think the draft should go out the way it is. Ken ================================================ Ken Chapman Argon Networks, Inc. tel: 978-486-0665 x146 25 Porter Road fax: 978-486-9379 Littleton, MA 01460 mailto:KChapman@Argon.com http://www.Argon.com ================================================ From aileen@thumper.bellcore.com Thu Jul 16 19:10:39 1998 Delivery-Date: Thu, 16 Jul 1998 19:10:40 -0400 Return-Path: aileen@thumper.bellcore.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23444 for ; Thu, 16 Jul 1998 19:10:39 -0400 (EDT) Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA23771 for ; Thu, 16 Jul 1998 19:10:30 -0400 (EDT) Received: from ALPHA1.RESTON.MCI.NET (alpha1.Reston.mci.net [204.70.128.80]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id RAA11446 for ; Thu, 16 Jul 1998 17:53:45 -0400 (EDT) Received: from rfrye.reston.mci.net ([166.45.4.242]) by ALPHA1.RESTON.MCI.NET (PMDF V5.2-22 #3857) with SMTP id <01IZH6R54LCY0003EG@ALPHA1.RESTON.MCI.NET> for atommib@thumper.bellcore.com; Thu, 16 Jul 1998 17:53:10 EDT Date: Thu, 16 Jul 1998 17:47:17 -0400 From: Rob Frye Subject: Re: draft to RFC ? In-reply-to: <3.0.32.19980716152359.00adb560@shultz.argon.com> X-Sender: rfrye@alpha1.reston.mci.net To: Ken Chapman , Kaj Tesink , atommib@thumper.bellcore.com Cc: snmpv3@tis.com Message-id: <01IZH6R55EK40003EG@ALPHA1.RESTON.MCI.NET> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" At 03:24 PM 7/16/98 , Ken Chapman wrote: >I have an issue that is more an SNMP SMI than an ATM issue. > >I noticed that RFC 1695 has a DEFVAL for most of the OBJECT-TYPEs >that are of SYNTAX RowStatus. (And this persists into atm1ng-04.) >This, IMHO, is broken. It is defeating much of the semantics of RowStatus. >For example, if an NMS sends a set to an agent with just one >varbind to any one of the columns in a atmTrafficDescrParamTable for >a row that does not exist, then the row will be created and activated, >and no atmTrafficDescrRowStatus is needed (since it has a DEFVAL of active). > >I would like to know if that was the intent. > >Do others think this is "broken"? This is permitted in RFC 1903 and an example given in Sec 7.10 of RFC 1902. Care must be taken to ensure that if "active" or "createAndGo" are the DEFVAL values chosen, then the DEFVALs of other column variables must "make protocol sense". If a row could be created and active by leaving out certain columns, then the DEFVAL for a RowStatus variable should *not* be "active" or "createAndGo". -- Rob. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rob Frye ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sr. Network Management Architect Email: rfrye@mci.net MCI Telecommunications Corp. Phone: +1-703-715-7225/V272-7225 2100 Reston Parkway, Suite 600 Fax: +1-703-715-7436 Reston, VA 20191 Pager: +1-888-270-1537 ~~~~~~~~~~~~~~~~~~~~~~~~Procrastinate Later~~~~~~~~~~~~~~~~~~~~~~~~ From adm Sat Jul 18 10:39:11 1998 Delivery-Date: Sat, 18 Jul 1998 10:49:30 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id KAA29858 for ietf-123-outbound.10@ietf.org; Sat, 18 Jul 1998 10:35:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA28833; Sat, 18 Jul 1998 09:52:23 -0400 (EDT) Message-Id: <199807181352.JAA28833@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpv3@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-intro-00.txt Date: Sat, 18 Jul 1998 09:52:23 -0400 Sender: scoya@ns.cnri.reston.va.us --NextPart A New 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 : Introduction to Version 3 of the Internet Network Management Framework Author(s) : J. Case, R. Mundy, D. Partain, B. Stewart Filename : draft-ietf-snmpv3-intro-00.txt Pages : 21 Date : 17-Jul-98 The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-standard Management Framework (SNMPv1) and the second Internet-standard Management Framework (SNMPv2). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpv3-intro-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-snmpv3-intro-00.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpv3-intro-00.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980717091926.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-intro-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-intro-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980717091926.I-D@ietf.org> --OtherAccess-- --NextPart-- From maria@xedia.com Sun Jul 19 23:51:24 1998 Delivery-Date: Sun, 19 Jul 1998 23:51:25 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA14368 for ; Sun, 19 Jul 1998 23:51:23 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA02063 for ; Sun, 19 Jul 1998 23:51:17 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id TAA02723 for ; Sun, 19 Jul 1998 19:26:19 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id WAA19453 for ; Sun, 19 Jul 1998 22:04:58 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id WAA28282; Sun, 19 Jul 1998 22:03:36 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id WAA06288; Sun, 19 Jul 1998 22:03:35 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA13434; Sun, 19 Jul 1998 22:03:34 -0400 From: Uri Blumenthal Message-Id: <9807200203.AA13434@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: jochen+snmp3@scram.de (Jochen Friedrich) Date: Sun, 19 Jul 1998 22:03:33 -0400 (EDT) Cc: mo@UU.NET, rfrye@mci.net, WIJNEN@VNET.IBM.COM, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Jochen Friedrich" at Jul 15, 98 11:40:00 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Jochen Friedrich says: > > if the NMS is doing the authority mapping and not keeping > > audit trails, the implementation is deeply defective No argument. > Sure. But now these NMS audit trails become very important. If they get > lost (either by accident or on purpose), it's no longer possible to trace > back to the original user. > In the case of the agents doing the mapping, it's much harder to > manipulate all audit trails. It is worse than that. A sound security approach is for the OWNER of (or the CONTROLLER of the access to) the information to do the logging - otherwise it's like expecting a rogue banker to keep an audit log of all the cheats he'd done... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From aileen@thumper.bellcore.com Mon Jul 20 10:25:57 1998 Delivery-Date: Mon, 20 Jul 1998 10:25:57 -0400 Return-Path: aileen@thumper.bellcore.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA17200 for ; Mon, 20 Jul 1998 10:25:56 -0400 (EDT) Received: from thumper.bellcore.com ([128.96.41.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA03717 for ; Mon, 20 Jul 1998 10:25:47 -0400 (EDT) Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id IAA08967 for ; Mon, 20 Jul 1998 08:51:59 -0400 (EDT) Received: from aruba (aruba.argon.com [208.234.161.60]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id IAA16709; Mon, 20 Jul 1998 08:51:17 -0400 (EDT) Message-Id: <3.0.32.19980720085033.0094b910@shultz.argon.com> X-Sender: kchapman@shultz.argon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 20 Jul 1998 08:50:36 -0400 To: Rob Frye , Kaj Tesink , atommib@thumper.bellcore.com From: Ken Chapman Subject: Re: draft to RFC ? Cc: snmpv3@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Rob, Thanks for the "clarification". At 05:47 PM 7/16/98 -0400, Rob Frye wrote: >At 03:24 PM 7/16/98 , Ken Chapman wrote: >>I have an issue that is more an SNMP SMI than an ATM issue. >> >>I noticed that RFC 1695 has a DEFVAL for most of the OBJECT-TYPEs >>that are of SYNTAX RowStatus. (And this persists into atm1ng-04.) >>This, IMHO, is broken. It is defeating much of the semantics of RowStatus. >>For example, if an NMS sends a set to an agent with just one >>varbind to any one of the columns in a atmTrafficDescrParamTable for >>a row that does not exist, then the row will be created and activated, >>and no atmTrafficDescrRowStatus is needed (since it has a DEFVAL of active). >> >>I would like to know if that was the intent. >> >>Do others think this is "broken"? > >This is permitted in RFC 1903 I found it (I think)! It is not obvious, but I see in note (4) to the state table on page 9 that its ok "because the agent chosses to create the isnatance." It would have been nice to have mentioned that providing a DEFVAL in the MIB definition implies that the agent should behave that way, since it only mentions going to states B or C and not to D, which the DEFVAL can force. IMHO this could use a little clarification in a future release of RFC 1903. >and an example given in Sec 7.10 of RFC 1902. I had missed this, too. Thanks. I guess that means it is permitted! :^) I withdraw my issue. (Note: It wouldn't hurt to add an explanation in the DESCRIPTION clauses of the RowStatus varbinds that have a DEFVAL caluse as to what is the expected behavior.) Ken >Care must be taken to ensure that >if "active" or "createAndGo" are the DEFVAL values chosen, >then the DEFVALs of other column variables must >"make protocol sense". If a row could be created >and active by leaving out certain columns, then the >DEFVAL for a RowStatus variable should *not* be "active" >or "createAndGo". > >-- Rob. > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rob Frye ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Sr. Network Management Architect Email: rfrye@mci.net >MCI Telecommunications Corp. Phone: +1-703-715-7225/V272-7225 >2100 Reston Parkway, Suite 600 Fax: +1-703-715-7436 >Reston, VA 20191 Pager: +1-888-270-1537 >~~~~~~~~~~~~~~~~~~~~~~~~Procrastinate Later~~~~~~~~~~~~~~~~~~~~~~~~ > > ================================================ Ken Chapman Argon Networks, Inc. tel: 978-486-0665 x146 25 Porter Road fax: 978-486-9379 Littleton, MA 01460 mailto:KChapman@Argon.com http://www.Argon.com ================================================ From maria@xedia.com Tue Jul 21 00:13:25 1998 Delivery-Date: Tue, 21 Jul 1998 00:13:25 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA01988 for ; Tue, 21 Jul 1998 00:13:24 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA08227 for ; Tue, 21 Jul 1998 00:13:15 -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 TAA02352 for ; Mon, 20 Jul 1998 19:52:50 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id WAA16067 for ; Mon, 20 Jul 1998 22:31:45 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id WAA16616; Mon, 20 Jul 1998 22:31:41 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id WAA12212; Mon, 20 Jul 1998 22:31:40 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA30262; Mon, 20 Jul 1998 22:31:40 -0400 From: Uri Blumenthal Message-Id: <9807210231.AA30262@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder) Date: Mon, 20 Jul 1998 22:31:39 -0400 (EDT) Cc: rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: <199807070904.LAA01088@henkell.ibr.cs.tu-bs.de> from "Juergen Schoenwaelder" at Jul 7, 98 11:04:37 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Juergen Schoenwaelder says: > .......I also have concerns that management applications will provide > the support necessary to make this work in practice (that is providing > the intelligence to automatically select the "right" identities). It is hardly possible [meaning that a correctly working and properly secure management application that fits the bill isn't likely to be created.] > The lesson I have learned from party-based SNMPv2 is that the stuff has > to be damn simple to use and that we should not rely on assistance from > tools to get the thing configured and running. Can't agree more. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 00:15:16 1998 Delivery-Date: Tue, 21 Jul 1998 00:15:16 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA01997 for ; Tue, 21 Jul 1998 00:15:16 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA08237 for ; Tue, 21 Jul 1998 00:15:06 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id TAA02320 for ; Mon, 20 Jul 1998 19:46:05 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id WAA23342 for ; Mon, 20 Jul 1998 22:24:59 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id WAA11068; Mon, 20 Jul 1998 22:24:45 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id WAA09962; Mon, 20 Jul 1998 22:24:44 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA45646; Mon, 20 Jul 1998 22:24:43 -0400 From: Uri Blumenthal Message-Id: <9807210224.AA45646@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: rpresuhn@dorothy.bmc.com (Randy Presuhn) Date: Mon, 20 Jul 1998 22:24:43 -0400 (EDT) Cc: disman@nexen.com, snmpv3@tis.com In-Reply-To: <199807070015.RAA17489@dorothy.bmc.com> from "Randy Presuhn" at Jul 6, 98 05:15:20 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Randy Presuhn says: > It seems like the other appropach you outlined makes more > sense, where the administrator defines for each user a set of > _in_ securityNames with the supporting USM entries and > vacmSecurityToGroupEntries. In this case, one would only need > groups and avoid excessive duplication of subtree information. The > downside is that the command generator would have to be explicit about > the role in which the user is acting, and the security administrator > would need to be aware of those roles. This is probably not a bad thing. 1. "Role-based" authorization models usually have separate [independent] policies for roles known AND for users known. Each decision is made based on what the CONJUNCTION of the User and Role permissions are. For example: A role "operator" has access rights X. A role "netadmin" has access rights Y. A user "randy" has general access rights Z. So when a request comes from "randy-in_role-operator", the access rights to check it against will be what is included in the set "X AND Z". Whatever is not included in BOTH will automatically be forbidden. The main reason for role-based models is to be able to modify roles independently from principals and vs. versa. It is NOT easy to design and administer a good role-based access control model. 2. It usually is a very bad idea to allow the receiving entity to guess what role to apply, especially so if the guessing algorithm is "go for the mightiest access". Those who know me, have already figured out that I'm tempted to use a much stronger word than just "bad". 3. Sometimes when people say "role-based", what they really mean is: We want to have just a few access control policies, like "any operator can do X, any netadmin can do Y and any superuser can do Z", but we want to maintain a detailed log of who-did-what, including name-and-serial-number. So the "principal" ID goes into the log, but the access control is decided using the "role" rather than the "principal". In any case, the request MUST carry the "role" or the "group" tag in it, for anything role-based to make any sense at all. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 02:06:03 1998 Delivery-Date: Tue, 21 Jul 1998 02:06:03 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA02465 for ; Tue, 21 Jul 1998 02:06:02 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA08491 for ; Tue, 21 Jul 1998 02:05:54 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id VAA03817 for ; Mon, 20 Jul 1998 21:48:45 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id AAA23562 for ; Tue, 21 Jul 1998 00:27:41 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id AAA28334; Tue, 21 Jul 1998 00:27:39 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id AAA12160; Tue, 21 Jul 1998 00:27:38 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA28038; Tue, 21 Jul 1998 00:27:38 -0400 From: Uri Blumenthal Message-Id: <9807210427.AA28038@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 00:27:37 -0400 (EDT) Cc: disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 7, 98 08:05:12 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > for my money (and UUNET's), we believe that time-varying > role-based security policy is the only way you deal with > humans, Yes, but are you willing to pay the performance/code-size price for the privilege of having such a policy? Plus, do you realize that the only place to keep the "decider" code is in the data owner, i.e. that "network element" which you refer to below: > ......... which is very distinct from network elements. > for example, a network operator on duty may have > significant access rights to test and reconfigure a network > element, but when the person goes off-shift, they must lose > those rights. > the only way to do this rationally is to do the mapping of > person-role-time-rights *mostly* in NMS software which sits > between the operator and the network elements. If NMS does the mapping, you (a) may lose the proper audit trail and (b) may have to restrict management operations to certain installed NMS. > the machinery in SNMPv3 supports identity-rights mappings, > and that is sufficient given the interposed NMS software > which uses a set of identities instantiated in the network > elements to map a given person performing a specific role > at a certain time into a set of required access rights. This is not a role-based Access Control. It's a role-based NMS. Now, maybe that's all that is required? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 08:56:22 1998 Delivery-Date: Tue, 21 Jul 1998 08:56:23 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA03920 for ; Tue, 21 Jul 1998 08:56:22 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA09272 for ; Tue, 21 Jul 1998 08:56:15 -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 EAA08082 for ; Tue, 21 Jul 1998 04:43:06 -0400 (EDT) Received: from relay8.uu.net (relay8.uu.net [192.48.96.84]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id HAA17383 for ; Tue, 21 Jul 1998 07:22:07 -0400 (EDT) Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeyzd04778; Tue, 21 Jul 1998 07:22:05 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQeyzd04077; Tue, 21 Jul 1998 07:22:05 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder), rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Mon, 20 Jul 1998 22:31:39 EDT." <9807210231.AA30262@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 07:22:04 -0400 From: "Mike O'Dell" doing roll-based authentication is trivial - the user authenticates FOR A SPECIFIC ROLE and then does his work under that guise. there is no magic required whereby the software has to "guess" what roll is required. there is an absolute declaration of intent by the human. jeez - why are you guys trying to hard to fail?? -mo From maria@xedia.com Tue Jul 21 08:56:28 1998 Delivery-Date: Tue, 21 Jul 1998 08:56:28 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA03925 for ; Tue, 21 Jul 1998 08:56:27 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA09274 for ; Tue, 21 Jul 1998 08:56:20 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id EAA08085 for ; Tue, 21 Jul 1998 04:44:17 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id HAA24163 for ; Tue, 21 Jul 1998 07:23:17 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeyzd19994; Tue, 21 Jul 1998 07:23:16 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQeyzd04121; Tue, 21 Jul 1998 07:23:16 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: mo@UU.NET (Mike O'Dell), disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 21 Jul 1998 00:27:37 EDT." <9807210427.AA28038@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 07:23:15 -0400 From: "Mike O'Dell" no no no no the network element does NOT need to do the deciding -mo From maria@xedia.com Tue Jul 21 14:30:03 1998 Delivery-Date: Tue, 21 Jul 1998 14:30:05 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01231 for ; Tue, 21 Jul 1998 14:30:02 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA00770 for ; Tue, 21 Jul 1998 14:29:54 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA16177 for ; Tue, 21 Jul 1998 10:01:44 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id MAA25507 for ; Tue, 21 Jul 1998 12:40:48 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id MAA17948; Tue, 21 Jul 1998 12:40:40 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id MAA14642; Tue, 21 Jul 1998 12:40:39 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA47368; Tue, 21 Jul 1998 12:40:34 -0400 From: Uri Blumenthal Message-Id: <9807211640.AA47368@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 12:40:33 -0400 (EDT) Cc: schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 21, 98 07:22:04 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > doing roll-based authentication is trivial - the user authenticates > FOR A SPECIFIC ROLE and then does his work under that guise. The *concept* is trivial. The implementation is not, and neither are the details. Plus, what you seem to mean is *not* a "true" role-based approach. A "true" one requires a combination of principal rights with role rights. What you seem to imply is "authenticate the principal, use the rights of the `role'". Oh, and of course one needs a "permissions" table - which principal is authorized for which roles (and maybe this table should include date/time restrictions?). It is simple until you start thinking about how people will use it, how crackers will try to break it, and what it is supposed to protect you from... [Now back to my jet-lagged uneasy sleep, going "barrel rolls" :-] > there is no magic required whereby the software has to "guess" what > roll is required. there is an absolute declaration of intent by the > human. No magic, just (a) inclusion of the role name/tag in the message and (b) decision on how to compute the access rights [to base it solely on the role "rights", or on a combination of the role "rights" and the user "rights"]. I wish you'd commented on that rather than on the triviality of the basic concept... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 14:46:09 1998 Delivery-Date: Tue, 21 Jul 1998 14:46:09 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01336 for ; Tue, 21 Jul 1998 14:46:08 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA00880 for ; Tue, 21 Jul 1998 14:46:01 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id IAA14438 for ; Tue, 21 Jul 1998 08:55:28 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id LAA25227 for ; Tue, 21 Jul 1998 11:34:31 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id LAA23370; Tue, 21 Jul 1998 11:34:29 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id LAA16716; Tue, 21 Jul 1998 11:34:28 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA45762; Tue, 21 Jul 1998 11:34:19 -0400 From: Uri Blumenthal Message-Id: <9807211534.AA45762@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 11:34:18 -0400 (EDT) Cc: mo@UU.NET, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 21, 98 07:23:15 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > no no no no > > the network element does NOT need to do the deciding In that case your idea of access control has nothing in common with that of mine. To me if the network element has the data to be accessed, then the only place where access control can be done securely is that net.element. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 15:11:38 1998 Delivery-Date: Tue, 21 Jul 1998 15:11:38 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA01590 for ; Tue, 21 Jul 1998 15:11:37 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA01076 for ; Tue, 21 Jul 1998 15:11:30 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA17448 for ; Tue, 21 Jul 1998 10:59:01 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id NAA25781 for ; Tue, 21 Jul 1998 13:38:06 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQezac06672; Tue, 21 Jul 1998 13:38:04 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQezac00262; Tue, 21 Jul 1998 13:38:02 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: mo@UU.NET (Mike O'Dell), schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 21 Jul 1998 12:40:33 EDT." <9807211640.AA47368@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 13:38:02 -0400 From: "Mike O'Dell" Uri, i've been doing OS security since the early 1970s - i don't need the lecture. you can complicate the model to the degree you wish and i'm not going to argue about what constitutes "true" role-based security. arguments like that produced the SNMPv2 success. suffice it to say that we firmly believe that the authentication and authorization capabilities we need to operate a network of over 10,000 network elements and over half a billion US$ in cost, using a "role-inspired" model, can be implemented at reasonable cost and complexity using a combination of machinery resident in the network elements and some resident in the management software infrastructure, all using SNMPv3 mechanics as currently described. now can we please just ship the damn thing so we can get on with running our network?? -mo From maria@xedia.com Tue Jul 21 15:11:40 1998 Delivery-Date: Tue, 21 Jul 1998 15:11:40 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA01595 for ; Tue, 21 Jul 1998 15:11:39 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA01078 for ; Tue, 21 Jul 1998 15:11:32 -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 KAA17325 for ; Tue, 21 Jul 1998 10:50:10 -0400 (EDT) Received: from relay8.uu.net (relay8.uu.net [192.48.96.84]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id NAA19718 for ; Tue, 21 Jul 1998 13:29:15 -0400 (EDT) Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQezab21922; Tue, 21 Jul 1998 13:29:14 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQezab29696; Tue, 21 Jul 1998 13:29:13 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: mo@UU.NET (Mike O'Dell), disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 21 Jul 1998 11:34:18 EDT." <9807211534.AA45762@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 13:29:13 -0400 From: "Mike O'Dell" of course you are right in the limiting case however, *all* access control need not be done in the element, especially if there are rich semantic policies needed. all you have to do is have an adequate partitioning whereby enough simple mechanisms exist in the element to allow implementation with the heavy lifting done elsewhere -mo From maria@xedia.com Tue Jul 21 16:09:16 1998 Delivery-Date: Tue, 21 Jul 1998 16:09:17 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA02707 for ; Tue, 21 Jul 1998 16:09:16 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA01439 for ; Tue, 21 Jul 1998 16:09:09 -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 LAA19240 for ; Tue, 21 Jul 1998 11:59:41 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA20414 for ; Tue, 21 Jul 1998 14:38:46 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA17928; Tue, 21 Jul 1998 14:38:42 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA07180; Tue, 21 Jul 1998 14:38:42 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA43982; Tue, 21 Jul 1998 14:38:42 -0400 From: Uri Blumenthal Message-Id: <9807211838.AA43982@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 14:38:42 -0400 (EDT) Cc: mo@UU.NET, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 21, 98 01:29:13 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > however, *all* access control need not be done in the element, > especially if there are rich semantic policies needed. > all you have to do is have an adequate partitioning whereby > enough simple mechanisms exist in the element to allow > implementation with the heavy lifting done elsewhere If you have it roughly figured out, why don't you post an outline of what actions are to be taken and by what entities, when doing access control? Furnishing as many details as you can? Because at this point it sounds more like a sales pitch than a technical proposal (i.e. "simple enough", "adequate partitioning" etc. are rather subjective terms and have no meaning until you tell what exactly you want the things to look like). -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 16:12:41 1998 Delivery-Date: Tue, 21 Jul 1998 16:12:41 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA02729 for ; Tue, 21 Jul 1998 16:12:40 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA01471 for ; Tue, 21 Jul 1998 16:12:33 -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 LAA19057 for ; Tue, 21 Jul 1998 11:51:37 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA20339 for ; Tue, 21 Jul 1998 14:30:42 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA16928; Tue, 21 Jul 1998 14:30:34 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA11824; Tue, 21 Jul 1998 14:30:33 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA43592; Tue, 21 Jul 1998 14:30:32 -0400 From: Uri Blumenthal Message-Id: <9807211830.AA43592@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 14:30:31 -0400 (EDT) Cc: mo@UU.NET, schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 21, 98 01:38:02 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > Uri, i've been doing OS security since the early 1970s - i don't need > the lecture. OK, I'm glad to finally find somebody who knows it all. But since I don't know it all, and in the early 70s I've been doing other things - it would be helpful if you answered the purely technical questions I asked. Besides, you can't expect a consistent reaction unless those questions are answered uniformly by every implementation. I hope it is clear? > you can complicate the model to the degree you wish and i'm not going > to argue about what constitutes "true" role-based security. arguments > like that produced the SNMPv2 success. I'm trying to figure out what the hell it is that you want, and to possibly map it onto terminology that other people use/ That's all. > suffice it to say that we firmly believe that the authentication and > authorization capabilities we need to operate a network of over 10,000 > network elements and over half a billion US$ in cost, using a > "role-inspired" model, can be implemented at reasonable cost and > complexity using a combination of machinery resident in the network > elements and some resident in the management software infrastructure, > all using SNMPv3 mechanics as currently described. Fine with me - especially if instead of this pointless and non-technical bickering you take 5 minutes to understand the technical questions I've been asking and another 5 minutes to answer them. > now can we please just ship the damn thing so we can get on with > running our network?? Who stops you from shipping "the damn thing"? Not me, I hope? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 17:00:44 1998 Delivery-Date: Tue, 21 Jul 1998 17:00:44 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA03205 for ; Tue, 21 Jul 1998 17:00:43 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01795 for ; Tue, 21 Jul 1998 17:00:37 -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 MAA20040 for ; Tue, 21 Jul 1998 12:25:03 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA20600 for ; Tue, 21 Jul 1998 15:04:09 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQezai21784; Tue, 21 Jul 1998 15:04:08 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQezai09878; Tue, 21 Jul 1998 15:04:08 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: mo@UU.NET (Mike O'Dell), disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 21 Jul 1998 14:38:42 EDT." <9807211838.AA43982@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 15:04:07 -0400 From: "Mike O'Dell" i don't need any more mechanism than what's already there. the management interface maps User X Role -> AccessPartition based on time, policy, presented credentials, etc. of course it keeps records of all such mappings granted as well as all activities performed after the granting. the network elements have identies for the full set of AccessPartitions (which is much smaller than User x Role) and the credentials for access via one of those partition identities is maintained *solely* by the management software, which actually performs the accesses on behalf of the authorized user in his role. the management software effectively allows a given user to take on a given role at a particular time, and all the mediation required to execute the policy is only in the management interface software. the only identities defined in the network elements are the members of equivalence classes which cover the required rights. i assume what you believe is a full "role-based model" involves doing general capability vector algebra. such models are frequently operationally incomplete as that they don't generally support time-varying policy except via exogenous mediators (which is exactly what i'm proposing), and they require the maintainence of a large amount of distributed state which is not required for this purpose. yes, i understand that what i suggest is not as general, but that's fine - "You don't need to boil the ocean just to get a poached fish." so can we please get on with getting done?? -mo From maria@xedia.com Tue Jul 21 17:14:01 1998 Delivery-Date: Tue, 21 Jul 1998 17:14:01 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA03331 for ; Tue, 21 Jul 1998 17:14:00 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01871 for ; Tue, 21 Jul 1998 17:13:54 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id NAA23111 for ; Tue, 21 Jul 1998 13:06:24 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id PAA26488 for ; Tue, 21 Jul 1998 15:45:30 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id PAA13924; Tue, 21 Jul 1998 15:44:01 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id PAA18748; Tue, 21 Jul 1998 15:44:00 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA38384; Tue, 21 Jul 1998 15:43:50 -0400 From: Uri Blumenthal Message-Id: <9807211943.AA38384@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 15:43:49 -0400 (EDT) Cc: mo@UU.NET, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 21, 98 03:04:07 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > the management interface maps User X Role -> AccessPartition > based on time, policy, presented credentials, etc. So the principal for network elements will be AccessPartition? OK by me. > the network elements have identies for the full set of > AccessPartitions (which is much smaller than User x Role) OK here. > and the credentials for access via one of those partition > identities is maintained *solely* by the management software, > which actually performs the accesses on behalf of the authorized > user in his role. Management software does not perform any access. It requests the operation to be performed (and thus the access to be granted) by the network element(s). You want the NMS to authenticate a principal and map him onto the proper group (privileges-wise, time-wise etc.)? That's doable, of course. But it means that you must come in through NMS (and not via a shell script, for example). It also means that the data owner does not have the ability to trace who did what to it. If you can live with it, so can I. > the only identities defined in the network elements are the > members of equivalence classes which cover the required rights. Fine, in light of the above. To summarize: - The "network elements" have "roles" defined as principals, with the correspondign access rights; - the NMS authenticates the users and maps the requests to the appropriate "roles"; - the network elements authenticate requests issued by the "roles"; - the NMS logs who (a user) did what, the network elements log what role did what; - the network elements share secrets with the NMS(s) only, not with the users, and thus are accessible only via NMS. Does it represent accurately what you meant? What do the others think? > i assume what you believe is a full "role-based model" > involves doing general capability vector algebra...... I believe in God and in using correct terminology - no other assumption about my beliefs is reliable (:-). I don't care whether the accepted approach is a full role-based model, a partial one, or even a remotely similar. I do care that all the i's are dotted and all the t's are crossed, when the model - whatever it is - is specified. That's all. > "You don't need to boil the ocean just to get a poached fish." > so can we please get on with getting done?? Enjoy your poached jellyfish then. [Oh, and from my prospective, we *are* done.] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 19:00:55 1998 Delivery-Date: Tue, 21 Jul 1998 19:00:58 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA03810 for ; Tue, 21 Jul 1998 19:00:50 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA02346 for ; Tue, 21 Jul 1998 19:00:45 -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 OAA25551 for ; Tue, 21 Jul 1998 14:37:51 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA21498 for ; Tue, 21 Jul 1998 17:16:57 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQezar16496; Tue, 21 Jul 1998 17:16:55 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQezar21092; Tue, 21 Jul 1998 17:16:54 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: mo@UU.NET (Mike O'Dell), disman@nexen.com, snmpv3@tis.com, mo@UU.NET Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 21 Jul 1998 15:43:49 EDT." <9807211943.AA38384@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 17:16:54 -0400 From: "Mike O'Dell" as for what I believe, "I believe I'll have another beer." cheers -mo From maria@xedia.com Wed Jul 22 10:29:18 1998 Delivery-Date: Wed, 22 Jul 1998 10:29:22 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA14790 for ; Wed, 22 Jul 1998 10:29:17 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA05032 for ; Wed, 22 Jul 1998 10:29:10 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id FAA07696 for ; Wed, 22 Jul 1998 05:48:38 -0400 (EDT) Received: from concord.com (concord.com [192.124.15.3]) by guelah.nexen.com (8.8.5/8.7.3) with SMTP id IAA28835 for ; Wed, 22 Jul 1998 08:27:55 -0400 (EDT) Received: from marvin.concord.com by concord.com (4.1/SMI-4.1) id AA07023; Wed, 22 Jul 98 08:27:46 EDT Received: from skywalker by marvin.concord.com (SMI-8.6/SMI-SVR4) id IAA23571; Wed, 22 Jul 1998 08:27:40 -0400 Message-Id: <3.0.3.32.19980722082808.0098ee10@marvin.concord.com> X-Sender: engel@marvin.concord.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 22 Jul 1998 08:28:08 -0400 To: uri@watson.ibm.com, mo@UU.NET (Mike O'Dell) From: Fred Engel Subject: Re: VACM and DISMAN Cc: mo@UU.NET, schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: <9807211830.AA43592@watpub1.watson.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Guys, let's not get personal :-)!! Fred At 02:30 PM 7/21/98 -0400, Uri Blumenthal wrote: >Mike O'Dell says: >> Uri, i've been doing OS security since the early 1970s - i don't need >> the lecture. > >OK, I'm glad to finally find somebody who knows it all. > >But since I don't know it all, and in the early 70s I've been doing >other things - it would be helpful if you answered the purely >technical questions I asked. Besides, you can't expect a >consistent reaction unless those questions are answered >uniformly by every implementation. I hope it is clear? > >> you can complicate the model to the degree you wish and i'm not going >> to argue about what constitutes "true" role-based security. arguments >> like that produced the SNMPv2 success. > >I'm trying to figure out what the hell it is that you want, and to >possibly map it onto terminology that other people use/ That's all. > >> suffice it to say that we firmly believe that the authentication and >> authorization capabilities we need to operate a network of over 10,000 >> network elements and over half a billion US$ in cost, using a >> "role-inspired" model, can be implemented at reasonable cost and >> complexity using a combination of machinery resident in the network >> elements and some resident in the management software infrastructure, >> all using SNMPv3 mechanics as currently described. > >Fine with me - especially if instead of this pointless and non-technical >bickering you take 5 minutes to understand the technical questions I've >been asking and another 5 minutes to answer them. > >> now can we please just ship the damn thing so we can get on with >> running our network?? > >Who stops you from shipping "the damn thing"? Not me, I hope? >-- >Regards, >Uri uri@watson.ibm.com >-=-=-=-=-=-=- > > > Fred Engel Vice President, Engineering Concord Communications, Inc. Marlboro, MA. 01752 (508)-460-4646 From maria@xedia.com Wed Jul 22 14:37:43 1998 Delivery-Date: Wed, 22 Jul 1998 14:37:43 -0400 Return-Path: maria@xedia.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA17461 for ; Wed, 22 Jul 1998 14:37:38 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA06803 for ; Wed, 22 Jul 1998 14:37:31 -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 JAA14098 for ; Wed, 22 Jul 1998 09:44:09 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id MAA02060 for ; Wed, 22 Jul 1998 12:23:27 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA19136 for ; Wed, 22 Jul 1998 11:23:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019116; Wed, 22 Jul 98 11:23:07 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA25309 for ; Wed, 22 Jul 1998 11:22:32 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024928; Wed, 22 Jul 98 11:22:13 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA02611; Wed, 22 Jul 1998 11:22:41 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA17743; Wed, 22 Jul 1998 09:22:41 -0700 (PDT) Date: Wed, 22 Jul 1998 09:22:41 -0700 (PDT) From: Randy Presuhn Message-Id: <199807221622.JAA17743@dorothy.bmc.com> To: disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Since there seems to be virtually no disman-specific content in this thread, I suggest limiting its continuation to the snmpv3@tis.com list. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From adm Tue Aug 4 11:36:41 1998 Delivery-Date: Tue, 04 Aug 1998 11:54:26 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA09421 for ietf-123-outbound.10@ietf.org; Tue, 4 Aug 1998 11:35:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA16633; Tue, 4 Aug 1998 09:52:51 -0400 (EDT) Message-Id: <199808041352.JAA16633@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpv3@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-usm-v2-01.txt Date: Tue, 04 Aug 1998 09:52:50 -0400 Sender: cclark@ns.cnri.reston.va.us --NextPart A New 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) : B. Wijnen, U. Blumenthal Filename : draft-ietf-snmpv3-usm-v2-01.txt Pages : 83 Date : 03-Aug-98 This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFCxxx1]. 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 with 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-v2-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-snmpv3-usm-v2-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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpv3-usm-v2-01.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980803165240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-usm-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-usm-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980803165240.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Aug 4 11:46:39 1998 Delivery-Date: Tue, 04 Aug 1998 12:02:50 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA09959 for ietf-123-outbound.10@ietf.org; Tue, 4 Aug 1998 11:45:04 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA16650; Tue, 4 Aug 1998 09:52:54 -0400 (EDT) Message-Id: <199808041352.JAA16650@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpv3@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-vacm-00.txt Date: Tue, 04 Aug 1998 09:52:54 -0400 Sender: cclark@ns.cnri.reston.va.us --NextPart A New 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 (VACM) for the Simple Network Management Protocol (SNMP) Author(s) : K. McCloghrie, B. Wijnen, R. Presuhn Filename : draft-ietf-snmpv3-vacm-00.txt Pages : 36 Date : 03-Aug-98 This document describes the View-based Access Control Model for use in the SNMP architecture [RFCxxx1]. 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 with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpv3-vacm-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-snmpv3-vacm-00.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpv3-vacm-00.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980803170300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-vacm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-vacm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980803170300.I-D@ietf.org> --OtherAccess-- --NextPart--