From exim@www1.ietf.org Thu Dec 4 06:07:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19517 for ; Thu, 4 Dec 2003 06:07:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrK8-0004z7-Kf for midcom-archive@odin.ietf.org; Thu, 04 Dec 2003 06:07:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4B78QS019144 for midcom-archive@odin.ietf.org; Thu, 4 Dec 2003 06:07:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrK3-0004w7-85; Thu, 04 Dec 2003 06:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrJN-0004vB-7W for midcom@optimus.ietf.org; Thu, 04 Dec 2003 06:06:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19474 for ; Thu, 4 Dec 2003 06:06:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARrJJ-0006Ax-00 for midcom@ietf.org; Thu, 04 Dec 2003 06:06:17 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1ARrJI-0006AI-00 for midcom@ietf.org; Thu, 04 Dec 2003 06:06:16 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hB4B5eCx097913 for ; Thu, 4 Dec 2003 12:05:40 +0100 (CET) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 06211CA4DA for ; Thu, 4 Dec 2003 12:05:40 +0100 (CET) Date: Thu, 04 Dec 2003 12:03:16 +0100 From: Martin Stiemerling To: midcom@ietf.org Message-ID: <5089308.1070539396@[10.1.1.109]> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========05106824==========" X-Scanned-By: MIMEDefang 2.35 Subject: [midcom] I-D ACTION:draft-stiemerling-midcom-server-mib-00.txt (fwd) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --==========05106824========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, Juergen, Suresh and I have posted a new Internet draft proposing the 'MIB plane' of MIDCOM, so called MIDCOM SERVER MIB. The MIDCOM MIB module will implement the MIDCOM protocol. In contrary to the proposed MIDCOM MIB module the MIDCOM SERVER MIB module is made for controlling the MIDCOM server at the middlebox. This means that setting parameters at the MIDCOM server or monitoring of the MIDCOM server can be done through this MIDCOM SERVER MIB module. One example for configuring the MIDCOM server is setting the firewall rule group to which filter rules loaded by MIDCOM a assigned. Martin ------------ Forwarded Message ------------ Date: Mittwoch, 3. Dezember 2003 15:27 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: I-D ACTION:draft-stiemerling-midcom-server-mib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for MIDCOM Server Author(s) : M. Stiemerling Filename : draft-stiemerling-midcom-server-mib-00.txt Pages : 23 Date : 2003-12-3 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring and configuration of middleboxes running a MIDCOM server, i.e. the MIDCOM MIB module RFC YYYY. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-server-mib-00. txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-stiemerling-midcom-server-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-server-mib-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. ---------- End Forwarded Message ---------- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories stiemerling@netlab.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de --==========05106824========== Content-Type: message/rfc822; name="I-D ACTION:draft-stiemerling-midcom-server-mib-00.txt" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from tokyo.ccrle.nec.de (pluto.office [10.1.1.84]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 18ADA13737; Wed, 3 Dec 2003 22:13:22 +0100 (CET) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hB3LDKCx073233; Wed, 3 Dec 2003 22:13:20 +0100 (CET) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1ARdgK-0003Zb-SA for ietf-announce-list@asgard.ietf.org; Wed, 03 Dec 2003 15:33:08 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1ARdb1-0003Oa-Ue for all-ietf@asgard.ietf.org; Wed, 03 Dec 2003 15:27:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03586 for ; Wed, 3 Dec 2003 15:27:24 -0500 (EST) Message-Id: <200312032027.PAA03586@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-stiemerling-midcom-server-mib-00.txt Date: Wed, 03 Dec 2003 15:27:24 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-Scanned-By: MIMEDefang 2.35 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========05120362==========" --==========05120362========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for MIDCOM Server Author(s) : M. Stiemerling Filename : draft-stiemerling-midcom-server-mib-00.txt Pages : 23 Date : 2003-12-3 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring and configuration of middleboxes running a MIDCOM server, i.e. the MIDCOM MIB module RFC YYYY. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-server-mib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-stiemerling-midcom-server-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-server-mib-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. --==========05120362========== Content-Type: multipart/alternative; boundary="==========05094949==========" --==========05094949========== Content-Type: message/external-body; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-12-3152557.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stiemerling-midcom-server-mib-00.txt --==========05094949========== Content-Type: message/external-body; name="draft-stiemerling-midcom-server-mib-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-12-3152557.I-D@ietf.org> --==========05094949==========-- --==========05120362==========-- --==========05106824==========-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Dec 10 12:53:07 2003 Return-Path: Received: from optimus.ietf.org by ietf.org.ietf.org (SMI-8.6/SMI-SVR4) id MAA23550; Wed, 10 Dec 2003 12:53:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU8WL-0004oS-2j for midcom-archive@odin.ietf.org; Wed, 10 Dec 2003 12:53:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAHr9ck018498 for midcom-archive@odin.ietf.org; Wed, 10 Dec 2003 12:53:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU8WD-0004nX-8h; Wed, 10 Dec 2003 12:53:01 -0500 Received: from ns.cnri.reston.va.us ([132.151.1.1]) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU8Vl-0004mS-3p for midcom@optimus.cnri.reston.va.us; Wed, 10 Dec 2003 12:52:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org.ietf.org) by ns.cnri.reston.va.us with smtp (Exim 4.20) id 1AU8Vi-0004lC-5L for midcom@optimus; Wed, 10 Dec 2003 12:52:31 -0500 Received: from ietf-mx by ietf.org.ietf.org (SMI-8.6/SMI-SVR4) id MAA23524; Wed, 10 Dec 2003 12:52:24 -0500 Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU8Ve-0004hy-00 for midcom@ietf.org; Wed, 10 Dec 2003 12:52:26 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AU8Vd-0004hZ-00 for midcom@ietf.org; Wed, 10 Dec 2003 12:52:26 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hBAHps71033824 for ; Wed, 10 Dec 2003 18:51:55 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hBAHpn42033823 for ; Wed, 10 Dec 2003 18:51:49 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hBAHpn6x033821; Wed, 10 Dec 2003 18:51:49 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 51A59E8BF6; Wed, 10 Dec 2003 18:51:47 +0100 (CET) Date: Wed, 10 Dec 2003 18:53:49 +0100 From: Juergen Quittek To: mibs@ops.ietf.org Cc: midcom@ietf.org Message-ID: <2147483647.1071082429@[10.1.1.171]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Subject: [midcom] MIDCOM MIB design question Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , content-length: 2283 Dear all, In the MIDCOM working group we are developing a protocol for dynamically requesting pinholes in firewalls and bindings/sessions on NATs. The working group decided to use SNMP as basic protocol and now we are defining a MIDCOM MIB module. While doing this, we found that we are defining two separate groups of objects: Objects implementing the MIDCOM protocol (for which we already have a protocol semantics document, see draft-ietf-midcom-semantics-06.txt) and objects serving management purposes. Management purposes include for example configurations, such as - the priority with which requested pinholes are configured in the firewall, - a table showing the mapping of MIDCOM pinholes to firewall resources or of MIDCOM NAT sessions/bindings to NAT resources - a protocol statistics table listing the set of active MIDCOM sessions, protocol errors, etc. For these two groups of objects there are also two separate groups of users: - middlebox controllers sending requests for dynamic pinholes and NAT sessions/bindings - network managers configuring the middlebox (firewall or NAT) and monitoring its operation The middlebox controllers only need access to the objects implementing the MIDCOM protocol. The network managers would rather use the objects serving management purposes although in some cases they might need to access the other group also. Now, we have a draft defining these objects and the following question: Does someone have an opinion about whether these two groups of objects should be contained in a single MIB module or in two separate ones? Usually, this problem does not occur, because most control protocol, say GSMP are not defined on top of SNMP. Therefore in GSMP there is a clear separation between the protocol and the MIB with objects serving network management purposes. But in our case, SNMP is used for both purposes. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Dec 10 13:39:10 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08663 for ; Wed, 10 Dec 2003 13:39:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU90G-0005ul-HZ for midcom-archive@odin.ietf.org; Wed, 10 Dec 2003 13:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAIO4vp022701 for midcom-archive@odin.ietf.org; Wed, 10 Dec 2003 13:24:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU90F-0005tk-7o; Wed, 10 Dec 2003 13:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU8zQ-0005qG-7X for midcom@optimus.ietf.org; Wed, 10 Dec 2003 13:23:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07839 for ; Wed, 10 Dec 2003 13:14:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU8q3-000500-00 for midcom@ietf.org; Wed, 10 Dec 2003 13:13:31 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AU8q3-0004zT-00 for midcom@ietf.org; Wed, 10 Dec 2003 13:13:31 -0500 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBAICfn10540; Wed, 10 Dec 2003 13:12:41 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLY28PFX; Wed, 10 Dec 2003 13:12:41 -0500 Received: from nortelnetworks.com (acart1px.ca.nortel.com [47.129.130.149]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWNAPH; Wed, 10 Dec 2003 13:12:42 -0500 Message-ID: <3FD76218.6020504@nortelnetworks.com> Date: Wed, 10 Dec 2003 13:12:40 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: mibs@ops.ietf.org, midcom@ietf.org Subject: Re: [midcom] MIDCOM MIB design question References: <2147483647.1071082429@[10.1.1.171]> In-Reply-To: <2147483647.1071082429@[10.1.1.171]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'd say they should be in separate modules because they are likely to be implemented on separate boxes on the SNMP client side. Juergen Quittek wrote: > Dear all, > > In the MIDCOM working group we are developing a protocol for dynamically > requesting pinholes in firewalls and bindings/sessions on NATs. > > The working group decided to use SNMP as basic protocol and now we are > defining a MIDCOM MIB module. While doing this, we found that we are > defining two separate groups of objects: Objects implementing the MIDCOM > protocol (for which we already have a protocol semantics document, see > draft-ietf-midcom-semantics-06.txt) and objects serving management > purposes. > Management purposes include for example configurations, such as > - the priority with which requested pinholes are configured in the > firewall, > - a table showing the mapping of MIDCOM pinholes to firewall resources > or of MIDCOM NAT sessions/bindings to NAT resources > - a protocol statistics table listing the set of active MIDCOM sessions, > protocol errors, etc. > > For these two groups of objects there are also two separate groups of > users: > - middlebox controllers sending requests for dynamic pinholes and NAT > sessions/bindings > - network managers configuring the middlebox (firewall or NAT) and > monitoring its operation > > The middlebox controllers only need access to the objects implementing > the MIDCOM protocol. > > The network managers would rather use the objects serving management > purposes > although in some cases they might need to access the other group also. > > Now, we have a draft defining these objects and the following question: > > Does someone have an opinion about whether these two groups of objects > should be contained in a single MIB module or in two separate ones? > > Usually, this problem does not occur, because most control protocol, > say GSMP are not defined on top of SNMP. Therefore in GSMP there is > a clear separation between the protocol and the MIB with objects serving > network management purposes. But in our case, SNMP is used for both > purposes. > > Thanks, > > Juergen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Dec 10 21:26:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01150 for ; Wed, 10 Dec 2003 21:26:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUGWk-0003kW-Kr for midcom-archive@odin.ietf.org; Wed, 10 Dec 2003 21:26:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB2Q6tM014409 for midcom-archive@odin.ietf.org; Wed, 10 Dec 2003 21:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUGWf-0003jw-Ki; Wed, 10 Dec 2003 21:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUGWD-0003jN-1j for midcom@optimus.ietf.org; Wed, 10 Dec 2003 21:25:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01147 for ; Wed, 10 Dec 2003 21:25:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUGW9-0000Ix-00 for midcom@ietf.org; Wed, 10 Dec 2003 21:25:29 -0500 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AUGW8-0000Iu-00 for midcom@ietf.org; Wed, 10 Dec 2003 21:25:29 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id VAA15475 for ; Wed, 10 Dec 2003 21:26:32 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma015466; Wed, 10 Dec 03 21:25:44 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 10 Dec 2003 21:24:42 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 10 Dec 2003 21:24:42 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Dec 2003 21:24:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] MIDCOM MIB design question Date: Wed, 10 Dec 2003 21:24:39 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA013B1747@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] MIDCOM MIB design question Thread-Index: AcO/StagQJOvazUgRtC+XA3mH+XIlAALsZTg From: "Harrington, David" To: "Tom Taylor" , "Juergen Quittek" Cc: , X-OriginalArrivalTime: 11 Dec 2003 02:24:40.0374 (UTC) FILETIME=[EE2D3560:01C3BF8D] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:83.3688 M:99.5542 P:95.9108 R:95.9108 S:77.6934 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Juergen, SNMP is a protocol that manipulates sets of data on remote devices. The set of data is typically used by many users. You separate mib data sets by the functionality they contain, not by which "user" will use it.=20 It would be really helpful if you were more explicit about the requirements and the separate objects you think are needed in each mib. Objects that "serve management purposes" means nothing to me. It depends on the manager. I might have one network manager or application whose job is to monitor performance, and he/it might use ifInOctets in its calculations. I might have a second application whose job is to isolate faulty interfaces, and it might use ifInOctets. I might have an intruder detection system that watches for anomalies and it might use ifInOctets. I wouldn't want three duplicate ifInOctet objects to rpvoide this information just because I happen to have three different managers/users looking at the datum for different purposes. You did list three things as management: 1) the priority with which requested pinholes are configured in the firewall, 2) a table showing the mapping of MIDCOM pinholes to firewall resources or of MIDCOM NAT sessions/bindings to NAT resources, 3) a protocol statistics table listing the set of active MIDCOM sessions, protocol errors, etc. I'm not quite sure what type of priority you are referring to in 1). Priority relative to what? To other pinholes? To other firewall rules? To other MIDCOM rules within a group? To other MIDCOM groups? The priority of the operator performing the opeation? The priority of the operation versus other tasks the device needs to perform?=20 The MIDCOM MIB manipulates the mappings of MIDCOM pinholes to resources, so the map available to monitor this mapping belongs in the same mib, in my opinion. You don't need to duplicate the information just so another user can read it. Statistics are about the MIDCOM sessions and whatnot being configured in this mib. You don't need to separate which mib this is in. It is generally better to keep the status related to a functionality in the same mib as the configuration of the functionality. Statistics are part of status, and so are the configuration settings. dbh > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com]=20 > Sent: Wednesday, December 10, 2003 1:13 PM > To: Juergen Quittek > Cc: mibs@ops.ietf.org; midcom@ietf.org > Subject: Re: [midcom] MIDCOM MIB design question >=20 >=20 > I'd say they should be in separate modules because they are=20 > likely to be=20 > implemented on separate boxes on the SNMP client side. >=20 > Juergen Quittek wrote: >=20 > > Dear all, > >=20 > > In the MIDCOM working group we are developing a protocol=20 > for dynamically > > requesting pinholes in firewalls and bindings/sessions on NATs. > >=20 > > The working group decided to use SNMP as basic protocol and=20 > now we are > > defining a MIDCOM MIB module. While doing this, we found=20 > that we are > > defining two separate groups of objects: Objects=20 > implementing the MIDCOM > > protocol (for which we already have a protocol semantics=20 > document, see > > draft-ietf-midcom-semantics-06.txt) and objects serving management=20 > > purposes. > > Management purposes include for example configurations, such as > > - the priority with which requested pinholes are configured in the=20 > > firewall, > > - a table showing the mapping of MIDCOM pinholes to=20 > firewall resources > > or of MIDCOM NAT sessions/bindings to NAT resources > > - a protocol statistics table listing the set of active=20 > MIDCOM sessions, > > protocol errors, etc. > >=20 > > For these two groups of objects there are also two separate=20 > groups of=20 > > users: > > - middlebox controllers sending requests for dynamic=20 > pinholes and NAT > > sessions/bindings > > - network managers configuring the middlebox (firewall or NAT) and > > monitoring its operation > >=20 > > The middlebox controllers only need access to the objects=20 > implementing > > the MIDCOM protocol. > >=20 > > The network managers would rather use the objects serving=20 > management=20 > > purposes > > although in some cases they might need to access the other=20 > group also. > >=20 > > Now, we have a draft defining these objects and the=20 > following question: > >=20 > > Does someone have an opinion about whether these two groups=20 > of objects > > should be contained in a single MIB module or in two separate ones? > >=20 > > Usually, this problem does not occur, because most control protocol, > > say GSMP are not defined on top of SNMP. Therefore in GSMP there is > > a clear separation between the protocol and the MIB with=20 > objects serving > > network management purposes. But in our case, SNMP is used for both > > purposes. > >=20 > > Thanks, > >=20 > > Juergen >=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Dec 10 23:29:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04542 for ; Wed, 10 Dec 2003 23:29:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIRl-0007nu-Qr for midcom-archive@odin.ietf.org; Wed, 10 Dec 2003 23:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB4T5lU029992 for midcom-archive@odin.ietf.org; Wed, 10 Dec 2003 23:29:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIRh-0007nC-DE; Wed, 10 Dec 2003 23:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIQw-0007l1-Fe for midcom@optimus.ietf.org; Wed, 10 Dec 2003 23:28:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04524 for ; Wed, 10 Dec 2003 23:28:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUIQt-0002PJ-00 for midcom@ietf.org; Wed, 10 Dec 2003 23:28:11 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AUIQt-0002P1-00 for midcom@ietf.org; Wed, 10 Dec 2003 23:28:11 -0500 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBB4RQT18910; Wed, 10 Dec 2003 23:27:26 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLY20C36; Wed, 10 Dec 2003 23:27:26 -0500 Received: from nortelnetworks.com (acart1px.ca.nortel.com [47.129.130.149]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWNA40; Wed, 10 Dec 2003 23:27:25 -0500 Message-ID: <3FD7F22D.3040306@nortelnetworks.com> Date: Wed, 10 Dec 2003 23:27:25 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Harrington, David" CC: Juergen Quittek , mibs@ops.ietf.org, midcom@ietf.org Subject: Re: [midcom] MIDCOM MIB design question References: <6D745637A7E0F94DA070743C55CDA9BA013B1747@NHROCMBX1.ets.enterasys.com> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA013B1747@NHROCMBX1.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I know you can use views to separate out what one user sees vs. another, but I figured separation by module was cleaner. Juergen is talking about separating what the administrator is interested in from what the MIDCOM agent is interested in. Agreed that they both address the same underlying data structures, but I would think security setup would be simpler if you could specify access by module rather than having to do it object by object. Harrington, David wrote: > Hi Juergen, > > SNMP is a protocol that manipulates sets of data on remote devices. The > set of data is typically used by many users. You separate mib data sets > by the functionality they contain, not by which "user" will use it. > > It would be really helpful if you were more explicit about the > requirements and the separate objects you think are needed in each mib. > Objects that "serve management purposes" means nothing to me. It depends > on the manager. > > I might have one network manager or application whose job is to monitor > performance, and he/it might use ifInOctets in its calculations. I might > have a second application whose job is to isolate faulty interfaces, and > it might use ifInOctets. I might have an intruder detection system that > watches for anomalies and it might use ifInOctets. I wouldn't want three > duplicate ifInOctet objects to rpvoide this information just because I > happen to have three different managers/users looking at the datum for > different purposes. > > You did list three things as management: > 1) the priority with which requested pinholes are configured in the > firewall, > 2) a table showing the mapping of MIDCOM pinholes to firewall resources > or of MIDCOM NAT sessions/bindings to NAT resources, > 3) a protocol statistics table listing the set of active MIDCOM > sessions, protocol errors, etc. > > I'm not quite sure what type of priority you are referring to in 1). > Priority relative to what? To other pinholes? To other firewall rules? > To other MIDCOM rules within a group? To other MIDCOM groups? The > priority of the operator performing the opeation? The priority of the > operation versus other tasks the device needs to perform? > > The MIDCOM MIB manipulates the mappings of MIDCOM pinholes to resources, > so the map available to monitor this mapping belongs in the same mib, in > my opinion. You don't need to duplicate the information just so another > user can read it. > > Statistics are about the MIDCOM sessions and whatnot being configured in > this mib. You don't need to separate which mib this is in. > > It is generally better to keep the status related to a functionality in > the same mib as the configuration of the functionality. Statistics are > part of status, and so are the configuration settings. > > dbh > > >>-----Original Message----- >>From: Tom Taylor [mailto:taylor@nortelnetworks.com] >>Sent: Wednesday, December 10, 2003 1:13 PM >>To: Juergen Quittek >>Cc: mibs@ops.ietf.org; midcom@ietf.org >>Subject: Re: [midcom] MIDCOM MIB design question >> >> >>I'd say they should be in separate modules because they are >>likely to be >>implemented on separate boxes on the SNMP client side. >> >>Juergen Quittek wrote: >> >> >>>Dear all, >>> >>>In the MIDCOM working group we are developing a protocol >> >>for dynamically >> >>>requesting pinholes in firewalls and bindings/sessions on NATs. >>> >>>The working group decided to use SNMP as basic protocol and >> >>now we are >> >>>defining a MIDCOM MIB module. While doing this, we found >> >>that we are >> >>>defining two separate groups of objects: Objects >> >>implementing the MIDCOM >> >>>protocol (for which we already have a protocol semantics >> >>document, see >> >>>draft-ietf-midcom-semantics-06.txt) and objects serving management >>>purposes. >>>Management purposes include for example configurations, such as >>> - the priority with which requested pinholes are configured in the >>>firewall, >>> - a table showing the mapping of MIDCOM pinholes to >> >>firewall resources >> >>> or of MIDCOM NAT sessions/bindings to NAT resources >>> - a protocol statistics table listing the set of active >> >>MIDCOM sessions, >> >>> protocol errors, etc. >>> >>>For these two groups of objects there are also two separate >> >>groups of >> >>>users: >>> - middlebox controllers sending requests for dynamic >> >>pinholes and NAT >> >>> sessions/bindings >>> - network managers configuring the middlebox (firewall or NAT) and >>> monitoring its operation >>> >>>The middlebox controllers only need access to the objects >> >>implementing >> >>>the MIDCOM protocol. >>> >>>The network managers would rather use the objects serving >> >>management >> >>>purposes >>>although in some cases they might need to access the other >> >>group also. >> >>>Now, we have a draft defining these objects and the >> >>following question: >> >>>Does someone have an opinion about whether these two groups >> >>of objects >> >>>should be contained in a single MIB module or in two separate ones? >>> >>>Usually, this problem does not occur, because most control protocol, >>>say GSMP are not defined on top of SNMP. Therefore in GSMP there is >>>a clear separation between the protocol and the MIB with >> >>objects serving >> >>>network management purposes. But in our case, SNMP is used for both >>>purposes. >>> >>>Thanks, >>> >>> Juergen >> >> >>_______________________________________________ >>midcom mailing list >>midcom@ietf.org >>https://www1.ietf.org/mailman/listinfo/midcom >> > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 01:42:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07183 for ; Thu, 11 Dec 2003 01:42:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUKWR-0003pt-Oy for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 01:42:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB6g3ZE014739 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 01:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUKWQ-0003pX-2C; Thu, 11 Dec 2003 01:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUKWG-0003oS-4P for midcom@optimus.ietf.org; Thu, 11 Dec 2003 01:41:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07164 for ; Thu, 11 Dec 2003 01:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUKWC-00049C-00 for midcom@ietf.org; Thu, 11 Dec 2003 01:41:48 -0500 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AUKWB-000496-00 for midcom@ietf.org; Thu, 11 Dec 2003 01:41:47 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id BAA19409 for ; Thu, 11 Dec 2003 01:42:53 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma019397; Thu, 11 Dec 03 01:42:02 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 11 Dec 2003 01:40:56 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 11 Dec 2003 01:40:56 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Dec 2003 01:40:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] MIDCOM MIB design question Date: Thu, 11 Dec 2003 01:40:55 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA013B1748@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] MIDCOM MIB design question Thread-Index: AcO/nxrFK9rVDY7STHWtpDhGEq+fHgAEdOhg From: "Harrington, David" To: "Tom Taylor" Cc: "Juergen Quittek" , , X-OriginalArrivalTime: 11 Dec 2003 06:40:55.0828 (UTC) FILETIME=[BAA94D40:01C3BFB1] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:83.3688 M:99.5542 P:95.9108 R:95.9108 S:76.9308 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Tom, So I have a pile of money in my house. There are two people outside my house - one is my wife, and the other a thief. For simplicity, I could have two doors in my house; one I would lock to keep the thief out, and the other I'd leave unlocked so my wife could get in. How secure is my money? dbh > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com]=20 > Sent: Wednesday, December 10, 2003 11:27 PM > To: Harrington, David > Cc: Juergen Quittek; mibs@ops.ietf.org; midcom@ietf.org > Subject: Re: [midcom] MIDCOM MIB design question >=20 >=20 > I know you can use views to separate out what one user sees=20 > vs. another,=20 > but I figured separation by module was cleaner. Juergen is talking=20 > about separating what the administrator is interested in from=20 > what the=20 > MIDCOM agent is interested in. Agreed that they both address=20 > the same=20 > underlying data structures, but I would think security setup would be=20 > simpler if you could specify access by module rather than=20 > having to do=20 > it object by object. >=20 > Harrington, David wrote: >=20 > > Hi Juergen, > >=20 > > SNMP is a protocol that manipulates sets of data on remote=20 > devices. The > > set of data is typically used by many users. You separate=20 > mib data sets > > by the functionality they contain, not by which "user" will use it.=20 > >=20 > > It would be really helpful if you were more explicit about the > > requirements and the separate objects you think are needed=20 > in each mib. > > Objects that "serve management purposes" means nothing to=20 > me. It depends > > on the manager. > >=20 > > I might have one network manager or application whose job=20 > is to monitor > > performance, and he/it might use ifInOctets in its=20 > calculations. I might > > have a second application whose job is to isolate faulty=20 > interfaces, and > > it might use ifInOctets. I might have an intruder detection=20 > system that > > watches for anomalies and it might use ifInOctets. I=20 > wouldn't want three > > duplicate ifInOctet objects to rpvoide this information=20 > just because I > > happen to have three different managers/users looking at=20 > the datum for > > different purposes. > >=20 > > You did list three things as management: > > 1) the priority with which requested pinholes are configured in the > > firewall, > > 2) a table showing the mapping of MIDCOM pinholes to=20 > firewall resources > > or of MIDCOM NAT sessions/bindings to NAT resources, > > 3) a protocol statistics table listing the set of active MIDCOM > > sessions, protocol errors, etc. > >=20 > > I'm not quite sure what type of priority you are referring to in 1). > > Priority relative to what? To other pinholes? To other=20 > firewall rules? > > To other MIDCOM rules within a group? To other MIDCOM groups? The > > priority of the operator performing the opeation? The=20 > priority of the > > operation versus other tasks the device needs to perform?=20 > >=20 > > The MIDCOM MIB manipulates the mappings of MIDCOM pinholes=20 > to resources, > > so the map available to monitor this mapping belongs in the=20 > same mib, in > > my opinion. You don't need to duplicate the information=20 > just so another > > user can read it. > >=20 > > Statistics are about the MIDCOM sessions and whatnot being=20 > configured in > > this mib. You don't need to separate which mib this is in. > >=20 > > It is generally better to keep the status related to a=20 > functionality in > > the same mib as the configuration of the functionality.=20 > Statistics are > > part of status, and so are the configuration settings. > >=20 > > dbh > >=20 > >=20 > >>-----Original Message----- > >>From: Tom Taylor [mailto:taylor@nortelnetworks.com]=20 > >>Sent: Wednesday, December 10, 2003 1:13 PM > >>To: Juergen Quittek > >>Cc: mibs@ops.ietf.org; midcom@ietf.org > >>Subject: Re: [midcom] MIDCOM MIB design question > >> > >> > >>I'd say they should be in separate modules because they are=20 > >>likely to be=20 > >>implemented on separate boxes on the SNMP client side. > >> > >>Juergen Quittek wrote: > >> > >> > >>>Dear all, > >>> > >>>In the MIDCOM working group we are developing a protocol=20 > >> > >>for dynamically > >> > >>>requesting pinholes in firewalls and bindings/sessions on NATs. > >>> > >>>The working group decided to use SNMP as basic protocol and=20 > >> > >>now we are > >> > >>>defining a MIDCOM MIB module. While doing this, we found=20 > >> > >>that we are > >> > >>>defining two separate groups of objects: Objects=20 > >> > >>implementing the MIDCOM > >> > >>>protocol (for which we already have a protocol semantics=20 > >> > >>document, see > >> > >>>draft-ietf-midcom-semantics-06.txt) and objects serving management=20 > >>>purposes. > >>>Management purposes include for example configurations, such as > >>> - the priority with which requested pinholes are=20 > configured in the=20 > >>>firewall, > >>> - a table showing the mapping of MIDCOM pinholes to=20 > >> > >>firewall resources > >> > >>> or of MIDCOM NAT sessions/bindings to NAT resources > >>> - a protocol statistics table listing the set of active=20 > >> > >>MIDCOM sessions, > >> > >>> protocol errors, etc. > >>> > >>>For these two groups of objects there are also two separate=20 > >> > >>groups of=20 > >> > >>>users: > >>> - middlebox controllers sending requests for dynamic=20 > >> > >>pinholes and NAT > >> > >>> sessions/bindings > >>> - network managers configuring the middlebox (firewall or NAT) and > >>> monitoring its operation > >>> > >>>The middlebox controllers only need access to the objects=20 > >> > >>implementing > >> > >>>the MIDCOM protocol. > >>> > >>>The network managers would rather use the objects serving=20 > >> > >>management=20 > >> > >>>purposes > >>>although in some cases they might need to access the other=20 > >> > >>group also. > >> > >>>Now, we have a draft defining these objects and the=20 > >> > >>following question: > >> > >>>Does someone have an opinion about whether these two groups=20 > >> > >>of objects > >> > >>>should be contained in a single MIB module or in two separate ones? > >>> > >>>Usually, this problem does not occur, because most control=20 > protocol, > >>>say GSMP are not defined on top of SNMP. Therefore in=20 > GSMP there is > >>>a clear separation between the protocol and the MIB with=20 > >> > >>objects serving > >> > >>>network management purposes. But in our case, SNMP is=20 > used for both > >>>purposes. > >>> > >>>Thanks, > >>> > >>> Juergen > >> > >> > >>_______________________________________________ > >>midcom mailing list > >>midcom@ietf.org > >>https://www1.ietf.org/mailman/listinfo/midcom > >> > >=20 > >=20 >=20 >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 05:31:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24361 for ; Thu, 11 Dec 2003 05:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUO64-0005So-2j for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 05:31:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBAV4F7021001 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 05:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUO61-0005SK-OR; Thu, 11 Dec 2003 05:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUO5I-0005Mw-9z for midcom@optimus.ietf.org; Thu, 11 Dec 2003 05:30:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24295 for ; Thu, 11 Dec 2003 05:30:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUO5E-0007La-00 for midcom@ietf.org; Thu, 11 Dec 2003 05:30:12 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AUO5D-0007LL-00 for midcom@ietf.org; Thu, 11 Dec 2003 05:30:11 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hBBATc75057466 for ; Thu, 11 Dec 2003 11:29:42 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hBBATaw9057464 for ; Thu, 11 Dec 2003 11:29:36 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hBBATZ6x057459; Thu, 11 Dec 2003 11:29:36 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D596DE922C; Thu, 11 Dec 2003 11:29:33 +0100 (CET) Date: Thu, 11 Dec 2003 11:31:37 +0100 From: Juergen Quittek To: "Harrington, David" , Tom Taylor Cc: mibs@ops.ietf.org, midcom@ietf.org Subject: RE: [midcom] MIDCOM MIB design question Message-ID: <2147483647.1071142297@[10.1.1.171]> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA013B1747@NHROCMBX1.ets.enterasys.com> References: <6D745637A7E0F94DA070743C55CDA9BA013B1747@NHROCMBX1.ets.enterasys.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi David, --On 10.12.2003 21:24 Uhr -0500 Harrington, David wrote: > Hi Juergen, > > SNMP is a protocol that manipulates sets of data on remote devices. The > set of data is typically used by many users. You separate mib data sets > by the functionality they contain, not by which "user" will use it. > > It would be really helpful if you were more explicit about the > requirements and the separate objects you think are needed in each mib. Martin Stiemerling and I sent you a description of the requirements in November, but you did not reply. That's why I asked on the mibs mailing list. > Objects that "serve management purposes" means nothing to me. It depends > on the manager. Are you happier with "may be useful for fault, configuration, accounting, performance and/or security management"? I used the generic term not to describe exactly the functionality provided by this particular group of objects, but to separate this group from the other one containing managed objects that primarily serve for implementing the MIDCOM protocol which signals application layer requests to a middlebox and IMHO does NOT "serve management purposes". > I might have one network manager or application whose job is to monitor > performance, and he/it might use ifInOctets in its calculations. I might > have a second application whose job is to isolate faulty interfaces, and > it might use ifInOctets. I might have an intruder detection system that > watches for anomalies and it might use ifInOctets. I wouldn't want three > duplicate ifInOctet objects to rpvoide this information just because I > happen to have three different managers/users looking at the datum for > different purposes. As I said in the original message below, we aready identified separate groups of objects. We do not have the intention to duplicate any object. Just Martin and I found that we could idenitify a group of objects (the one implementing the MIDCOM protocol semantics) that is relevant to applications that want to use the MIDCOM protocol for signaling their application layer communication requests. These applications are no network management applications, i.e. applications "serving network management purposes". > You did list three things as management: > 1) the priority with which requested pinholes are configured in the > firewall, > 2) a table showing the mapping of MIDCOM pinholes to firewall resources > or of MIDCOM NAT sessions/bindings to NAT resources, > 3) a protocol statistics table listing the set of active MIDCOM > sessions, protocol errors, etc. > > I'm not quite sure what type of priority you are referring to in 1). > Priority relative to what? To other pinholes? To other firewall rules? > To other MIDCOM rules within a group? To other MIDCOM groups? The > priority of the operator performing the opeation? The priority of the > operation versus other tasks the device needs to perform? Sorry for not explaining it in sufficient detail. This is a request from Wes Hardaker which we discussed at the last MIDCOM MIB design team meeting in Minneapolis. Yes, the requirement is to set the priority of firewall rules requested via the MIDCOM protocol with respect to all other firewall rules entered by the administrator or a NMS. Firewall process rules in an order defined by the rule priority. The administrator certainly wants to be able to configure the priority of rules resulting from MIDCOM protocol operation such that he/she is still able to insert rules of higher priority. > The MIDCOM MIB manipulates the mappings of MIDCOM pinholes to resources, > so the map available to monitor this mapping belongs in the same mib, in > my opinion. You don't need to duplicate the information just so another > user can read it. As I said, there is no intention to duplicate anything. The point is that the MIDCOM protocol operates on a more abstract level where most concrete mappings are irrelevant to the application using the MIDCOM protocol. For network management applications, the ones that serve management purposes, it might be relevant to identify, which MIDCOM policy affects which resource, for example an application monitoring resource usage on middleboxes. But this is of no interest to the applications using the MIDCOM protocol. > Statistics are about the MIDCOM sessions and whatnot being configured in > this mib. You don't need to separate which mib this is in. Yes, statistics are rarely writeable. But statistics on open MIDCOM sessions does not belong to the information that should be available to an application using the MIDCOM protocol. It should be accessible only to application that are authorized to monitor the entire protocol engine. Just compare it to TCP: Not every user of the TCP protocol should be allowed to access objects in the the TCP-MIB module. > It is generally better to keep the status related to a functionality in > the same mib as the configuration of the functionality. Statistics are > part of status, and so are the configuration settings. Yes, I fully agree. But all objects serving configuration purposes are in the group that I labeled "serving management purposes". There is no configuration object in the group of objects serving the MIDCOM protocol. Thanks for your detailed comments, Juergen > dbh > >> -----Original Message----- >> From: Tom Taylor [mailto:taylor@nortelnetworks.com] >> Sent: Wednesday, December 10, 2003 1:13 PM >> To: Juergen Quittek >> Cc: mibs@ops.ietf.org; midcom@ietf.org >> Subject: Re: [midcom] MIDCOM MIB design question >> >> >> I'd say they should be in separate modules because they are >> likely to be >> implemented on separate boxes on the SNMP client side. >> >> Juergen Quittek wrote: >> >> > Dear all, >> > >> > In the MIDCOM working group we are developing a protocol >> for dynamically >> > requesting pinholes in firewalls and bindings/sessions on NATs. >> > >> > The working group decided to use SNMP as basic protocol and >> now we are >> > defining a MIDCOM MIB module. While doing this, we found >> that we are >> > defining two separate groups of objects: Objects >> implementing the MIDCOM >> > protocol (for which we already have a protocol semantics >> document, see >> > draft-ietf-midcom-semantics-06.txt) and objects serving management >> > purposes. >> > Management purposes include for example configurations, such as >> > - the priority with which requested pinholes are configured in the >> > firewall, >> > - a table showing the mapping of MIDCOM pinholes to >> firewall resources >> > or of MIDCOM NAT sessions/bindings to NAT resources >> > - a protocol statistics table listing the set of active >> MIDCOM sessions, >> > protocol errors, etc. >> > >> > For these two groups of objects there are also two separate >> groups of >> > users: >> > - middlebox controllers sending requests for dynamic >> pinholes and NAT >> > sessions/bindings >> > - network managers configuring the middlebox (firewall or NAT) and >> > monitoring its operation >> > >> > The middlebox controllers only need access to the objects >> implementing >> > the MIDCOM protocol. >> > >> > The network managers would rather use the objects serving >> management >> > purposes >> > although in some cases they might need to access the other >> group also. >> > >> > Now, we have a draft defining these objects and the >> following question: >> > >> > Does someone have an opinion about whether these two groups >> of objects >> > should be contained in a single MIB module or in two separate ones? >> > >> > Usually, this problem does not occur, because most control protocol, >> > say GSMP are not defined on top of SNMP. Therefore in GSMP there is >> > a clear separation between the protocol and the MIB with >> objects serving >> > network management purposes. But in our case, SNMP is used for both >> > purposes. >> > >> > Thanks, >> > >> > Juergen >> >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom >> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 05:49:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24677 for ; Thu, 11 Dec 2003 05:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUONS-000650-1p for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 05:49:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBAn2L8023353 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 05:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUONQ-00064H-QL; Thu, 11 Dec 2003 05:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUOMW-00063m-Ok for midcom@optimus.ietf.org; Thu, 11 Dec 2003 05:48:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24665 for ; Thu, 11 Dec 2003 05:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUOMS-0007be-00 for midcom@ietf.org; Thu, 11 Dec 2003 05:48:00 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AUOMR-0007bb-00 for midcom@ietf.org; Thu, 11 Dec 2003 05:47:59 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hBBAlQ75059963 for ; Thu, 11 Dec 2003 11:47:30 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hBBAhRGa059370 for ; Thu, 11 Dec 2003 11:43:27 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hBBAhQ6x059365; Thu, 11 Dec 2003 11:43:27 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id F14DCE92CF; Thu, 11 Dec 2003 11:43:24 +0100 (CET) Date: Thu, 11 Dec 2003 11:45:28 +0100 From: Juergen Quittek To: "Harrington, David" , Tom Taylor Cc: mibs@ops.ietf.org, midcom@ietf.org Subject: RE: [midcom] MIDCOM MIB design question Message-ID: <2147483647.1071143128@[10.1.1.171]> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA013B1748@NHROCMBX1.ets.enterasys.com> References: <6D745637A7E0F94DA070743C55CDA9BA013B1748@NHROCMBX1.ets.enterasys.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi David, --On 11.12.2003 1:40 Uhr -0500 Harrington, David wrote: > Hi Tom, > > So I have a pile of money in my house. There are two people outside my > house - one is my wife, and the other a thief. For simplicity, I could > have two doors in my house; one I would lock to keep the thief out, and > the other I'd leave unlocked so my wife could get in. How secure is my > money? I think the security community made experiences differing from yours. Let's take your example and replace the thief by one of your kids. You would give your kid AND your wife access to the coins you collect somewhere in the kitchen for giving tips to delivery service or for paying stamps and so on. But you probably would only give your wife access to your checking account and block access from your kids to the account. Coming back to the MIDCOM MIB problem. On one side, there is a set of objects that concerns the entire protocol operations: statistics, the list of entities that established policies using the MIDCOM protocol, the number of failed attempts to establish a MIDCOM session, etc. This should not be accessible to all potential entities that are allowed to use the MIDCOM protocol. On the other side, there is the set of objects implementing the MIDCOM protocol. This set should be accessible to a wider group of users. Now, Tom said that this security issue could be handled more easily if we would use separate modules. I do not see anything wrong with this. Thanks, Juergen > dbh > >> -----Original Message----- >> From: Tom Taylor [mailto:taylor@nortelnetworks.com] >> Sent: Wednesday, December 10, 2003 11:27 PM >> To: Harrington, David >> Cc: Juergen Quittek; mibs@ops.ietf.org; midcom@ietf.org >> Subject: Re: [midcom] MIDCOM MIB design question >> >> >> I know you can use views to separate out what one user sees >> vs. another, >> but I figured separation by module was cleaner. Juergen is talking >> about separating what the administrator is interested in from >> what the >> MIDCOM agent is interested in. Agreed that they both address >> the same >> underlying data structures, but I would think security setup would be >> simpler if you could specify access by module rather than >> having to do >> it object by object. >> >> Harrington, David wrote: >> >> > Hi Juergen, >> > >> > SNMP is a protocol that manipulates sets of data on remote >> devices. The >> > set of data is typically used by many users. You separate >> mib data sets >> > by the functionality they contain, not by which "user" will use it. >> > >> > It would be really helpful if you were more explicit about the >> > requirements and the separate objects you think are needed >> in each mib. >> > Objects that "serve management purposes" means nothing to >> me. It depends >> > on the manager. >> > >> > I might have one network manager or application whose job >> is to monitor >> > performance, and he/it might use ifInOctets in its >> calculations. I might >> > have a second application whose job is to isolate faulty >> interfaces, and >> > it might use ifInOctets. I might have an intruder detection >> system that >> > watches for anomalies and it might use ifInOctets. I >> wouldn't want three >> > duplicate ifInOctet objects to rpvoide this information >> just because I >> > happen to have three different managers/users looking at >> the datum for >> > different purposes. >> > >> > You did list three things as management: >> > 1) the priority with which requested pinholes are configured in the >> > firewall, >> > 2) a table showing the mapping of MIDCOM pinholes to >> firewall resources >> > or of MIDCOM NAT sessions/bindings to NAT resources, >> > 3) a protocol statistics table listing the set of active MIDCOM >> > sessions, protocol errors, etc. >> > >> > I'm not quite sure what type of priority you are referring to in 1). >> > Priority relative to what? To other pinholes? To other >> firewall rules? >> > To other MIDCOM rules within a group? To other MIDCOM groups? The >> > priority of the operator performing the opeation? The >> priority of the >> > operation versus other tasks the device needs to perform? >> > >> > The MIDCOM MIB manipulates the mappings of MIDCOM pinholes >> to resources, >> > so the map available to monitor this mapping belongs in the >> same mib, in >> > my opinion. You don't need to duplicate the information >> just so another >> > user can read it. >> > >> > Statistics are about the MIDCOM sessions and whatnot being >> configured in >> > this mib. You don't need to separate which mib this is in. >> > >> > It is generally better to keep the status related to a >> functionality in >> > the same mib as the configuration of the functionality. >> Statistics are >> > part of status, and so are the configuration settings. >> > >> > dbh >> > >> > >> >> -----Original Message----- >> >> From: Tom Taylor [mailto:taylor@nortelnetworks.com] >> >> Sent: Wednesday, December 10, 2003 1:13 PM >> >> To: Juergen Quittek >> >> Cc: mibs@ops.ietf.org; midcom@ietf.org >> >> Subject: Re: [midcom] MIDCOM MIB design question >> >> >> >> >> >> I'd say they should be in separate modules because they are >> >> likely to be >> >> implemented on separate boxes on the SNMP client side. >> >> >> >> Juergen Quittek wrote: >> >> >> >> >> >>> Dear all, >> >>> >> >>> In the MIDCOM working group we are developing a protocol >> >> >> >> for dynamically >> >> >> >>> requesting pinholes in firewalls and bindings/sessions on NATs. >> >>> >> >>> The working group decided to use SNMP as basic protocol and >> >> >> >> now we are >> >> >> >>> defining a MIDCOM MIB module. While doing this, we found >> >> >> >> that we are >> >> >> >>> defining two separate groups of objects: Objects >> >> >> >> implementing the MIDCOM >> >> >> >>> protocol (for which we already have a protocol semantics >> >> >> >> document, see >> >> >> >>> draft-ietf-midcom-semantics-06.txt) and objects serving management >> >>> purposes. >> >>> Management purposes include for example configurations, such as >> >>> - the priority with which requested pinholes are >> configured in the >> >>> firewall, >> >>> - a table showing the mapping of MIDCOM pinholes to >> >> >> >> firewall resources >> >> >> >>> or of MIDCOM NAT sessions/bindings to NAT resources >> >>> - a protocol statistics table listing the set of active >> >> >> >> MIDCOM sessions, >> >> >> >>> protocol errors, etc. >> >>> >> >>> For these two groups of objects there are also two separate >> >> >> >> groups of >> >> >> >>> users: >> >>> - middlebox controllers sending requests for dynamic >> >> >> >> pinholes and NAT >> >> >> >>> sessions/bindings >> >>> - network managers configuring the middlebox (firewall or NAT) and >> >>> monitoring its operation >> >>> >> >>> The middlebox controllers only need access to the objects >> >> >> >> implementing >> >> >> >>> the MIDCOM protocol. >> >>> >> >>> The network managers would rather use the objects serving >> >> >> >> management >> >> >> >>> purposes >> >>> although in some cases they might need to access the other >> >> >> >> group also. >> >> >> >>> Now, we have a draft defining these objects and the >> >> >> >> following question: >> >> >> >>> Does someone have an opinion about whether these two groups >> >> >> >> of objects >> >> >> >>> should be contained in a single MIB module or in two separate ones? >> >>> >> >>> Usually, this problem does not occur, because most control >> protocol, >> >>> say GSMP are not defined on top of SNMP. Therefore in >> GSMP there is >> >>> a clear separation between the protocol and the MIB with >> >> >> >> objects serving >> >> >> >>> network management purposes. But in our case, SNMP is >> used for both >> >>> purposes. >> >>> >> >>> Thanks, >> >>> >> >>> Juergen >> >> >> >> >> >> _______________________________________________ >> >> midcom mailing list >> >> midcom@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/midcom >> >> >> > >> > >> >> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 09:35:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02038 for ; Thu, 11 Dec 2003 09:35:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURuI-0006L3-TK for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 09:35:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBEZAxe024365 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 09:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURuA-0006KN-So; Thu, 11 Dec 2003 09:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURtd-0006K2-NK for midcom@optimus.ietf.org; Thu, 11 Dec 2003 09:34:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02020 for ; Thu, 11 Dec 2003 09:34:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AURtb-0004wv-00 for midcom@ietf.org; Thu, 11 Dec 2003 09:34:28 -0500 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AURtb-0004ws-00 for midcom@ietf.org; Thu, 11 Dec 2003 09:34:27 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id JAA04016 for ; Thu, 11 Dec 2003 09:35:30 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma003755; Thu, 11 Dec 03 09:34:23 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 11 Dec 2003 09:33:17 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 11 Dec 2003 09:33:17 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Dec 2003 09:33:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Dec 2003 09:33:17 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA013B175C@NHROCMBX1.ets.enterasys.com> Thread-Topic: MIDCOM MIB access control Thread-Index: AcO/1EeMkavpVgXPSAmB0pFaFO75LgAEggnA From: "Harrington, David" To: "Juergen Quittek" , "Tom Taylor" Cc: , X-OriginalArrivalTime: 11 Dec 2003 14:33:21.0470 (UTC) FILETIME=[B9FB05E0:01C3BFF3] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:93.0328 M:94.5022 P:95.9108 R:95.9108 S:24.3311 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Subject: [midcom] MIDCOM MIB access control Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, > I think the security community made experiences differing from yours. >=20 > Let's take your example and replace the thief by one of your kids. > You would give your kid AND your wife access to the coins you collect > somewhere in the kitchen for giving tips to delivery service or for > paying stamps and so on. But you probably would only give your wife > access to your checking account and block access from your kids to the > account. My response was to Tom's message, which was about the SAME underlying instrumentation, and the only thing two mibs provide are two interfaces to the same underlying data structures.=20 "Agreed that they both address the same underlying data structures, but I would think security setup would be simpler if you could specify access by module rather than having to do it object by object." That's not two piles of money; it's two checkbooks to the same underlying account. One of the things you really need is a mechanism that allows you to specify different permissions for different persons to the same datastore. That's what VACM provides. Dbh _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 09:58:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02814 for ; Thu, 11 Dec 2003 09:58:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSGQ-0007Zk-Ea for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 09:58:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBEw28G029119 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 09:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSGO-0007ZG-Rf; Thu, 11 Dec 2003 09:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSGF-0007Yv-6V for midcom@optimus.ietf.org; Thu, 11 Dec 2003 09:57:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02796 for ; Thu, 11 Dec 2003 09:57:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUSGD-0005Ut-00 for midcom@ietf.org; Thu, 11 Dec 2003 09:57:49 -0500 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AUSGC-0005Uq-00 for midcom@ietf.org; Thu, 11 Dec 2003 09:57:48 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id JAA06092 for ; Thu, 11 Dec 2003 09:58:48 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma006038; Thu, 11 Dec 03 09:58:26 -0500 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 11 Dec 2003 09:57:19 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 11 Dec 2003 09:57:15 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Dec 2003 09:57:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] MIDCOM MIB design question Date: Thu, 11 Dec 2003 09:57:05 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA013B175E@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] MIDCOM MIB design question Thread-Index: AcO/3dACAQvdX6PXRg6aVi7TmuyGqwAFi/Ug From: "Harrington, David" To: "Dave Shield" , "Juergen Quittek" Cc: "Tom Taylor" , , X-OriginalArrivalTime: 11 Dec 2003 14:57:02.0487 (UTC) FILETIME=[08F90270:01C3BFF7] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:83.3688 M:99.4056 P:95.9108 R:95.9108 S:79.3563 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks Dave. I agree. Having two separate modules is not wrong; but it isn't necessary, and it doesn't bring any real benefits. You can simplify the VACM config using separate subtrees within the same module, or just separate tables.=20 I expect that the network manager may want to look at some of the information being set by the MIDCOM agent, so two users will need access to the same data. A MIDCOM agent that had access to the statistics of different middleboxes might be able to choose which middlebox would provide the fastest/cleanest path between endpoints, so while not required to implement MIDCOM, access to the management information might be helpful.=20 The data involved here appears to be closely related, and I recommend it be kept together in the same mib. The separation into different modules is just an unnecessary complexity based on thinking about two different applications and the specific objects they use. If we follow that reasoning, do we need to define a new mib module for every type of application that might look at MIDCOM data? Should we put the traps into a separate module because a fault/trap manager might only look at the traps? Should we separate the statistics from the mappings tables because some performance management applications only need the statistics and not the maps? Should we put NAT-related MIDCOM statistics in one module and the firewall-related MIDCOM statistics in another module because applications might focus on one or the other but not both? This is not a good way to approach defining a data set to monitor and manage MIDCOM functionality. -- You should understand something sbout me. One of the things I usually fight against is large modules; I prefer smaller modules because it makes it easier to advance the individual pieces. But you can break it down too fine as well, and then need to create multiple dependencies between the modules, which causes both to advance simultaneously in the advancement process. I also fight against that. I think using two mibs makes it more complex than necessary. How much more complex depends on how you do it. If N is counting the things created in M, you have a N->M normative dependency. If M is defining the priority of the rules created in N, then you have a M->N normative dependency. These modules will never be able to advance independent of each other. You haven't discussed whether your intention would be to publish two mibs in the same document, or different documents. If you put two mibs in the same document, then the issue of normative references between documents goes away and we can ignore it. If you define two mibs within the same document, you create the need to import a lot of the objects from one into the other. Under those conditions, I don't see a real benefit from doing this. There aren't major downsides either, but it does increase the complexity unnecessarily when you could simply use subtrees within the same mib. dbh > -----Original Message----- > From: Dave Shield [mailto:D.T.Shield@csc.liv.ac.uk]=20 > Sent: Thursday, December 11, 2003 6:55 AM > To: Juergen Quittek > Cc: Harrington, David; Tom Taylor; mibs@ops.ietf.org; midcom@ietf.org > Subject: Re: [midcom] MIDCOM MIB design question=20 >=20 >=20 >=20 > > Coming back to the MIDCOM MIB problem. On one side, there=20 > is a set of > > objects that concerns the entire protocol operations:=20 > statistics, the > > list of entities that established policies using the MIDCOM=20 > protocol, > > the number of failed attempts to establish a MIDCOM session, etc. > > This should not be accessible to all potential entities=20 > that are allowed > > to use the MIDCOM protocol. On the other side, there is the set of > > objects implementing the MIDCOM protocol. This set should=20 > be accessible > > to a wider group of users. > >=20 > > Now, Tom said that this security issue could be handled=20 > more easily if > > we would use separate modules. I do not see anything wrong=20 > with this. >=20 >=20 > Pardon me for chipping in, but I'm not quite sure how the=20 > split between > MIB modules makes any difference to the security aspects of things. > Surely by the time access controls are applied, the MIB=20 > module(s) will have > already been combined (even if only logically) into a single OID tree? >=20 > I can see that having a suitable hierarchical structure for=20 > the management > objects could well aid (or hinder) the configuration of=20 > appropriate access > control settings. But what difference does it make whether=20 > these objects > are defined in one module, or two? (Or even one module per object!) >=20 >=20 > The question of how to divide objects between MIB modules feels to be > more related to issues of convenience for implementation=20 > and/or revision > management. >=20 > So what am I missing? >=20 > Dave >=20 >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 10:04:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03451 for ; Thu, 11 Dec 2003 10:04:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSME-0007p5-6e for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:04:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBF42om030007 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSMD-0007nh-52; Thu, 11 Dec 2003 10:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPR0-0008FL-6t for midcom@optimus.ietf.org; Thu, 11 Dec 2003 06:56:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26390 for ; Thu, 11 Dec 2003 06:56:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPQv-00012j-00 for midcom@ietf.org; Thu, 11 Dec 2003 06:56:41 -0500 Received: from mx3.liv.ac.uk ([138.253.100.181]) by ietf-mx with esmtp (Exim 4.12) id 1AUPQu-00012V-00 for midcom@ietf.org; Thu, 11 Dec 2003 06:56:40 -0500 Received: from mailhub1.liv.ac.uk ([138.253.100.94]) by mx3.liv.ac.uk with esmtp (Exim 4.24) id 1AUPQR-0007LS-LD; Thu, 11 Dec 2003 11:56:11 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mailhub1.liv.ac.uk) by mailhub1.liv.ac.uk with esmtp (Exim 4.24) id 1AUPQR-0006kd-J6; Thu, 11 Dec 2003 11:56:11 +0000 Received: from tethys.server.csc.liv.ac.uk ([138.253.184.237]) by mailhub1.liv.ac.uk with esmtp (Exim 4.24) id 1AUPQR-0006ka-Fg; Thu, 11 Dec 2003 11:56:11 +0000 Received: from lune.server.csc.liv.ac.uk (bin@lune [138.253.184.241]) by tethys.server.csc.liv.ac.uk (8.11.1 - (Revision 1.5)/LUCS-DTS-3.0M10) with ESMTP id hBBBuBP13494; Thu, 11 Dec 2003 11:56:11 GMT Received: from daves.staff.csc.liv.ac.uk (IDENT:daves@daves [138.253.185.91]) by lune.server.csc.liv.ac.uk (8.9.3 (PHNE_28760)/LUCS-DTS-3.0D10) with ESMTP id LAA15613; Thu, 11 Dec 2003 11:56:09 GMT Received: from daves.staff.csc.liv.ac.uk (daves@localhost) by daves.staff.csc.liv.ac.uk (8.12.8/8.12.8/Submit) with ESMTP id hBBBtPBD027854; Thu, 11 Dec 2003 11:55:25 GMT Message-Id: <200312111155.hBBBtPBD027854@daves.staff.csc.liv.ac.uk> X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 To: Juergen Quittek cc: "Harrington, David" , Tom Taylor , mibs@ops.ietf.org, midcom@ietf.org Subject: Re: [midcom] MIDCOM MIB design question In-Reply-To: Message from Juergen Quittek of "Thu, 11 Dec 2003 11:45:28 +0100." <2147483647.1071143128@[10.1.1.171]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Dec 2003 11:55:25 +0000 From: Dave Shield Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Coming back to the MIDCOM MIB problem. On one side, there is a set of > objects that concerns the entire protocol operations: statistics, the > list of entities that established policies using the MIDCOM protocol, > the number of failed attempts to establish a MIDCOM session, etc. > This should not be accessible to all potential entities that are allowed > to use the MIDCOM protocol. On the other side, there is the set of > objects implementing the MIDCOM protocol. This set should be accessible > to a wider group of users. > > Now, Tom said that this security issue could be handled more easily if > we would use separate modules. I do not see anything wrong with this. Pardon me for chipping in, but I'm not quite sure how the split between MIB modules makes any difference to the security aspects of things. Surely by the time access controls are applied, the MIB module(s) will have already been combined (even if only logically) into a single OID tree? I can see that having a suitable hierarchical structure for the management objects could well aid (or hinder) the configuration of appropriate access control settings. But what difference does it make whether these objects are defined in one module, or two? (Or even one module per object!) The question of how to divide objects between MIB modules feels to be more related to issues of convenience for implementation and/or revision management. So what am I missing? Dave _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 10:04:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03458 for ; Thu, 11 Dec 2003 10:04:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSME-0007p0-6G for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:04:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBF420Q030008 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSMD-0007np-Hx; Thu, 11 Dec 2003 10:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUQSx-0002cl-Pk for midcom@optimus.ietf.org; Thu, 11 Dec 2003 08:02:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28652 for ; Thu, 11 Dec 2003 08:02:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUQSw-0002gR-00 for midcom@ietf.org; Thu, 11 Dec 2003 08:02:50 -0500 Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 1AUQSv-0002fo-00 for midcom@ietf.org; Thu, 11 Dec 2003 08:02:49 -0500 Received: from tom3 (1Cust191.tnt29.lnd3.gbr.da.uu.net [62.188.120.191]) by colossus.systems.pipex.net (Postfix) with SMTP id AEFE1160003BE; Thu, 11 Dec 2003 13:02:14 +0000 (GMT) Message-ID: <004701c3bfe7$03ecb160$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Juergen Quittek" Cc: , Subject: Re: [midcom] MIDCOM MIB design question Date: Thu, 11 Dec 2003 12:38:35 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree with Dave that it is mostly the non-technical aspects, the administration, that should colour your choice, the likely future evolution, the need for revision, conformance, ownership by working groups/IANA/ID editors and such like. A MIB module is a useful chunk of definition to be administered as one item. Technically, once it is in an agent, then you just have the one tree of objects and how many modules the tree came from is irrelevant. But I suggest you consider the tree structure carefully. Several aspects of SNMP revolve around the tree structure and it is much easier to define eg midcom.4 as available to all and midcom.5 as restricted to administrators, as opposed to having to define eg midcom.4 as available to all except for midcom.4.2, midcom.4.4.1 and the table entries of midcom.4.5 with entries starting with x... except on weekends and Bank Holidays :-) ie group your objects in the tree structure so that whole branches have the same pattern of access, use, security etc. This can be achieved - or not - with one or 100 modules.. Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Tom Taylor To: Juergen Quittek Cc: mibs@ops.ietf.org ; midcom@ietf.org Date: 11 December 2003 10:46 Subject: Re: [midcom] MIDCOM MIB design question >I'd say they should be in separate modules because they are likely to be >implemented on separate boxes on the SNMP client side. > >Juergen Quittek wrote: > >> Dear all, >> >> In the MIDCOM working group we are developing a protocol for dynamically >> requesting pinholes in firewalls and bindings/sessions on NATs. >> >> The working group decided to use SNMP as basic protocol and now we are >> defining a MIDCOM MIB module. While doing this, we found that we are >> defining two separate groups of objects: Objects implementing the MIDCOM >> protocol (for which we already have a protocol semantics document, see >> draft-ietf-midcom-semantics-06.txt) and objects serving management >> purposes. >> Management purposes include for example configurations, such as >> - the priority with which requested pinholes are configured in the >> firewall, >> - a table showing the mapping of MIDCOM pinholes to firewall resources >> or of MIDCOM NAT sessions/bindings to NAT resources >> - a protocol statistics table listing the set of active MIDCOM sessions, >> protocol errors, etc. >> >> For these two groups of objects there are also two separate groups of >> users: >> - middlebox controllers sending requests for dynamic pinholes and NAT >> sessions/bindings >> - network managers configuring the middlebox (firewall or NAT) and >> monitoring its operation >> >> The middlebox controllers only need access to the objects implementing >> the MIDCOM protocol. >> >> The network managers would rather use the objects serving management >> purposes >> although in some cases they might need to access the other group also. >> >> Now, we have a draft defining these objects and the following question: >> >> Does someone have an opinion about whether these two groups of objects >> should be contained in a single MIB module or in two separate ones? >> >> Usually, this problem does not occur, because most control protocol, >> say GSMP are not defined on top of SNMP. Therefore in GSMP there is >> a clear separation between the protocol and the MIB with objects serving >> network management purposes. But in our case, SNMP is used for both >> purposes. >> >> Thanks, >> >> Juergen > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 10:28:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06274 for ; Thu, 11 Dec 2003 10:28:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSjS-0000s4-7A for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBFS22D003347 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSjQ-0000rd-TU; Thu, 11 Dec 2003 10:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSii-0000qb-9N for midcom@optimus.ietf.org; Thu, 11 Dec 2003 10:27:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06199 for ; Thu, 11 Dec 2003 10:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUSiV-0006Wr-00 for midcom@ietf.org; Thu, 11 Dec 2003 10:27:03 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AUSiU-0006WF-00 for midcom@ietf.org; Thu, 11 Dec 2003 10:27:02 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBBFQDI00415; Thu, 11 Dec 2003 10:26:13 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLST2Z91; Thu, 11 Dec 2003 10:26:13 -0500 Received: from nortelnetworks.com (acart1px.ca.nortel.com [47.129.130.149]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWNAY3; Thu, 11 Dec 2003 10:26:14 -0500 Message-ID: <3FD88C94.3040900@nortelnetworks.com> Date: Thu, 11 Dec 2003 10:26:12 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Harrington, David" CC: Dave Shield , Juergen Quittek , midcom@ietf.org Subject: Re: [midcom] MIDCOM MIB design question References: <6D745637A7E0F94DA070743C55CDA9BA013B175E@NHROCMBX1.ets.enterasys.com> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA013B175E@NHROCMBX1.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit OK, I surrender. Looks like I ventured into an area the MIB experts command. Harrington, David wrote: > Thanks Dave. > I agree. > > Having two separate modules is not wrong; but it isn't necessary, and it > doesn't bring any real benefits. You can simplify the VACM config using > separate subtrees within the same module, or just separate tables. > > I expect that the network manager may want to look at some of the > information being set by the MIDCOM agent, so two users will need access > to the same data. A MIDCOM agent that had access to the statistics of > different middleboxes might be able to choose which middlebox would > provide the fastest/cleanest path between endpoints, so while not > required to implement MIDCOM, access to the management information might > be helpful. > > The data involved here appears to be closely related, and I recommend it > be kept together in the same mib. The separation into different > modules is just an unnecessary complexity based on thinking about two > different applications and the specific objects they use. If we follow > that reasoning, do we need to define a new mib module for every type of > application that might look at MIDCOM data? Should we put the traps into > a separate module because a fault/trap manager might only look at the > traps? Should we separate the statistics from the mappings tables > because some performance management applications only need the > statistics and not the maps? Should we put NAT-related MIDCOM statistics > in one module and the firewall-related MIDCOM statistics in another > module because applications might focus on one or the other but not > both? > > This is not a good way to approach defining a data set to monitor and > manage MIDCOM functionality. > -- > > You should understand something sbout me. One of the things I usually > fight against is large modules; I prefer smaller modules because it > makes it easier to advance the individual pieces. But you can break it > down too fine as well, and then need to create multiple dependencies > between the modules, which causes both to advance simultaneously in the > advancement process. I also fight against that. I think using two mibs > makes it more complex than necessary. How much more complex depends on > how you do it. > > If N is counting the things created in M, you have a N->M normative > dependency. If M is defining the priority of the rules created in N, > then you have a M->N normative dependency. These modules will never be > able to advance independent of each other. > > You haven't discussed whether your intention would be to publish two > mibs in the same document, or different documents. If you put two mibs > in the same document, then the issue of normative references between > documents goes away and we can ignore it. > > If you define two mibs within the same document, you create the need to > import a lot of the objects from one into the other. Under those > conditions, I don't see a real benefit from doing this. There aren't > major downsides either, but it does increase the complexity > unnecessarily when you could simply use subtrees within the same mib. > > dbh > > >>-----Original Message----- >>From: Dave Shield [mailto:D.T.Shield@csc.liv.ac.uk] >>Sent: Thursday, December 11, 2003 6:55 AM >>To: Juergen Quittek >>Cc: Harrington, David; Tom Taylor; mibs@ops.ietf.org; midcom@ietf.org >>Subject: Re: [midcom] MIDCOM MIB design question >> >> >> >> >>>Coming back to the MIDCOM MIB problem. On one side, there >> >>is a set of >> >>>objects that concerns the entire protocol operations: >> >>statistics, the >> >>>list of entities that established policies using the MIDCOM >> >>protocol, >> >>>the number of failed attempts to establish a MIDCOM session, etc. >>>This should not be accessible to all potential entities >> >>that are allowed >> >>>to use the MIDCOM protocol. On the other side, there is the set of >>>objects implementing the MIDCOM protocol. This set should >> >>be accessible >> >>>to a wider group of users. >>> >>>Now, Tom said that this security issue could be handled >> >>more easily if >> >>>we would use separate modules. I do not see anything wrong >> >>with this. >> >> >>Pardon me for chipping in, but I'm not quite sure how the >>split between >>MIB modules makes any difference to the security aspects of things. >>Surely by the time access controls are applied, the MIB >>module(s) will have >>already been combined (even if only logically) into a single OID tree? >> >>I can see that having a suitable hierarchical structure for >>the management >>objects could well aid (or hinder) the configuration of >>appropriate access >>control settings. But what difference does it make whether >>these objects >>are defined in one module, or two? (Or even one module per object!) >> >> >>The question of how to divide objects between MIB modules feels to be >>more related to issues of convenience for implementation >>and/or revision >>management. >> >>So what am I missing? >> >>Dave >> >> > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 10:38:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07131 for ; Thu, 11 Dec 2003 10:38:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUStB-0001Rt-Bv for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:38:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBFc5Ap005550 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:38:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSt7-0001QH-Fb; Thu, 11 Dec 2003 10:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSt2-0001Ov-QZ for midcom@optimus.ietf.org; Thu, 11 Dec 2003 10:37:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07072 for ; Thu, 11 Dec 2003 10:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUSt0-0006t0-00 for midcom@ietf.org; Thu, 11 Dec 2003 10:37:54 -0500 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AUSsz-0006su-00 for midcom@ietf.org; Thu, 11 Dec 2003 10:37:53 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA09673 for ; Thu, 11 Dec 2003 10:38:55 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma009636; Thu, 11 Dec 03 10:38:02 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 11 Dec 2003 10:36:56 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 11 Dec 2003 10:36:56 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Dec 2003 10:36:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] MIDCOM MIB design question Date: Thu, 11 Dec 2003 10:36:50 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA013B1761@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] MIDCOM MIB design question Thread-Index: AcO/09R7oVdRj5xTTlu6LVpykdtqmAAKJYgw From: "Harrington, David" To: "Tom Taylor" , "Juergen Quittek" Cc: , X-OriginalArrivalTime: 11 Dec 2003 15:36:56.0508 (UTC) FILETIME=[9BEB9FC0:01C3BFFC] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:83.3688 M:99.5542 P:95.9108 R:95.9108 S:78.2196 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Tom, I didn't understand this comment. Can you explain further what boxes you are referring to, and which functionality would be implemented on each? Thanks, dbh > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com]=20 > Sent: Wednesday, December 10, 2003 1:13 PM > To: Juergen Quittek > Cc: mibs@ops.ietf.org; midcom@ietf.org > Subject: Re: [midcom] MIDCOM MIB design question >=20 >=20 > I'd say they should be in separate modules because they are=20 > likely to be=20 > implemented on separate boxes on the SNMP client side. >=20 > Juergen Quittek wrote: >=20 > > Dear all, > >=20 > > In the MIDCOM working group we are developing a protocol=20 > for dynamically > > requesting pinholes in firewalls and bindings/sessions on NATs. > >=20 > > The working group decided to use SNMP as basic protocol and=20 > now we are > > defining a MIDCOM MIB module. While doing this, we found=20 > that we are > > defining two separate groups of objects: Objects=20 > implementing the MIDCOM > > protocol (for which we already have a protocol semantics=20 > document, see > > draft-ietf-midcom-semantics-06.txt) and objects serving management=20 > > purposes. > > Management purposes include for example configurations, such as > > - the priority with which requested pinholes are configured in the=20 > > firewall, > > - a table showing the mapping of MIDCOM pinholes to=20 > firewall resources > > or of MIDCOM NAT sessions/bindings to NAT resources > > - a protocol statistics table listing the set of active=20 > MIDCOM sessions, > > protocol errors, etc. > >=20 > > For these two groups of objects there are also two separate=20 > groups of=20 > > users: > > - middlebox controllers sending requests for dynamic=20 > pinholes and NAT > > sessions/bindings > > - network managers configuring the middlebox (firewall or NAT) and > > monitoring its operation > >=20 > > The middlebox controllers only need access to the objects=20 > implementing > > the MIDCOM protocol. > >=20 > > The network managers would rather use the objects serving=20 > management=20 > > purposes > > although in some cases they might need to access the other=20 > group also. > >=20 > > Now, we have a draft defining these objects and the=20 > following question: > >=20 > > Does someone have an opinion about whether these two groups=20 > of objects > > should be contained in a single MIB module or in two separate ones? > >=20 > > Usually, this problem does not occur, because most control protocol, > > say GSMP are not defined on top of SNMP. Therefore in GSMP there is > > a clear separation between the protocol and the MIB with=20 > objects serving > > network management purposes. But in our case, SNMP is used for both > > purposes. > >=20 > > Thanks, > >=20 > > Juergen >=20 >=20 >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 10:49:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07519 for ; Thu, 11 Dec 2003 10:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUT3m-0001m8-QE for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:49:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBFn2th006807 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUT3l-0001lf-8J; Thu, 11 Dec 2003 10:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUT2n-0001kz-2O for midcom@optimus.ietf.org; Thu, 11 Dec 2003 10:48:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07495 for ; Thu, 11 Dec 2003 10:47:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUT2k-00073j-00 for midcom@ietf.org; Thu, 11 Dec 2003 10:47:58 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AUT2j-00073S-00 for midcom@ietf.org; Thu, 11 Dec 2003 10:47:57 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hBBFlJ75088192 for ; Thu, 11 Dec 2003 16:47:22 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hBBFlHZB088176 for ; Thu, 11 Dec 2003 16:47:17 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hBBFlF6x088170; Thu, 11 Dec 2003 16:47:17 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1D1A7CFD9F; Thu, 11 Dec 2003 16:47:14 +0100 (CET) Date: Thu, 11 Dec 2003 16:49:17 +0100 From: Juergen Quittek To: "Harrington, David" , Tom Taylor Cc: mibs@ops.ietf.org, midcom@ietf.org Message-ID: <2147483647.1071161357@[10.1.1.171]> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA013B175C@NHROCMBX1.ets.enterasys.com> References: <6D745637A7E0F94DA070743C55CDA9BA013B175C@NHROCMBX1.ets.enterasys.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [midcom] Re: MIDCOM MIB access control Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Dave, --On 11.12.2003 9:33 Uhr -0500 Harrington, David wrote: > Hi, > >> I think the security community made experiences differing from yours. >> >> Let's take your example and replace the thief by one of your kids. >> You would give your kid AND your wife access to the coins you collect >> somewhere in the kitchen for giving tips to delivery service or for >> paying stamps and so on. But you probably would only give your wife >> access to your checking account and block access from your kids to the >> account. > > My response was to Tom's message, which was about the SAME underlying > instrumentation, and the only thing two mibs provide are two interfaces > to the same underlying data structures. You are confusing the terms 'instrumentation' and 'data structure'. No Tom's message was not about the SAME underlying instrumentation, but yes, it was about the same underlying data structure. > "Agreed that they both address the same underlying data > structures, but I would think security setup would be simpler if you > could specify access by module rather than having to do it object by > object." > > That's not two piles of money; it's two checkbooks to the same > underlying account. One of the things you really need is a mechanism > that allows you to specify different permissions for different persons > to the same datastore. That's what VACM provides. Yes, it's not two piles of money. But that is where the example fails to explain the issue well. Anyway I agree with Dave Shield and Tom Patch, that simplicity of security configuration is not among the really relevant criteria for our discussion. Thanks, Juergen > Dbh _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 10:53:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07639 for ; Thu, 11 Dec 2003 10:53:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUT7d-0001uL-0P for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:53:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBFr0Pb007307 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUT7c-0001tl-OI; Thu, 11 Dec 2003 10:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUT6f-0001sC-Kj for midcom@optimus.ietf.org; Thu, 11 Dec 2003 10:52:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07597 for ; Thu, 11 Dec 2003 10:51:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUT6d-0007BL-00 for midcom@ietf.org; Thu, 11 Dec 2003 10:51:59 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AUT6c-0007Aj-00 for midcom@ietf.org; Thu, 11 Dec 2003 10:51:58 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBBFpB516668; Thu, 11 Dec 2003 10:51:11 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLST25YA; Thu, 11 Dec 2003 10:51:11 -0500 Received: from nortelnetworks.com (acart1px.ca.nortel.com [47.129.130.149]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWNAYV; Thu, 11 Dec 2003 10:51:11 -0500 Message-ID: <3FD8926E.9000403@nortelnetworks.com> Date: Thu, 11 Dec 2003 10:51:10 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Harrington, David" CC: "Tom-PT Taylor" , Juergen Quittek , midcom@ietf.org Subject: Re: [midcom] MIDCOM MIB design question References: <6D745637A7E0F94DA070743C55CDA9BA013B1761@NHROCMBX1.ets.enterasys.com> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA013B1761@NHROCMBX1.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The MIDCOM Agent is one box, the middlebox administrator's host is another. Harrington, David wrote: > Hi Tom, > > I didn't understand this comment. Can you explain further what boxes you > are referring to, and which functionality would be implemented on each? > > Thanks, > dbh > > >>-----Original Message----- >>From: Tom Taylor [mailto:taylor@nortelnetworks.com] >>Sent: Wednesday, December 10, 2003 1:13 PM >>To: Juergen Quittek >>Cc: mibs@ops.ietf.org; midcom@ietf.org >>Subject: Re: [midcom] MIDCOM MIB design question >> >> >>I'd say they should be in separate modules because they are >>likely to be >>implemented on separate boxes on the SNMP client side. >> > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 10:55:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07746 for ; Thu, 11 Dec 2003 10:55:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUT9a-000293-P3 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:55:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBFt2VW008217 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 10:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUT9Z-00028F-9O; Thu, 11 Dec 2003 10:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUT9W-00027y-Gr for midcom@optimus.ietf.org; Thu, 11 Dec 2003 10:54:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07722 for ; Thu, 11 Dec 2003 10:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUT9T-0007EL-00 for midcom@ietf.org; Thu, 11 Dec 2003 10:54:56 -0500 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AUT9T-0007EF-00 for midcom@ietf.org; Thu, 11 Dec 2003 10:54:55 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA13345 for ; Thu, 11 Dec 2003 10:55:57 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma012461; Thu, 11 Dec 03 10:53:02 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 11 Dec 2003 10:51:58 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 11 Dec 2003 10:51:58 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Dec 2003 10:51:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] MIDCOM MIB design question Date: Thu, 11 Dec 2003 10:51:57 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA013B1767@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] MIDCOM MIB design question Thread-Index: AcO/+UOkSeyMTWqUTsy2OubFCPaPrAAA/7Dg From: "Harrington, David" To: X-OriginalArrivalTime: 11 Dec 2003 15:51:58.0055 (UTC) FILETIME=[B548C770:01C3BFFE] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:80.8653 M:99.5542 P:95.9108 R:95.9108 S:34.9733 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Just to keep the discussion light, here are a few private comments my example drew: The thief would be happy with the money but the wife would want the house. Does your wife know anything about your relationship with the thief? If so, I'd say you're toast even if you lock both doors. I was not sure which of the two was a more severe threat. The Thief takes something once.... wives.... oh well. No flames please, :-) dbh =20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 12:08:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10120 for ; Thu, 11 Dec 2003 12:08:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUIF-00065j-Dt for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 12:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBH83Tw023407 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 12:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUID-00064o-RJ; Thu, 11 Dec 2003 12:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUI4-00061l-It for midcom@optimus.ietf.org; Thu, 11 Dec 2003 12:07:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10061 for ; Thu, 11 Dec 2003 12:07:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUUI3-0000vz-00 for midcom@ietf.org; Thu, 11 Dec 2003 12:07:51 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AUUI2-0000uF-00 for midcom@ietf.org; Thu, 11 Dec 2003 12:07:50 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hBBH7F75094002 for ; Thu, 11 Dec 2003 18:07:19 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hBBH7Ei5094001 for ; Thu, 11 Dec 2003 18:07:14 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hBBH7D6x093997; Thu, 11 Dec 2003 18:07:14 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BFCC4E8E33; Thu, 11 Dec 2003 18:07:11 +0100 (CET) Date: Thu, 11 Dec 2003 18:09:16 +0100 From: Juergen Quittek To: "Harrington, David" Cc: Tom Taylor , mibs@ops.ietf.org, midcom@ietf.org Message-ID: <2147483647.1071166156@[10.1.1.171]> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA013B175E@NHROCMBX1.ets.enterasys.com> References: <6D745637A7E0F94DA070743C55CDA9BA013B175E@NHROCMBX1.ets.enterasys.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [midcom] RE: MIDCOM MIB design question Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David, Thanks again for your comments. --On 11.12.2003 9:57 Uhr -0500 Harrington, David wrote: > Thanks Dave. > I agree. > > Having two separate modules is not wrong; but it isn't necessary, and it > doesn't bring any real benefits. You can simplify the VACM config using > separate subtrees within the same module, or just separate tables. Agreed. > I expect that the network manager may want to look at some of the > information being set by the MIDCOM agent, so two users will need access > to the same data. A MIDCOM agent that had access to the statistics of > different middleboxes might be able to choose which middlebox would > provide the fastest/cleanest path between endpoints, so while not > required to implement MIDCOM, access to the management information might > be helpful. I see your point, but I think there are very few web browsers that check the MIB of a web server before selecting which one to choose. > The data involved here appears to be closely related, and I recommend it > be kept together in the same mib. The separation into different > modules is just an unnecessary complexity based on thinking about two > different applications and the specific objects they use. If we follow > that reasoning, do we need to define a new mib module for every type of > application that might look at MIDCOM data? Should we put the traps into > a separate module because a fault/trap manager might only look at the > traps? Should we separate the statistics from the mappings tables > because some performance management applications only need the > statistics and not the maps? Should we put NAT-related MIDCOM statistics > in one module and the firewall-related MIDCOM statistics in another > module because applications might focus on one or the other but not > both? David, you are exaggerating. I am asking for advice whether or not concerning a split into two modules. I have a preference, but in the end I want to make the optimal choice, whatever it is. And I want to understand the choice. > This is not a good way to approach defining a data set to monitor and > manage MIDCOM functionality. Agreed. The exaggerated examples are to be voided. > > You should understand something sbout me. One of the things I usually > fight against is large modules; OK. I understand you are a fighter against large modules. You have my full support. I hate unnecessary complexity, particularly in tricky and political things such as standard MIB modules ;-) > I prefer smaller modules because it > makes it easier to advance the individual pieces. But you can break it > down too fine as well, and then need to create multiple dependencies > between the modules, which causes both to advance simultaneously in the > advancement process. I also fight against that. Again, you have my full support. However, I did not raise the issue, because I just WANT to split the module into two. Initially Suresh, Martin and I worked on a single module. Then we discovered that there are two portions used by different applications and not having many dependencies among each other. One portion (the MIDCOM Protocol portion) is completely independent and the other portion would have to import three index objects and use them for providing information about resources used per policy. Also, the second portion is optional while the first one is mandatory. Therefore, we considered the idea of separating them. But we did not just do it but asked for advice first. And that's where we are now. > I think using two mibs > makes it more complex than necessary. How much more complex depends on > how you do it. OK. You say: if you can do it in one MIB module, choose one. > If N is counting the things created in M, you have a N->M normative > dependency. If M is defining the priority of the rules created in N, M is defining ONE priority applying to ALL rules created in N. > then you have a M->N normative dependency. These modules will never be > able to advance independent of each other. Thanks for the lecture. The overlap between the modules is three shared index objects, defined in one module and imported by the other one. There is no configuration of M that affects a single particular object in N. > You haven't discussed whether your intention would be to publish two > mibs in the same document, or different documents. If you put two mibs > in the same document, then the issue of normative references between > documents goes away and we can ignore it. Well David, I did not discuss it on this list yet, but I did send a detailed message discussing exactly this issue to Wes and you without getting a reply. That's why I posted to this list. Here is a quote of it: --On 01.12.2003 11:00 Uhr +0100 Juergen Quittek wrote: JUERGEN> In general, we see the following three choices: JUERGEN> JUERGEN> 1. Have a single MIB module including all objects JUERGEN> Advantage: all in one JUERGEN> Disadvantage: The separation of both groups gets blurred. JUERGEN> JUERGEN> 2. Have two separate MIB modules, JUERGEN> JUERGEN> - a MIDCOM-PROTOCOL-MIB for all objects relevant to the JUERGEN> MIDCOM agent JUERGEN> JUERGEN> - a MIDCOM-SERVER-MIB for all additional objects that are JUERGEN> intended to be used mainly by network management applications. JUERGEN> JUERGEN> This separation is much clearer, because the logical split JUERGEN> between protocol plane and management plane is reflected. JUERGEN> JUERGEN> We can have these two modules on JUERGEN> JUERGEN> 2.a. a single document JUERGEN> 2.b. two separate documents JUERGEN> JUERGEN> 3. Drop MIDCOM server managed objects, because they are out JUERGEN> of scope. > If you define two mibs within the same document, you create the need to > import a lot of the objects from one into the other. As you can read from the draft Martin and I brought to your attention some time ago (draft-stiemerling-midcom-server-mib-00.txt), it is not a lot of objects but exactly three objects and all of them serve as common index. > Under those > conditions, I don't see a real benefit from doing this. There aren't > major downsides either, but it does increase the complexity > unnecessarily when you could simply use subtrees within the same mib. OK. I will collect the posted opinions and come up with a summary before making a decision. Let me summarize your position (and please correct me if I'm wrong!): David's recommendation: one MIB module. - Security is not a reason for having separate modules. - Two separated MIDCOM modules cannot be progressed independently because they depend too much on each other. - Three shared index objects increase complexity unnecessarily. Different subtrees should be used instead. Thanks, Juergen > dbh > >> -----Original Message----- >> From: Dave Shield [mailto:D.T.Shield@csc.liv.ac.uk] >> Sent: Thursday, December 11, 2003 6:55 AM >> To: Juergen Quittek >> Cc: Harrington, David; Tom Taylor; mibs@ops.ietf.org; midcom@ietf.org >> Subject: Re: [midcom] MIDCOM MIB design question >> >> >> >> > Coming back to the MIDCOM MIB problem. On one side, there >> is a set of >> > objects that concerns the entire protocol operations: >> statistics, the >> > list of entities that established policies using the MIDCOM >> protocol, >> > the number of failed attempts to establish a MIDCOM session, etc. >> > This should not be accessible to all potential entities >> that are allowed >> > to use the MIDCOM protocol. On the other side, there is the set of >> > objects implementing the MIDCOM protocol. This set should >> be accessible >> > to a wider group of users. >> > >> > Now, Tom said that this security issue could be handled >> more easily if >> > we would use separate modules. I do not see anything wrong >> with this. >> >> >> Pardon me for chipping in, but I'm not quite sure how the >> split between >> MIB modules makes any difference to the security aspects of things. >> Surely by the time access controls are applied, the MIB >> module(s) will have >> already been combined (even if only logically) into a single OID tree? >> >> I can see that having a suitable hierarchical structure for >> the management >> objects could well aid (or hinder) the configuration of >> appropriate access >> control settings. But what difference does it make whether >> these objects >> are defined in one module, or two? (Or even one module per object!) >> >> >> The question of how to divide objects between MIB modules feels to be >> more related to issues of convenience for implementation >> and/or revision >> management. >> >> So what am I missing? >> >> Dave >> >> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 12:21:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10905 for ; Thu, 11 Dec 2003 12:21:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUUo-0006rG-O2 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 12:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBHL2Eh026352 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 12:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUUn-0006qq-Uj; Thu, 11 Dec 2003 12:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUUB-0006q7-KQ for midcom@optimus.ietf.org; Thu, 11 Dec 2003 12:20:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10784 for ; Thu, 11 Dec 2003 12:20:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUUUA-0001Tj-00 for midcom@ietf.org; Thu, 11 Dec 2003 12:20:22 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AUUU9-0001SE-00 for midcom@ietf.org; Thu, 11 Dec 2003 12:20:21 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hBBHJk73094474 for ; Thu, 11 Dec 2003 18:19:50 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hBBHJixP094473 for ; Thu, 11 Dec 2003 18:19:44 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hBBHJi6x094470; Thu, 11 Dec 2003 18:19:44 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E09E2E9272; Thu, 11 Dec 2003 18:19:42 +0100 (CET) Date: Thu, 11 Dec 2003 18:21:47 +0100 From: Juergen Quittek To: Tom Petch Cc: mibs@ops.ietf.org, midcom@ietf.org Subject: Re: [midcom] MIDCOM MIB design question Message-ID: <2147483647.1071166907@[10.1.1.171]> In-Reply-To: <004701c3bfe7$03ecb160$0301a8c0@tom3> References: <004701c3bfe7$03ecb160$0301a8c0@tom3> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, Thanks a lot for your advice! --On 11.12.2003 12:38 Uhr +0000 Tom Petch wrote: > I agree with Dave that it is mostly the non-technical aspects, the > administration, that should colour your choice, the likely future > evolution, the need for revision, conformance, ownership by working > groups/IANA/ID editors and such like. A MIB module is a useful chunk of > definition to be administered as one item. > > Technically, once it is in an agent, then you just have the one tree of > objects and how many modules the tree came from is irrelevant. > > But I suggest you consider the tree structure carefully. Several aspects > of SNMP revolve around the tree structure and it is much easier to define > eg midcom.4 as available to all and midcom.5 as restricted to > administrators, as opposed to having to define eg midcom.4 as available to > all except for midcom.4.2, midcom.4.4.1 and the table entries of midcom.4.5 > with entries starting with x... except on weekends and Bank Holidays :-) > > ie group your objects in the tree structure so that whole branches have the > same pattern of access, use, security etc. This can be achieved - or not - > with one or 100 modules.. We tried to follow this rule and group our objects well (while also reducing the number of objects). After doing so we found a portion of objects in one subtree that was completely optional with respect to our main goal (implementing the MIDCOM protocol over SNMP) and that would be of relevance rather to one or the other network management application than to the users of the MIDCOM protocol. Also there were very few dependencies. Three index objects are shared. Therefore, we started thinking about separating this portion. But considering the response we got so far, this does not seem to be the right idea. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > Tom Petch > > nwnetworks@dial.pipex.com > > -----Original Message----- > From: Tom Taylor > To: Juergen Quittek > Cc: mibs@ops.ietf.org ; midcom@ietf.org > > Date: 11 December 2003 10:46 > Subject: Re: [midcom] MIDCOM MIB design question > > >> I'd say they should be in separate modules because they are likely to be >> implemented on separate boxes on the SNMP client side. >> >> Juergen Quittek wrote: >> >>> Dear all, >>> >>> In the MIDCOM working group we are developing a protocol for dynamically >>> requesting pinholes in firewalls and bindings/sessions on NATs. >>> >>> The working group decided to use SNMP as basic protocol and now we are >>> defining a MIDCOM MIB module. While doing this, we found that we are >>> defining two separate groups of objects: Objects implementing the > MIDCOM >>> protocol (for which we already have a protocol semantics document, see >>> draft-ietf-midcom-semantics-06.txt) and objects serving management >>> purposes. >>> Management purposes include for example configurations, such as >>> - the priority with which requested pinholes are configured in the >>> firewall, >>> - a table showing the mapping of MIDCOM pinholes to firewall resources >>> or of MIDCOM NAT sessions/bindings to NAT resources >>> - a protocol statistics table listing the set of active MIDCOM > sessions, >>> protocol errors, etc. >>> >>> For these two groups of objects there are also two separate groups of >>> users: >>> - middlebox controllers sending requests for dynamic pinholes and NAT >>> sessions/bindings >>> - network managers configuring the middlebox (firewall or NAT) and >>> monitoring its operation >>> >>> The middlebox controllers only need access to the objects implementing >>> the MIDCOM protocol. >>> >>> The network managers would rather use the objects serving management >>> purposes >>> although in some cases they might need to access the other group also. >>> >>> Now, we have a draft defining these objects and the following question: >>> >>> Does someone have an opinion about whether these two groups of objects >>> should be contained in a single MIB module or in two separate ones? >>> >>> Usually, this problem does not occur, because most control protocol, >>> say GSMP are not defined on top of SNMP. Therefore in GSMP there is >>> a clear separation between the protocol and the MIB with objects serving >>> network management purposes. But in our case, SNMP is used for both >>> purposes. >>> >>> Thanks, >>> >>> Juergen >> >> > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 11 14:23:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15732 for ; Thu, 11 Dec 2003 14:23:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWOx-0004Mv-11 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 14:23:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBJN6dw016770 for midcom-archive@odin.ietf.org; Thu, 11 Dec 2003 14:23:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWOr-0004Lz-BY; Thu, 11 Dec 2003 14:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWK5-00049T-0Y for midcom@optimus.ietf.org; Thu, 11 Dec 2003 14:18:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15392 for ; Thu, 11 Dec 2003 14:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUWK2-0004sp-00 for midcom@ietf.org; Thu, 11 Dec 2003 14:18:02 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1AUWK1-0004sl-00 for midcom@ietf.org; Thu, 11 Dec 2003 14:18:01 -0500 Received: from h-68-164-77-111.snvacaid.dynamic.covad.net ([68.164.77.111] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AUWJw-00007r-00; Thu, 11 Dec 2003 11:17:56 -0800 Message-ID: <004e01c3c01b$d79dd140$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: References: <004701c3bfe7$03ecb160$0301a8c0@tom3> <2147483647.1071166907@[10.1.1.171]> Subject: Re: [midcom] MIDCOM MIB design question Date: Thu, 11 Dec 2003 11:20:30 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi - > From: "Juergen Quittek" > To: "Tom Petch" > Cc: ; > Sent: Thursday, December 11, 2003 9:21 AM > Subject: Re: [midcom] MIDCOM MIB design question ... > After doing so we found a portion of objects in one subtree that was > completely optional with respect to our main goal (implementing the MIDCOM > protocol over SNMP) and that would be of relevance rather to one or the > other network management application than to the users of the MIDCOM > protocol. Also there were very few dependencies. Three index objects are > shared. ... I agree that this is sufficient reason to think seriously about splitting it into two modules. A deciding factor for me would be whether the implementation of the MIDCOM protocol is at all likely to be a separate software component. If it is, then separate modules, even if published in the same RFC, would be a distinct aid to developer sanity. Randy _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Dec 12 04:46:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02896 for ; Fri, 12 Dec 2003 04:46:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjs7-0002V9-Of for midcom-archive@odin.ietf.org; Fri, 12 Dec 2003 04:46:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC9k7Uu009609 for midcom-archive@odin.ietf.org; Fri, 12 Dec 2003 04:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjs2-0002UL-EK; Fri, 12 Dec 2003 04:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjrR-0002Ty-MX for midcom@optimus.ietf.org; Fri, 12 Dec 2003 04:45:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02870 for ; Fri, 12 Dec 2003 04:45:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUjrO-00015Y-00 for midcom@ietf.org; Fri, 12 Dec 2003 04:45:22 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUjrN-00014s-00 for midcom@ietf.org; Fri, 12 Dec 2003 04:45:21 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 8DE03820BE; Fri, 12 Dec 2003 10:44:51 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.46.146]) by merkur.iu-bremen.de (Postfix) with ESMTP id 507614409C; Fri, 12 Dec 2003 10:44:49 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id B889281C8; Fri, 12 Dec 2003 10:44:48 +0100 (CET) Date: Fri, 12 Dec 2003 10:44:48 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Cc: mibs@ops.ietf.org, midcom@ietf.org Subject: Re: [midcom] MIDCOM MIB design question Message-ID: <20031212094448.GB813@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Juergen Quittek , mibs@ops.ietf.org, midcom@ietf.org References: <2147483647.1071082429@[10.1.1.171]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147483647.1071082429@[10.1.1.171]> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Dec 10, 2003 at 06:53:49PM +0100, Juergen Quittek wrote: [...] > Usually, this problem does not occur, because most control protocol, > say GSMP are not defined on top of SNMP. Therefore in GSMP there is > a clear separation between the protocol and the MIB with objects serving > network management purposes. But in our case, SNMP is used for both > purposes. What puzzles me is the notion of the "MIDCOM protocol" in the context of SNMP. I have read the MIDCOM semantics document and I think I do have some understanding what the _services_ are that MIDCOM wants to define. But by using SNMP, you will probably realize these abstract services defined in the semantics documents via a bunch of MIB tables that can be tweaked to create holes and so on. So from this MIB perspective, I fail to see why there is a certain MIBCOM protocol - there are just MIDCOM MIB objects which allow you to achieve the services described in the MIDCOM semantics objects. Let me know if I am completely on the wrong track and I have to read the document (which one?). Regading the question how to split things into modules: 1) There are absolutely no implications concerning access control. 2) Different implementation requirements should be expressed by compliance statements. 3) MIB objects generally try to offer functionality without saying or prescribing how the functionality is used. Sometimes this causes problems because developers have a hard time to figure out how to use the objects to achieve a certain goal. On the other hand, trying to be neutral wrt. the expected usage allows for flexibility. So I think a good approach is to just define objects that offer a certain functionality in the MIB and to augment that with a textual description how the objects are typically used to solve certain problems. 4) I strongly recommend to keep things simple (you are done if there is nothing left which can be removed). However, some MIBs just require a certain complexity and trying to hide that by having multiple MIB modules does not help. 5) As we all know, there are some implications imposed by the IETF standardization process. Personally, I recommend to not worry too much about this while working on a Proposed Standard. If you later run into debates because someone want to advance while others want to add/change stuff, you are in the very fortunate situation that your document has been implemented and is being used. Perhaps this is an issue totally ignored in the IETF problem discussions: The IETF rewards success with pain. The more pain you feel, the more successful you likely are. ;-) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Dec 12 12:26:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17410 for ; Fri, 12 Dec 2003 12:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUr3D-0005fU-1R for midcom-archive@odin.ietf.org; Fri, 12 Dec 2003 12:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCHQ3Fx021782 for midcom-archive@odin.ietf.org; Fri, 12 Dec 2003 12:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUr3B-0005em-Lb; Fri, 12 Dec 2003 12:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUr2E-0005e1-Eo for midcom@optimus.ietf.org; Fri, 12 Dec 2003 12:25:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17390 for ; Fri, 12 Dec 2003 12:24:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUr2C-00027v-00 for midcom@ietf.org; Fri, 12 Dec 2003 12:25:01 -0500 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AUr2C-00027s-00 for midcom@ietf.org; Fri, 12 Dec 2003 12:25:00 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id MAA29614 for ; Fri, 12 Dec 2003 12:26:05 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma029603; Fri, 12 Dec 03 12:25:30 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 12 Dec 2003 12:24:24 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 12 Dec 2003 12:24:24 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Dec 2003 12:24:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] MIDCOM MIB design question Date: Fri, 12 Dec 2003 12:24:23 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA013B179F@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] MIDCOM MIB design question Thread-Index: AcPAlM5NJK0b4EUYS1Cj0DWs3GtWVwAPJOCg From: "Harrington, David" To: , "Juergen Quittek" Cc: , X-OriginalArrivalTime: 12 Dec 2003 17:24:23.0797 (UTC) FILETIME=[C9379A50:01C3C0D4] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:83.3688 M:99.5542 P:95.9108 R:95.9108 S:51.1865 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi JS, > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 >=20 > What puzzles me is the notion of the "MIDCOM protocol" in the context=20 > of SNMP. ... So from this MIB perspective, > I fail to see why there is a certain MIBCOM protocol - there are just > MIDCOM MIB objects which allow you to achieve the services=20 > described in > the MIDCOM semantics objects. Let me know if I am completely on the > wrong track and I have to read the document (which one?). >=20 Thank you for your comment. I don't think you're on the wrong track. I agree strongly with you on this and have been working to educate people on this viewpoint. Thank you for also pointing this out. The WG has selected SNMPv3 as the protocol (as the result of a comparison of five existing IETF protocols), but most of the WG are not very SNMP-savvy and have difficulty conceptualizing the solution in SNMP terms. Many people in the WG come from environments where they think in terms of control protocols, and continue to conceptualize the problem in terms of a "MIDCOM protocol" that happens to run over SNMP, rather than thinking that SNMPv3 **is** the protocol.=20 Sometimes this non-SNMPish view of the world makes it much harder to design the MIDCOM MIB. The current discussion is partly due to thinking of the solution in terms of a MIDCOM protocol distinct from SNMP. Oh well. dbh _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Dec 12 13:39:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19493 for ; Fri, 12 Dec 2003 13:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUsBq-0000n0-Tt for midcom-archive@odin.ietf.org; Fri, 12 Dec 2003 13:39:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCId2d3003011 for midcom-archive@odin.ietf.org; Fri, 12 Dec 2003 13:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUsBp-0000mA-8q; Fri, 12 Dec 2003 13:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUsBK-0000lj-VI for midcom@optimus.ietf.org; Fri, 12 Dec 2003 13:38:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19474 for ; Fri, 12 Dec 2003 13:38:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUsBI-0003j5-00 for midcom@ietf.org; Fri, 12 Dec 2003 13:38:28 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AUsBI-0003ic-00 for midcom@ietf.org; Fri, 12 Dec 2003 13:38:28 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBCIbtAt018388; Fri, 12 Dec 2003 10:37:56 -0800 (PST) Received: from cisco.com ([10.25.65.180]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id APB66968; Fri, 12 Dec 2003 10:37:53 -0800 (PST) Date: Fri, 12 Dec 2003 13:37:53 -0500 Subject: Re: [midcom] MIDCOM MIB design question Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: , "Juergen Quittek" , , To: "Harrington, David" From: Melinda Shore In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA013B179F@NHROCMBX1.ets.enterasys.com> Message-Id: <4C281556-2CD2-11D8-85DE-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday, December 12, 2003, at 12:24 PM, Harrington, David wrote: > Sometimes this non-SNMPish view of the world makes it much harder to > design the MIDCOM MIB. The current discussion is partly due to thinking > of the solution in terms of a MIDCOM protocol distinct from SNMP. Thanks to you both for emphasizing this, and especially for hanging in and helping us out. I think it's clearly the case that if we want this to function well we need to do it in a way that's idiomatic to SNMP. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Dec 15 16:57:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02384 for ; Mon, 15 Dec 2003 16:57:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0i8-0000vO-Or for midcom-archive@odin.ietf.org; Mon, 15 Dec 2003 16:57:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFLv4aW003535 for midcom-archive@odin.ietf.org; Mon, 15 Dec 2003 16:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0i5-0000ud-Az; Mon, 15 Dec 2003 16:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0hj-0000uG-E0 for midcom@optimus.ietf.org; Mon, 15 Dec 2003 16:56:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02369 for ; Mon, 15 Dec 2003 16:56:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW0hh-0002lj-00 for midcom@ietf.org; Mon, 15 Dec 2003 16:56:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW0hg-0002lc-00 for midcom@ietf.org; Mon, 15 Dec 2003 16:56:37 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AW0hg-0002lY-00 for midcom@ietf.org; Mon, 15 Dec 2003 16:56:36 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hBFLu3oe068516 for ; Mon, 15 Dec 2003 22:56:06 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hBFLtxmb068515 for ; Mon, 15 Dec 2003 22:55:59 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hBFLtwoa068512; Mon, 15 Dec 2003 22:55:59 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E0594EB650; Mon, 15 Dec 2003 22:55:51 +0100 (CET) Date: Mon, 15 Dec 2003 22:57:54 +0100 From: Juergen Quittek To: j.schoenwaelder@iu-bremen.de Cc: mibs@ops.ietf.org, midcom@ietf.org Subject: Re: [midcom] MIDCOM MIB design question Message-ID: <2147483647.1071529074@[10.1.1.26]> In-Reply-To: <20031212094448.GB813@iu-bremen.de> References: <2147483647.1071082429@[10.1.1.171]> <20031212094448.GB813@iu-bremen.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Juergen, Thank you very much for this guidance. I think it answers the open question and we know now how to structure the first version of the MIDCOM MIB. --On 12.12.2003 10:44 Uhr +0100 Juergen Schoenwaelder wrote: > On Wed, Dec 10, 2003 at 06:53:49PM +0100, Juergen Quittek wrote: > > [...] > >> Usually, this problem does not occur, because most control protocol, >> say GSMP are not defined on top of SNMP. Therefore in GSMP there is >> a clear separation between the protocol and the MIB with objects serving >> network management purposes. But in our case, SNMP is used for both >> purposes. > > What puzzles me is the notion of the "MIDCOM protocol" in the context > of SNMP. I have read the MIDCOM semantics document and I think I do have > some understanding what the _services_ are that MIDCOM wants to define. > But by using SNMP, you will probably realize these abstract services > defined in the semantics documents via a bunch of MIB tables that > can be tweaked to create holes and so on. So from this MIB perspective, > I fail to see why there is a certain MIBCOM protocol - there are just > MIDCOM MIB objects which allow you to achieve the services described in > the MIDCOM semantics objects. Let me know if I am completely on the > wrong track and I have to read the document (which one?). Basically, it is the midcom charter. The midcom WG is chartered to select an existing standard protocol and use it "as the basis for the development of a middlebox communication protocol." This term magically turned from 'odd' to 'puzzling' when it entered the SNMP community. I hope we do not have to change the charter after selecting SNMP ;-) Juergen Q. -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > Regading the question how to split things into modules: > > 1) There are absolutely no implications concerning access control. > > 2) Different implementation requirements should be expressed by > compliance statements. > > 3) MIB objects generally try to offer functionality without saying > or prescribing how the functionality is used. Sometimes this > causes problems because developers have a hard time to figure > out how to use the objects to achieve a certain goal. On the > other hand, trying to be neutral wrt. the expected usage > allows for flexibility. So I think a good approach is to just > define objects that offer a certain functionality in the MIB > and to augment that with a textual description how the objects > are typically used to solve certain problems. > > 4) I strongly recommend to keep things simple (you are done if there > is nothing left which can be removed). However, some MIBs just > require a certain complexity and trying to hide that by having > multiple MIB modules does not help. > > 5) As we all know, there are some implications imposed by the IETF > standardization process. Personally, I recommend to not worry too > much about this while working on a Proposed Standard. If you > later run into debates because someone want to advance while > others want to add/change stuff, you are in the very fortunate > situation that your document has been implemented and is being > used. > > > Perhaps this is an issue totally ignored in the IETF problem > discussions: The IETF rewards success with pain. The more > pain you feel, the more successful you likely are. ;-) > > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Dec 15 17:17:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03081 for ; Mon, 15 Dec 2003 17:17:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW11S-00028Y-TY for midcom-archive@odin.ietf.org; Mon, 15 Dec 2003 17:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFMH2sQ008196 for midcom-archive@odin.ietf.org; Mon, 15 Dec 2003 17:17:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW11R-000284-HY; Mon, 15 Dec 2003 17:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW11G-00026s-Op for midcom@optimus.ietf.org; Mon, 15 Dec 2003 17:16:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03053 for ; Mon, 15 Dec 2003 17:16:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW11E-0003Wk-00 for midcom@ietf.org; Mon, 15 Dec 2003 17:16:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW11C-0003Wc-00 for midcom@ietf.org; Mon, 15 Dec 2003 17:16:48 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AW11C-0003Tp-00 for midcom@ietf.org; Mon, 15 Dec 2003 17:16:46 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hBFMGDog068637 for ; Mon, 15 Dec 2003 23:16:16 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hBFMGCmp068636 for ; Mon, 15 Dec 2003 23:16:12 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hBFMGBoa068632; Mon, 15 Dec 2003 23:16:12 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B67BEEE33B; Mon, 15 Dec 2003 23:16:07 +0100 (CET) Date: Mon, 15 Dec 2003 23:18:11 +0100 From: Juergen Quittek To: "Harrington, David" , j.schoenwaelder@iu-bremen.de Cc: mibs@ops.ietf.org, midcom@ietf.org Subject: RE: [midcom] MIDCOM MIB design question Message-ID: <2147483647.1071530278@[10.1.1.26]> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA013B179F@NHROCMBX1.ets.enterasys.com> References: <6D745637A7E0F94DA070743C55CDA9BA013B179F@NHROCMBX1.ets.enterasys.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David, --On 12.12.2003 12:24 Uhr -0500 Harrington, David wrote: > Hi JS, > >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] >> >> What puzzles me is the notion of the "MIDCOM protocol" in the context >> of SNMP. ... So from this MIB perspective, >> I fail to see why there is a certain MIBCOM protocol - there are just >> MIDCOM MIB objects which allow you to achieve the services >> described in > the MIDCOM semantics objects. Let me know if I am > completely on the >> wrong track and I have to read the document (which one?). >> > Thank you for your comment. > > I don't think you're on the wrong track. I agree strongly with you on > this and have been working to educate people on this viewpoint. Thank > you for also pointing this out. > > The WG has selected SNMPv3 as the protocol (as the result of a > comparison of five existing IETF protocols), but most of the WG are not > very SNMP-savvy and have difficulty conceptualizing the solution in SNMP > terms. Thank you for the compliment. The point is that the SNMP community in turn is not very MIDCOM-savvy, so it is not that easy to produce a standard that satisfies both parties. > Many people in the WG come from environments where they think in > terms of control protocols, and continue to conceptualize the problem in > terms of a "MIDCOM protocol" that happens to run over SNMP, rather than > thinking that SNMPv3 **is** the protocol. Let's discuss this offline, maybe at the next IETF meeting. For now, we have an answer to our question and can prepare a first version of the MIDCOM MIB. > Sometimes this non-SNMPish view of the world makes it much harder to > design the MIDCOM MIB. The current discussion is partly due to thinking > of the solution in terms of a MIDCOM protocol distinct from SNMP. > > Oh well. Thank you for your patience. I am afraid we MIDCOM people will need more of it until the MIDCOM MIB is mature. I guess we are still welcome to ask ignorant questions ;-) Thanks, Juergen > dbh _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Dec 18 13:40:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07565 for ; Thu, 18 Dec 2003 13:40:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX34F-0000yE-As for midcom-archive@odin.ietf.org; Thu, 18 Dec 2003 13:40:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIIeAG3003724 for midcom-archive@odin.ietf.org; Thu, 18 Dec 2003 13:40:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX348-0000wk-DE; Thu, 18 Dec 2003 13:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX33T-0000vs-Lb for midcom@optimus.ietf.org; Thu, 18 Dec 2003 13:39:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07534 for ; Thu, 18 Dec 2003 13:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX33R-0000nn-00 for midcom@ietf.org; Thu, 18 Dec 2003 13:39:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX33P-0000nZ-00 for midcom@ietf.org; Thu, 18 Dec 2003 13:39:21 -0500 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AX33P-0000nW-00 for midcom@ietf.org; Thu, 18 Dec 2003 13:39:19 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA07007 for ; Thu, 18 Dec 2003 13:40:27 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma006982; Thu, 18 Dec 03 13:39:33 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 18 Dec 2003 13:38:23 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 18 Dec 2003 13:38:23 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Dec 2003 13:38:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] MIDCOM MIB design question Date: Thu, 18 Dec 2003 13:38:31 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA013B1916@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] MIDCOM MIB design question Thread-Index: AcPDWS/pUTEf8K//Q2K1qSx0yuST6ACPEbNg From: "Harrington, David" To: "Juergen Quittek" , Cc: , X-OriginalArrivalTime: 18 Dec 2003 18:38:33.0644 (UTC) FILETIME=[2402DEC0:01C3C596] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:80.8653 M:99.5542 P:95.9108 R:95.9108 S:57.0538 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi JQ, > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de]=20 > --On 12.12.2003 12:24 Uhr -0500 Harrington, David wrote: > > The WG has selected SNMPv3 as the protocol (as the result of a > > comparison of five existing IETF protocols), but most of=20 > the WG are not > > very SNMP-savvy and have difficulty conceptualizing the=20 > solution in SNMP > > terms. >=20 > Thank you for the compliment. >=20 > The point is that the SNMP community in turn is not very MIDCOM-savvy, > so it is not that easy to produce a standard that satisfies=20 > both parties. Agreed. Uh ... And thanks for the compliment ;-) And, let me thank you for driving hard to bridge the chasm between our worlds. >=20 > Thank you for your patience. I am afraid we MIDCOM people will need > more of it until the MIDCOM MIB is mature. I guess we are=20 > still welcome > to ask ignorant questions ;-) As long as I'm still welcome to ask ignorant questions about MIDCOM as well ;-) dbh _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom