From exim@www1.ietf.org Mon May 3 09:51:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29527 for ; Mon, 3 May 2004 09:51:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKdhw-0006On-A6 for midcom-archive@odin.ietf.org; Mon, 03 May 2004 09:42:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43Dg8d5024597 for midcom-archive@odin.ietf.org; Mon, 3 May 2004 09:42:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKd5J-0006ve-FC; Mon, 03 May 2004 09:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKcwQ-0001Yi-4t for midcom@optimus.ietf.org; Mon, 03 May 2004 08:53:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25867 for ; Mon, 3 May 2004 08:52:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKcwO-0006dw-P6 for midcom@ietf.org; Mon, 03 May 2004 08:53:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKcq6-0005if-00 for midcom@ietf.org; Mon, 03 May 2004 08:46:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKckH-0004mt-00 for midcom@ietf.org; Mon, 03 May 2004 08:40:29 -0400 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i43Cdgus023541; Mon, 3 May 2004 08:39:42 -0400 (EDT) Message-ID: <40963D64.7060306@dynamicsoft.com> Date: Mon, 03 May 2004 08:39:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Tran CC: midcom@ietf.org, "'Melinda Shore'" Subject: Re: RE : [midcom] More on new work item References: <000701c42ed4$2ec76360$b248d284@kamel> In-Reply-To: <000701c42ed4$2ec76360$b248d284@kamel> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i43Cdgus023541 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=AWL 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 inline. Joel Tran wrote: >>-----Message d'origine----- >>De : Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Envoy=E9 : 30 avril, 2004 11:42 >>=C0 : Joel Tran >>Cc : 'Melinda Shore'; midcom@ietf.org >>Objet : Re: RE : [midcom] More on new work item >> >=20 >>* if there is any other NAT intervening the user and the >>ISP's nat (very >>common here in the US at least, due to residential NAT devices like >>those made by linksys), this of course won't help even if you >>work out >>the ACL issues >=20 >=20 > Yes traversing the home NAT is a problem. Just a quick question, is the= re a > solution avaible for traversing both home and ISP NAT (excluding relayi= ng) > when two peers are under such topology? If yes, we could probably learn= form > them how they solve the situtation. Sure, STUN would allow this. >=20 >=20 >>* assuming no other nats between the user and the ISP NAT, there is a >>correlation that needs to be made somewhere between the >>username/password and the IP address thats allocated to them. >>This would >>require some really convoluted coupling between DHCP (which >>can tell you >>the MAC/IP binding) and customer provisioning systems (which >>*might* be >>able to tell you the MAC used by a customers cable modem) and the ISP >>firewall, to make sure that a user can only make changes for >>their own >>IP. This seems pretty complicated to me. >=20 >=20 > I don't think we require a big correlation (User/PWD/IP) in order to pr= ovide > a security mechanism. For example, the rules can be : >=20 > 1 - Pinholes can only be created for the source address. > 2 - User joe can only create 10 pinholes or IP source can only create= 10 > pinholes. > 3 - ... This rule is susceptible to source address spoofing attacks. It would=20 allow me to direct traffic at a target by faking my source IP to be that=20 of the target. If you further reduce the scope of this problem by making, say,=20 relatively short timeouts on the bindings that are created, and only=20 allow a single port to be allocated at a time, you come to an=20 interesting point - you could obtain exactly the same kind of allocation=20 from a midcom-unaware NAT by sending a STUN query through it. >=20 >>* Its also not clear to me that there aren't security holes >>in the whole >>thing that might enable someone to learn the passwords and usernames >>needed to control bindings for other IP addresses. >=20 >=20 > I'm not an SNMPv3 expert but I think that the security mechanism > (USM/encryption) provided by SNMPv3 is strong enough so that it will be= hard > for someone to break trough and discover the user name/password or try = to > get unrestricted access. I was concerned more about system level security, if you try and=20 correlate the username/pass with DHCP and MAC information. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon May 3 11:48:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09014 for ; Mon, 3 May 2004 11:48:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfZH-0001ZZ-T7 for midcom-archive@odin.ietf.org; Mon, 03 May 2004 11:41:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43FfJXW006040 for midcom-archive@odin.ietf.org; Mon, 3 May 2004 11:41:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfU9-0008RY-0j; Mon, 03 May 2004 11:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfOz-0007T8-7g for midcom@optimus.ietf.org; Mon, 03 May 2004 11:30:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08180 for ; Mon, 3 May 2004 11:30:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKfOy-00014D-6o for midcom@ietf.org; Mon, 03 May 2004 11:30:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKfO2-00010p-00 for midcom@ietf.org; Mon, 03 May 2004 11:29:43 -0400 Received: from smtpi1.usherbrooke.ca ([132.210.244.92]) by ietf-mx with esmtp (Exim 4.12) id 1BKfNU-0000xY-00 for midcom@ietf.org; Mon, 03 May 2004 11:29:08 -0400 Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by smtpi1.usherbrooke.ca (8.12.10/8.12.10) with ESMTP id i43FQITx009309; Mon, 3 May 2004 11:26:18 -0400 From: "Joel Tran" To: "'Jonathan Rosenberg'" Cc: , "'Melinda Shore'" Subject: RE : RE : [midcom] More on new work item Date: Mon, 3 May 2004 11:25:38 -0400 Message-ID: <000401c43122$e35cdee0$b248d284@kamel> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40963D64.7060306@dynamicsoft.com> Importance: Normal X-UdeS-i-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-i-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca 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=AWL autolearn=no version=2.60 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: , I think we are diverging from the basic scope of the discussion. The scope of the discussion is to find if DHCP or anoother means of configuration might be needed in some circumstances for Midcom. IMHO, It is not meant to be a deep analysis for all the pros and the cons of DHCP and how things can be done or not. At the beginning, you raised some good questions about the applicability of this technique. It was a good call. However, as discuss earlier, I think that there are some circumstances where this technique is applicable and where we might need the end-points to communicate directly with the Midcom middlebox. What we are now performing is an in deep analysis of how we can/can't implement this. IMHO, this is the next step of development and means that DHCP or another means for configuring end-points might be needed. I think now we are at a turn point in the discussion where we have do decide whatever we need or not DHCP or another mechanism for midcom. As for my opinion, I still think that midcom will benefit from DHCP or other means of configuration of end-points. Regards, ...J > -----Message d'origine----- > De : Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Envoyé : 3 mai, 2004 08:39 > À : Joel Tran > Cc : midcom@ietf.org; 'Melinda Shore' > Objet : Re: RE : [midcom] More on new work item > > > inline. > > Joel Tran wrote: > > >>-----Message d'origine----- > >>De : Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Envoyé : 30 > >>avril, 2004 11:42 À : Joel Tran > >>Cc : 'Melinda Shore'; midcom@ietf.org > >>Objet : Re: RE : [midcom] More on new work item > >> > > > >>* if there is any other NAT intervening the user and the ISP's nat > >>(very common here in the US at least, due to residential > NAT devices > >>like those made by linksys), this of course won't help even if you > >>work out > >>the ACL issues > > > > > > Yes traversing the home NAT is a problem. Just a quick question, is > > there a solution avaible for traversing both home and ISP NAT > > (excluding relaying) when two peers are under such > topology? If yes, > > we could probably learn form them how they solve the situtation. > > Sure, STUN would allow this. > > > > > > >>* assuming no other nats between the user and the ISP NAT, > there is a > >>correlation that needs to be made somewhere between the > >>username/password and the IP address thats allocated to them. This > >>would require some really convoluted coupling between DHCP (which > >>can tell you > >>the MAC/IP binding) and customer provisioning systems (which > >>*might* be > >>able to tell you the MAC used by a customers cable modem) > and the ISP > >>firewall, to make sure that a user can only make changes for > >>their own > >>IP. This seems pretty complicated to me. > > > > > > I don't think we require a big correlation (User/PWD/IP) in > order to > > provide a security mechanism. For example, the rules can be : > > > > 1 - Pinholes can only be created for the source address. > > 2 - User joe can only create 10 pinholes or IP source can only > > create 10 pinholes. > > 3 - ... > > This rule is susceptible to source address spoofing attacks. It would > allow me to direct traffic at a target by faking my source IP > to be that > of the target. > > If you further reduce the scope of this problem by making, say, > relatively short timeouts on the bindings that are created, and only > allow a single port to be allocated at a time, you come to an > interesting point - you could obtain exactly the same kind of > allocation > from a midcom-unaware NAT by sending a STUN query through it. > > > > > >>* Its also not clear to me that there aren't security holes in the > >>whole thing that might enable someone to learn the passwords and > >>usernames needed to control bindings for other IP addresses. > > > > > > I'm not an SNMPv3 expert but I think that the security mechanism > > (USM/encryption) provided by SNMPv3 is strong enough so > that it will > > be hard for someone to break trough and discover the user > > name/password or try to get unrestricted access. > > I was concerned more about system level security, if you try and > correlate the username/pass with DHCP and MAC information. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon May 3 12:25:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11120 for ; Mon, 3 May 2004 12:25:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgCY-0003yK-UG for midcom-archive@odin.ietf.org; Mon, 03 May 2004 12:21:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43GLswD015269 for midcom-archive@odin.ietf.org; Mon, 3 May 2004 12:21:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfyC-00079L-0M; Mon, 03 May 2004 12:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfpD-00058z-AX for midcom@optimus.ietf.org; Mon, 03 May 2004 11:57:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09548 for ; Mon, 3 May 2004 11:57:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKfpC-0002n8-18 for midcom@ietf.org; Mon, 03 May 2004 11:57:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKfoH-0002jW-00 for midcom@ietf.org; Mon, 03 May 2004 11:56:50 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKfnT-0002d7-00 for midcom@ietf.org; Mon, 03 May 2004 11:55:59 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 May 2004 08:09:35 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i43FtRW9019625; Mon, 3 May 2004 08:55:27 -0700 (PDT) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with SMTP id ATQ30411; Mon, 3 May 2004 08:55:25 -0700 (PDT) Date: Mon, 3 May 2004 11:55:22 -0400 Subject: Re: RE : RE : [midcom] More on new work item Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: "'Jonathan Rosenberg'" , To: "Joel Tran" From: Melinda Shore In-Reply-To: <000401c43122$e35cdee0$b248d284@kamel> Message-Id: <48FAA5A6-9D1A-11D8-9F75-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) 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=AWL 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 On Monday, May 3, 2004, at 11:25 AM, Joel Tran wrote: > What we are now performing is an in deep analysis of how we can/can't > implement this. IMHO, this is the next step of development and means > that > DHCP or another means for configuring end-points might be needed. These decisions are made by a triumvirate of the working group, the ADs, and the chair. I think that right now, given the circumstances of this working group, it's reasonable to expect a certain level of maturity in any ancillary work we agree to take on. My personal bias is that there's a role for the work in some future network that may or may not come into existence but that it's less clear that there's a role for it today. That's why I'm interested in seeing the issues that Jonathan raised be answered with something fairly specific. The conditions that have to exist for the working group to recharter to take on a new deliverable include but aren't limited to: 1) wg consensus, 2) AD agreement, 3) a recognized need for the work, 4) an understanding of what effort would be required, 5) resources to satisfy the effort, and 6) assurance that the completed work will receive expert review. I think we're somewhat deficient on 3 and 6. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon May 3 13:05:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14051 for ; Mon, 3 May 2004 13:05:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKght-0004DW-Uq for midcom-archive@odin.ietf.org; Mon, 03 May 2004 12:54:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43GsHHa016187 for midcom-archive@odin.ietf.org; Mon, 3 May 2004 12:54:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgZv-0001LU-HO; Mon, 03 May 2004 12:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgPA-00072m-0Q for midcom@optimus.ietf.org; Mon, 03 May 2004 12:34:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11652 for ; Mon, 3 May 2004 12:34:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKgP8-0005ii-Dp for midcom@ietf.org; Mon, 03 May 2004 12:34:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgOI-0005db-00 for midcom@ietf.org; Mon, 03 May 2004 12:34:03 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BKgNC-0005TX-00 for midcom@ietf.org; Mon, 03 May 2004 12:32:54 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 09:32:21 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 03 May 2004 09:32:23 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 09:31:33 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 09:32:33 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 3 May 2004 09:32:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: RE : RE : [midcom] More on new work item Date: Mon, 3 May 2004 09:32:14 -0700 Message-ID: Thread-Topic: RE : RE : [midcom] More on new work item Thread-Index: AcQxJPcdUfzKOeaHTLetzWz6JwjN1gABu97Q From: "Christian Huitema" To: "Joel Tran" , "Jonathan Rosenberg" Cc: , "Melinda Shore" X-OriginalArrivalTime: 03 May 2004 16:32:11.0084 (UTC) FILETIME=[2F0BC8C0:01C4312C] 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=AWL 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 > I think now we are at a turn point in the discussion where we have do > decide whatever we need or not DHCP or another mechanism for midcom. Based on the discussion so far, I believe the answer is: No. The domains of applicability of DHCP and Midcom have an almost empty intersection, and adding another standard to the mix is not going to help. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon May 3 15:33:28 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24307 for ; Mon, 3 May 2004 15:33:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiwI-0002a9-Fw for midcom-archive@odin.ietf.org; Mon, 03 May 2004 15:17:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43JHIgY009916 for midcom-archive@odin.ietf.org; Mon, 3 May 2004 15:17:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKilO-0007iX-G1; Mon, 03 May 2004 15:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKicX-0008BK-0z for midcom@optimus.ietf.org; Mon, 03 May 2004 14:56:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20397 for ; Mon, 3 May 2004 14:56:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKicU-0006Ci-6V for midcom@ietf.org; Mon, 03 May 2004 14:56:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKibd-000672-00 for midcom@ietf.org; Mon, 03 May 2004 14:55:58 -0400 Received: from smtpi1.usherbrooke.ca ([132.210.244.92]) by ietf-mx with esmtp (Exim 4.12) id 1BKiay-0005yr-00 for midcom@ietf.org; Mon, 03 May 2004 14:55:16 -0400 Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by smtpi1.usherbrooke.ca (8.12.10/8.12.10) with ESMTP id i43IsCex007057; Mon, 3 May 2004 14:54:12 -0400 From: "Joel Tran" To: "'Jonathan Rosenberg'" Cc: , "'Melinda Shore'" Subject: RE : RE : [midcom] More on new work item Date: Mon, 3 May 2004 14:53:29 -0400 Message-ID: <001a01c4313f$ec91df20$b248d284@kamel> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40963D64.7060306@dynamicsoft.com> Importance: Normal X-UdeS-i-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-i-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca 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=AWL autolearn=no version=2.60 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: , Response inline. > > > > > > >>* assuming no other nats between the user and the ISP NAT, > there is a > >>correlation that needs to be made somewhere between the > >>username/password and the IP address thats allocated to them. This > >>would require some really convoluted coupling between DHCP (which > >>can tell you > >>the MAC/IP binding) and customer provisioning systems (which > >>*might* be > >>able to tell you the MAC used by a customers cable modem) > and the ISP > >>firewall, to make sure that a user can only make changes for > >>their own > >>IP. This seems pretty complicated to me. > > > > > > I don't think we require a big correlation (User/PWD/IP) in > order to > > provide a security mechanism. For example, the rules can be : > > > > 1 - Pinholes can only be created for the source address. > > 2 - User joe can only create 10 pinholes or IP source can only > > create 10 pinholes. > > 3 - ... > > This rule is susceptible to source address spoofing attacks. It would > allow me to direct traffic at a target by faking my source IP > to be that > of the target. I think DHCP is used mainly by ISP in two cases. The first case concerns the assingment of pseudo-static IP address to client using a DHCP. This technique is mainly used in a shared medium context (cable user for instance). The second case concerns the assingment of dynamic IP address to client. This is mainly used with PPP link (PPOE ADSL network and dialup for instance). In the first case, it is easy to make a policy with the IP/MAC to an user since it is pseudo-static. An attacker would have to clone the MAC/IP and find the correct user/pwd to do a sproofing attacks. In the second case, since a PPP connection is used, it is easy to detect and filter sproofing with a proper rule. ...J _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue May 4 03:45:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14855 for ; Tue, 4 May 2004 03:45:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuad-0003wV-GC for midcom-archive@odin.ietf.org; Tue, 04 May 2004 03:43:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i447hhD2015156 for midcom-archive@odin.ietf.org; Tue, 4 May 2004 03:43:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuUC-0001uS-Ng; Tue, 04 May 2004 03:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKuSd-0001Y5-W2 for midcom@optimus.ietf.org; Tue, 04 May 2004 03:35:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14214 for ; Tue, 4 May 2004 03:35:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKuSb-0007ZL-Hp for midcom@ietf.org; Tue, 04 May 2004 03:35:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKuRj-0007LG-00 for midcom@ietf.org; Tue, 04 May 2004 03:34:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BKuR5-00079V-00 for midcom@ietf.org; Tue, 04 May 2004 03:33:51 -0400 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i447X9us024163; Tue, 4 May 2004 03:33:10 -0400 (EDT) Message-ID: <4096EB1B.4000105@dynamicsoft.com> Date: Mon, 03 May 2004 21:00:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Tran CC: midcom@ietf.org, "'Melinda Shore'" Subject: Re: RE : RE : [midcom] More on new work item References: <000401c43122$e35cdee0$b248d284@kamel> In-Reply-To: <000401c43122$e35cdee0$b248d284@kamel> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_06_12 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 Joel Tran wrote: > IMHO, It is not meant to be a deep analysis for all the pros and the cons of > DHCP and how things can be done or not. At the beginning, you raised some > good questions about the applicability of this technique. It was a good > call. However, as discuss earlier, I think that there are some circumstances > where this technique is applicable and where we might need the end-points to > communicate directly with the Midcom middlebox. Well, I'm trying to poke into that. I don't think it makes sense to take on this work item if it turns out that it only makes sense as part of a network that is designed with serious security issues or complexity problems. If that is so, there is no point in doing this DHCP work. >>>I don't think we require a big correlation (User/PWD/IP) in >> >>> order to >> >>>> > provide a security mechanism. For example, the rules can be : >>>> > >>>> > 1 - Pinholes can only be created for the source address. >>>> > 2 - User joe can only create 10 pinholes or IP source can only >>>> > create 10 pinholes. >>>> > 3 - ... >> >>> >>> This rule is susceptible to source address spoofing attacks. It would >>> allow me to direct traffic at a target by faking my source IP >>> to be that >>> of the target. > > > I think DHCP is used mainly by ISP in two cases. The first case concerns the > assingment of pseudo-static IP address to client using a DHCP. This > technique is mainly used in a shared medium context (cable user for > instance). The second case concerns the assingment of dynamic IP address to > client. This is mainly used with PPP link (PPOE ADSL network and dialup for > instance). > > In the first case, it is easy to make a policy with the IP/MAC to an user > since it is pseudo-static. An attacker would have to clone the MAC/IP and > find the correct user/pwd to do a sproofing attacks. This depends on how the username/password are distributed. In any case, pseurandom is the same as being totally random, since once its not static, you need a way to communicate the assignment from the DHCP server to the middlebox. Of course, there are probably several middleboxes, and so you need to distribute the usernames and passwords to those. Or, add a AAA system to avoid having the firewall actually know everyones username and passwords... Anyway, what I'm driving at here is that this gets to be a reall, really complex system. Complex systems are expensive, and they make security more problematic. I think something like STUN or one of the many documented relay techniques are going to be far simpler and also far more secure. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue May 4 17:20:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00210 for ; Tue, 4 May 2004 17:20:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL7HN-0000yT-Cq for midcom-archive@odin.ietf.org; Tue, 04 May 2004 17:16:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44LGfK0003745 for midcom-archive@odin.ietf.org; Tue, 4 May 2004 17:16:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL786-0006lJ-Fs; Tue, 04 May 2004 17:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL74F-0005jf-Jv for midcom@optimus.ietf.org; Tue, 04 May 2004 17:03:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29127 for ; Tue, 4 May 2004 17:03:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL74D-0007Uy-EN for midcom@ietf.org; Tue, 04 May 2004 17:03:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL73I-0007Nj-00 for midcom@ietf.org; Tue, 04 May 2004 17:02:08 -0400 Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BL72s-0007GO-00 for midcom@ietf.org; Tue, 04 May 2004 17:01:42 -0400 Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2.enterasys.com [134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i44L1eTm003804 for ; Tue, 4 May 2004 17:01:41 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 04 May 2004 17:01:41 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 04 May 2004 17:01:41 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 May 2004 17:01:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] Possible new work item Date: Tue, 4 May 2004 17:01:35 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA01977678@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] Possible new work item Thread-Index: AcQopCWIkMzoMjH3ScmhXL+uagyCUwJdmdrA From: "Harrington, David" To: "Melinda Shore" , Cc: X-OriginalArrivalTime: 04 May 2004 21:01:41.0813 (UTC) FILETIME=[FFF6F650:01C4321A] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:84.0661 M:98.8113 P:95.9108 R:95.9108 S:99.9000 ) 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=AWL 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 Melinda, I'd be more supportive if one or more persons had actually done an implementation and found it useful in practice (you know, rough consensus and running code). Otherwise this is purely speculation that it might be useable and useful to somebody sometime. That doesn't sound like a good justification to me. dbh > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On=20 > Behalf Of Melinda Shore > Sent: Thursday, April 22, 2004 3:04 PM > To: midcom@ietf.org > Cc: rdroms@cisco.com > Subject: [midcom] Possible new work item >=20 > As was discussed here several weeks ago, there's a proposal for midcom > to add new deliverables - DHCP and DHCPv6 options to=20 > configure middlebox > addresses into endpoints. If we were to undertake the work, we'd be > working with the dhc working group (expert review) and ideally we'd > be able to get a volunteer from that group to work with the editor of=20 > the > deliverable. I've appended some proposed charter text. The two > questions are: >=20 > 1) do we want to take on the work, and > 2) is the proposed charter paragraph okay? >=20 > Thanks, >=20 > Melinda >=20 >=20 > The working group will also produce documents describing DHCP and > DHCPv6 options for configuring middlebox addresses into endpoints. > These are not a replacement for a more sophisticated routing or > discovery mechanism, but may prove useful in simple network topologies > where network endpoints are making requests directly of middleboxes > rather than relying on third parties, such as call control servers, to > make middlebox requests on their behalf. >=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed May 5 11:41:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21629 for ; Wed, 5 May 2004 11:41:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOOB-000671-IU for midcom-archive@odin.ietf.org; Wed, 05 May 2004 11:32:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45FWpDx023472 for midcom-archive@odin.ietf.org; Wed, 5 May 2004 11:32:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOF2-0002ZS-TN; Wed, 05 May 2004 11:23:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLO3U-0006TO-Ou for midcom@optimus.ietf.org; Wed, 05 May 2004 11:11:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19801 for ; Wed, 5 May 2004 11:11:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLO3S-0003ge-4v for midcom@ietf.org; Wed, 05 May 2004 11:11:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLO21-0003GJ-00 for midcom@ietf.org; Wed, 05 May 2004 11:09:58 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BLNzn-0002SA-00 for midcom@ietf.org; Wed, 05 May 2004 11:07:40 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 05 May 2004 07:21:38 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i45F5XSu017506; Wed, 5 May 2004 08:07:05 -0700 (PDT) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with SMTP id ATS58247; Wed, 5 May 2004 08:05:31 -0700 (PDT) Date: Wed, 5 May 2004 11:05:28 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: rdroms@cisco.com To: midcom@ietf.org From: Melinda Shore Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] DHCP work item - no consensus 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 There is no consensus to undertake the development of a new option for DHCP to configure middlebox addresses into endpoints. The primary concern is the lack of a credible use case. Thanks for the discussion, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed May 12 11:21:03 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16242 for ; Wed, 12 May 2004 11:21:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvAf-0005Uo-Ur for midcom-archive@odin.ietf.org; Wed, 12 May 2004 10:57:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CEvLfb021126 for midcom-archive@odin.ietf.org; Wed, 12 May 2004 10:57:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNuFC-0002M8-NL; Wed, 12 May 2004 09:57:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtz1-0004XT-4o for midcom@optimus.ietf.org; Wed, 12 May 2004 09:41:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02595; Wed, 12 May 2004 09:41:12 -0400 (EDT) Message-Id: <200405121341.JAA02595@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 12 May 2004 09:41:12 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Definitions of Managed Objects for Middlebox Communication Author(s) : J. Quittek, et al. Filename : draft-ietf-midcom-mib-01.txt Pages : 82 Date : 2004-5-11 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 configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC XXXX. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-midcom-mib-01.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-ietf-midcom-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-12094156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-12094156.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed May 12 15:38:03 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06050 for ; Wed, 12 May 2004 15:38:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzPi-0008SD-3z for midcom-archive@odin.ietf.org; Wed, 12 May 2004 15:29:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CJTApt032498 for midcom-archive@odin.ietf.org; Wed, 12 May 2004 15:29:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzHx-0006XH-1Z; Wed, 12 May 2004 15:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNz7V-0000T6-DT for midcom@optimus.ietf.org; Wed, 12 May 2004 15:10:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01298 for ; Wed, 12 May 2004 14:23:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNyOL-0000P4-Rc for midcom@ietf.org; Wed, 12 May 2004 14:23:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNyNS-0007h6-00 for midcom@ietf.org; Wed, 12 May 2004 14:22:46 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BNyMK-0006ic-00 for midcom@ietf.org; Wed, 12 May 2004 14:21:36 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4CIL2Su011257 for ; Wed, 12 May 2004 11:21:03 -0700 (PDT) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with SMTP id AUA11443; Wed, 12 May 2004 11:21:01 -0700 (PDT) Date: Wed, 12 May 2004 14:20:57 -0400 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Fwd: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <1CE27438-A441-11D8-8468-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.553) 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=AWL 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 This is our final deliverable - the end is in sight. Please give the draft a careful read and post comments to the mailing list. WG review is, perhaps, the most important stage in moving documents towards publication, and this is the time to catch and fix any problems that may lurk in the draft. Thanks, Melinda Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Wed May 12, 2004 9:41:12 AM US/Eastern > To: i-d-announce@ietf.org > Cc: midcom@ietf.org > Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Middlebox Communication Working Group > of the IETF. > > Title : Definitions of Managed Objects for Middlebox > Communication > Author(s) : J. Quittek, et al. > Filename : draft-ietf-midcom-mib-01.txt > Pages : 82 > Date : 2004-5-11 > > 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 > configuring middleboxes, such as firewalls and network address > translators, in order to enable communication across these devices. > The definitions of managed objects in this documents follow closely > the MIDCOM semantics defined in RFC XXXX. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-ietf-midcom-mib-01.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-ietf-midcom-mib-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-5-12094156.I-D@ietf.org> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed May 12 22:30:20 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27516 for ; Wed, 12 May 2004 22:30:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO5wW-0005dw-QG for midcom-archive@odin.ietf.org; Wed, 12 May 2004 22:27:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D2RSxX021690 for midcom-archive@odin.ietf.org; Wed, 12 May 2004 22:27:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO5rF-0004tn-GH; Wed, 12 May 2004 22:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO5ox-00047T-MQ for midcom@optimus.ietf.org; Wed, 12 May 2004 22:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27048 for ; Wed, 12 May 2004 22:19:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO5ou-0001Eg-K2 for midcom@ietf.org; Wed, 12 May 2004 22:19:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO5o2-0000jb-00 for midcom@ietf.org; Wed, 12 May 2004 22:18:43 -0400 Received: from warspite.concentric.net ([207.155.248.9] helo=warspite.cnchost.com) by ietf-mx with esmtp (Exim 4.12) id 1BO5nP-0000EP-00 for midcom@ietf.org; Wed, 12 May 2004 22:18:03 -0400 Received: from MedhaviLT (pool-151-200-240-121.res.east.verizon.net [151.200.240.121]) by warspite.cnchost.com id WAA09404; Wed, 12 May 2004 22:18:01 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] Message-ID: <200405130218.WAA09404@warspite.cnchost.com> Reply-To: From: "Medhavi Bhatia" To: Subject: RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt Date: Wed, 12 May 2004 22:18:00 -0400 Organization: NexTone Communications MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQ4V5QGLFrW0fb+RiKuE6sYHFL3BQAOGBNg In-Reply-To: <1CE27438-A441-11D8-8468-000A95E35274@cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME 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 I have not completely gone through the mib yet, but going through the semantics documents and the requirements, I did not see anything which points to how the midcom agent can direct the middlebox to use symmetric ip/port (ie., the address from which the middle box sends traffic towards an endpoint A is the same as the address where traffic is being received from A). None of the signaling protocols (SIP etc) require this, but it would be interesting to see if there is any option provided for this. -Medhavi. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Melinda > Shore > Sent: Wednesday, May 12, 2004 2:21 PM > To: midcom@ietf.org > Subject: Fwd: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt > > This is our final deliverable - the end is in sight. Please give the > draft a careful read and post comments to the mailing list. WG review > is, > perhaps, the most important stage in moving documents towards > publication, > and this is the time to catch and fix any problems that may lurk in the > draft. > > Thanks, > > Melinda > > > Begin forwarded message: > > > From: Internet-Drafts@ietf.org > > Date: Wed May 12, 2004 9:41:12 AM US/Eastern > > To: i-d-announce@ietf.org > > Cc: midcom@ietf.org > > Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Middlebox Communication Working Group > > of the IETF. > > > > Title : Definitions of Managed Objects for Middlebox > > Communication > > Author(s) : J. Quittek, et al. > > Filename : draft-ietf-midcom-mib-01.txt > > Pages : 82 > > Date : 2004-5-11 > > > > 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 > > configuring middleboxes, such as firewalls and network address > > translators, in order to enable communication across these devices. > > The definitions of managed objects in this documents follow closely > > the MIDCOM semantics defined in RFC XXXX. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-01.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > 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-ietf-midcom-mib-01.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-ietf-midcom-mib-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > Content-Type: text/plain > > Content-ID: <2004-5-12094156.I-D@ietf.org> > > > _______________________________________________ > 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 Wed May 12 22:53:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28249 for ; Wed, 12 May 2004 22:53:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO6KJ-000384-PY for midcom-archive@odin.ietf.org; Wed, 12 May 2004 22:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D2q3rG012023 for midcom-archive@odin.ietf.org; Wed, 12 May 2004 22:52:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO6IL-0002Zs-Ji; Wed, 12 May 2004 22:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO6B5-0001Fb-31 for midcom@optimus.ietf.org; Wed, 12 May 2004 22:42:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27894 for ; Wed, 12 May 2004 22:42:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO6B1-00053O-QW for midcom@ietf.org; Wed, 12 May 2004 22:42:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO6A1-0004XZ-00 for midcom@ietf.org; Wed, 12 May 2004 22:41:26 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BO68u-0003ZC-00 for midcom@ietf.org; Wed, 12 May 2004 22:40:16 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i4D2glan023899; Wed, 12 May 2004 21:42:47 -0500 Reply-To: From: "Christopher A. Martin" To: "'Melinda Shore'" , Subject: RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt Date: Wed, 12 May 2004 21:39:16 -0500 Organization: SIP1 Information Services Message-ID: <02d401c43893$7cadcf10$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <1CE27438-A441-11D8-8468-000A95E35274@cisco.com> 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=AWL 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 Hi Melinda, everyone, Its been awhile. You know I notice that we now have the mib draft and was wondering, is it out of scope to look into a way to manage via SNMP via a middle-box using midcom to provide the mechanism for nat traversal for snmp? Just a thought...SNMP has always been the sore spot when it comes to managing devices behind a nat. Before snmp v3 I would never have asked rfor such functionality, but now... Any comments from anyone on this would be appreciated. _____ Christopher A. Martin P.O. Box 1264 Cedar Hill, Texas 75104 _____ DOMAINS.SIP1.COM Select your option below by clicking on the icon. RegisterForwardDomainAlert MonitoringWeb HostingSite BuilderEmailTraffic Blazer & Quick SizzleSSLInternet UtilitiesCopyright -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Melinda Shore Sent: Wednesday, May 12, 2004 1:21 PM To: midcom@ietf.org Subject: Fwd: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt This is our final deliverable - the end is in sight. Please give the draft a careful read and post comments to the mailing list. WG review is, perhaps, the most important stage in moving documents towards publication, and this is the time to catch and fix any problems that may lurk in the draft. Thanks, Melinda Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Wed May 12, 2004 9:41:12 AM US/Eastern > To: i-d-announce@ietf.org > Cc: midcom@ietf.org > Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Middlebox Communication Working Group > of the IETF. > > Title : Definitions of Managed Objects for Middlebox > Communication > Author(s) : J. Quittek, et al. > Filename : draft-ietf-midcom-mib-01.txt > Pages : 82 > Date : 2004-5-11 > > 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 > configuring middleboxes, such as firewalls and network address > translators, in order to enable communication across these devices. > The definitions of managed objects in this documents follow closely > the MIDCOM semantics defined in RFC XXXX. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-ietf-midcom-mib-01.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-ietf-midcom-mib-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-5-12094156.I-D@ietf.org> _______________________________________________ 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 May 13 17:16:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15334 for ; Thu, 13 May 2004 17:16:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOMsq-00074M-ID for midcom-archive@odin.ietf.org; Thu, 13 May 2004 16:32:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DKWmO2027175 for midcom-archive@odin.ietf.org; Thu, 13 May 2004 16:32:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOMkU-0004jM-8A; Thu, 13 May 2004 16:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOLip-0006uO-DV for midcom@optimus.ietf.org; Thu, 13 May 2004 15:18:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07468 for ; Thu, 13 May 2004 15:18:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOLin-00027T-W6 for midcom@ietf.org; Thu, 13 May 2004 15:18:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOLht-0001ai-00 for midcom@ietf.org; Thu, 13 May 2004 15:17:26 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BOLhH-00013o-00 for midcom@ietf.org; Thu, 13 May 2004 15:16:47 -0400 Received: from [10.1.1.109] (p50840594.dip0.t-ipconnect.de [80.132.5.148]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 8CB6EF674; Thu, 13 May 2004 21:21:51 +0200 (CEST) Date: Thu, 13 May 2004 21:16:31 +0200 From: Martin Stiemerling To: mbhatia@nextone.com, midcom@ietf.org Subject: RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt Message-ID: <2147483647.1084482991@[10.0.1.2]> In-Reply-To: <200405130218.WAA09404@warspite.cnchost.com> References: <200405130218.WAA09404@warspite.cnchost.com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 Hi, There is now parameter/option to tell the middlebox how it should allocated IP addresses/port numbers. This is up to the actual implementation of the box and/or the MIDCOM stack. Martin --On Mittwoch, 12. Mai 2004 22:18 Uhr -0400 Medhavi Bhatia wrote: | 7bit | MIME-Version: 1.0 | Content-Type: text/plain; charset="us-ascii" | Content-Transfer-Encoding: 7bit | 7bit | | I have not completely gone through the mib yet, but going through the | semantics documents and the requirements, I did not see anything which | points to how the midcom agent can direct the middlebox to use symmetric | ip/port (ie., the address from which the middle box sends traffic towards | an endpoint A is the same as the address where traffic is being received | from A). None of the signaling protocols (SIP etc) require this, but it | would be interesting to see if there is any option provided for this. | | -Medhavi. | |> -----Original Message----- |> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of | Melinda |> Shore |> Sent: Wednesday, May 12, 2004 2:21 PM |> To: midcom@ietf.org |> Subject: Fwd: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt |> |> This is our final deliverable - the end is in sight. Please give the |> draft a careful read and post comments to the mailing list. WG review |> is, |> perhaps, the most important stage in moving documents towards |> publication, |> and this is the time to catch and fix any problems that may lurk in the |> draft. |> |> Thanks, |> |> Melinda |> |> |> Begin forwarded message: |> |> > From: Internet-Drafts@ietf.org |> > Date: Wed May 12, 2004 9:41:12 AM US/Eastern |> > To: i-d-announce@ietf.org |> > Cc: midcom@ietf.org |> > Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt |> > |> > A New Internet-Draft is available from the on-line Internet-Drafts |> > directories. |> > This draft is a work item of the Middlebox Communication Working Group |> > of the IETF. |> > |> > Title : Definitions of Managed Objects for Middlebox |> > Communication |> > Author(s) : J. Quittek, et al. |> > Filename : draft-ietf-midcom-mib-01.txt |> > Pages : 82 |> > Date : 2004-5-11 |> > |> > 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 |> > configuring middleboxes, such as firewalls and network address |> > translators, in order to enable communication across these devices. |> > The definitions of managed objects in this documents follow closely |> > the MIDCOM semantics defined in RFC XXXX. |> > |> > A URL for this Internet-Draft is: |> > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-01.txt |> > |> > To remove yourself from the I-D Announcement list, send a message to |> > i-d-announce-request@ietf.org with the word unsubscribe in the body of |> > the message. |> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce |> > to change your subscription settings. |> > |> > |> > 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-ietf-midcom-mib-01.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-ietf-midcom-mib-01.txt". |> > |> > NOTE: The mail server at ietf.org can return the document in |> > MIME-encoded form by using the "mpack" utility. To use this |> > feature, insert the command "ENCODING mime" before the "FILE" |> > command. To decode the response(s), you will need "munpack" or |> > a MIME-compliant mail reader. Different MIME-compliant mail readers |> > exhibit different behavior, especially when dealing with |> > "multipart" MIME messages (i.e. documents which have been split |> > up into multiple messages), so check your local documentation on |> > how to manipulate these messages. |> > |> > |> > Below is the data which will enable a MIME compliant mail reader |> > implementation to automatically retrieve the ASCII version of the |> > Internet-Draft. |> > Content-Type: text/plain |> > Content-ID: <2004-5-12094156.I-D@ietf.org> |> |> |> _______________________________________________ |> 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri May 14 12:32:08 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02138 for ; Fri, 14 May 2004 12:32:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOfXN-0003bV-SN for midcom-archive@odin.ietf.org; Fri, 14 May 2004 12:27:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EGRr9E013854 for midcom-archive@odin.ietf.org; Fri, 14 May 2004 12:27:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOfRg-0000AL-HA; Fri, 14 May 2004 12:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOf8Y-00078y-Nl for midcom@optimus.ietf.org; Fri, 14 May 2004 12:02:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29274 for ; Fri, 14 May 2004 12:02:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOf8X-0004A1-BT for midcom@ietf.org; Fri, 14 May 2004 12:02:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOf7U-0003gd-00 for midcom@ietf.org; Fri, 14 May 2004 12:01:09 -0400 Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BOf76-0003DY-00 for midcom@ietf.org; Fri, 14 May 2004 12:00:47 -0400 Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2.enterasys.com [134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i4EG0hTm004803 for ; Fri, 14 May 2004 12:00:43 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 14 May 2004 12:00:43 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 14 May 2004 12:00:43 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 May 2004 12:00:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] I-D ACTION:draft-ietf-midcom-mib-01.txt Date: Fri, 14 May 2004 12:00:36 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA01AC34D9@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt Thread-Index: AcQ4lTqQnF1W6JzSQUK3ugkwpfXgpABM1efw From: "Harrington, David" To: , "Melinda Shore" , X-OriginalArrivalTime: 14 May 2004 16:00:43.0298 (UTC) FILETIME=[9C61C020:01C439CC] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:96.5164 P:95.5390 R:95.9108 S:51.8425 ) X-pstn-settings: 4 (0.2500:0.2500) 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=AWL 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, SNMPv3 was designed to handle circumstances like devices behind a NAT.=20 The engineID concept separates the engine identity from its address. Multiple engines can exist at the same address (the view from the public side of a NAT) and each will have a different engineID.=20 (The engineID also helps in the router situation where multiple unique interfaces share an SNMP agent; if the data sets originate from the same engineID, they can be recognized as being the same SNMP engine, even though their addresses are different). An SNMPv3 message contains two engineIDs - one to identify the "next-hop" snmp engine, and one to identify the originator of the data contained in the PDU. The proxy capability allows a proxy-capable engine to forward SNMP packets to different pre-configured contextEngineIDs and their associated addresses.=20 The one place where SNMPv3 cannot easily solve the NAT problem is in the traditional approach to engine discovery. A discovery performed from the public side of a NAT won't work because the messages cannot be uniquely addressed to the managed entities within the NAT without scoping it through the public NAT address. A middlebox solution might be a viable approach.=20 Recognize that configuring SNMPv3 proxies has a key distribution issue to be aware of. The public-to-NAT messaging requires shared SNMPv3 keys, and the NAT-to-private messaging will require SNMPv3 keys. A middlebox solution probably should not try to distribute shared keys that don't already exist in the NAT box, but should enable/disable SNMPv3 proxy forwarding as needed, given pre-shared security principals (users) and keys. The design of the SNMPv3 proxy application (RFC3417) supports this separation of the security credentials (the TargetParams table) and the addresses (TargetAddrTable), so a middlebox might be able to configure where SNMP packets should be forwarded without being allowed to know the security credentials necessary to do the forwarding. David Harrington =20 dbh@enterasys.com co-chair, IETF SNMPv3 WG, concluded > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On=20 > Behalf Of Christopher A. Martin > Sent: Wednesday, May 12, 2004 10:39 PM > To: 'Melinda Shore'; midcom@ietf.org > Subject: RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt >=20 > Hi Melinda, everyone, > Its been awhile. You know I notice that we now have the mib draft and > was wondering, is it out of scope to look into a way to=20 > manage via SNMP > via a middle-box using midcom to provide the mechanism for=20 > nat traversal > for snmp? >=20 > Just a thought...SNMP has always been the sore spot when it comes to > managing devices behind a nat. Before snmp v3 I would never have asked > rfor such functionality, but now... >=20 > Any comments from anyone on this would be appreciated. >=20 > _____ =20 >=20 > Christopher A. Martin > P.O. Box 1264 > Cedar Hill, Texas 75104 > _____ =20 >=20 >=20 > DOMAINS.SIP1.COM =09 > Select your option below by clicking on the icon. > RegisterForwardDomainAlert MonitoringWeb HostingSite=20 > BuilderEmailTraffic > Blazer & Quick SizzleSSLInternet UtilitiesCopyright =09 >=20 >=20 >=20 > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On=20 > Behalf Of > Melinda Shore > Sent: Wednesday, May 12, 2004 1:21 PM > To: midcom@ietf.org > Subject: Fwd: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt >=20 >=20 > This is our final deliverable - the end is in sight. Please give the > draft a careful read and post comments to the mailing list. =20 > WG review=20 > is, > perhaps, the most important stage in moving documents towards=20 > publication, > and this is the time to catch and fix any problems that may=20 > lurk in the > draft. >=20 > Thanks, >=20 > Melinda >=20 >=20 > Begin forwarded message: >=20 > > From: Internet-Drafts@ietf.org > > Date: Wed May 12, 2004 9:41:12 AM US/Eastern > > To: i-d-announce@ietf.org > > Cc: midcom@ietf.org > > Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Middlebox Communication=20 > Working Group >=20 > > of the IETF. > > > > Title : Definitions of Managed Objects for Middlebox > > Communication > > Author(s) : J. Quittek, et al. > > Filename : draft-ietf-midcom-mib-01.txt > > Pages : 82 > > Date : 2004-5-11 > > =09 > > 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 > > configuring middleboxes, such as firewalls and network address > > translators, in order to enable communication across=20 > these devices. > > The definitions of managed objects in this documents=20 > follow closely > > the MIDCOM semantics defined in RFC XXXX. > > > > A URL for this Internet-Draft is:=20 > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-01.txt > > > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of >=20 > > the message. You can also visit=20 > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > 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-ietf-midcom-mib-01.txt". > > > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > 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-ietf-midcom-mib-01.txt". > > =09 > > 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. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > Content-Type: text/plain > > Content-ID: <2004-5-12094156.I-D@ietf.org> >=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri May 14 17:12:03 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27432 for ; Fri, 14 May 2004 17:12:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjsI-00031z-4n for midcom-archive@odin.ietf.org; Fri, 14 May 2004 17:05:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EL5kSq011646 for midcom-archive@odin.ietf.org; Fri, 14 May 2004 17:05:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjeU-00072C-A4; Fri, 14 May 2004 16:51:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjOn-0006ef-KW for midcom@optimus.ietf.org; Fri, 14 May 2004 16:35:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23237 for ; Fri, 14 May 2004 16:35:14 -0400 (EDT) Resent-From: j.schoenwaelder@iu-bremen.de Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOjOl-00047c-Jt for midcom@ietf.org; Fri, 14 May 2004 16:35:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOjL0-0002jU-00 for midcom@ietf.org; Fri, 14 May 2004 16:31:23 -0400 Received: from g4023.g.pppool.de ([80.185.64.35] helo=james.eecs.iu-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1BOjHO-00019E-00 for midcom@ietf.org; Fri, 14 May 2004 16:27:39 -0400 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 273178841; Fri, 14 May 2004 22:27:36 +0200 (CEST) Resent-Date: Fri, 14 May 2004 22:27:36 +0200 Resent-Message-ID: <20040514202736.GA1945@iu-bremen.de> Resent-To: midcom@ietf.org X-Original-To: j.schoenwaelder@iu-bremen.de Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by merkur.iu-bremen.de (Postfix) with ESMTP id 0A56089621 for ; Fri, 14 May 2004 22:25:03 +0200 (CEST) Received: from merkur.iu-bremen.de ([212.201.44.27]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29774-06 for ; Fri, 14 May 2004 22:25:02 +0200 (CEST) Received: from james.eecs.iu-bremen.de (G4023.g.pppool.de [80.185.64.35]) by merkur.iu-bremen.de (Postfix) with ESMTP id A0C4183210 for ; Fri, 14 May 2004 22:24:58 +0200 (CEST) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 4BF508841; Fri, 14 May 2004 22:24:58 +0200 (CEST) Date: Fri, 14 May 2004 22:24:58 +0200 From: Juergen Schoenwaelder To: "Christopher A. Martin" Cc: "'Melinda Shore'" , midcom@ietf.org Subject: Re: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt Message-ID: <20040514202458.GA1793@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Christopher A. Martin" , 'Melinda Shore' , midcom@ietf.org References: <1CE27438-A441-11D8-8468-000A95E35274@cisco.com> <02d401c43893$7cadcf10$6402a8c0@HOME2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02d401c43893$7cadcf10$6402a8c0@HOME2> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Resent-Date: Fri, 14 May 2004 16:27:39 -0400 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=AWL autolearn=no version=2.60 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, May 12, 2004 at 09:39:16PM -0500, Christopher A. Martin wrote: > Just a thought...SNMP has always been the sore spot when it comes to > managing devices behind a nat. Before snmp v3 I would never have asked > rfor such functionality, but now... See RFC 2962 for a discussion why the proper way to handle NATs is the usage of SNMPv3 proxies. Note: I am not saying it is easy - just that it is possible. ;-) /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 May 14 17:21:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28618 for ; Fri, 14 May 2004 17:21:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjzs-00069y-5u for midcom-archive@odin.ietf.org; Fri, 14 May 2004 17:13:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ELDaA3023679 for midcom-archive@odin.ietf.org; Fri, 14 May 2004 17:13:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjse-0003GE-I1; Fri, 14 May 2004 17:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjeN-0006v9-E6 for midcom@optimus.ietf.org; Fri, 14 May 2004 16:51:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25310 for ; Fri, 14 May 2004 16:51:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOjeL-0002AT-Br for midcom@ietf.org; Fri, 14 May 2004 16:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOjbp-0001Gh-00 for midcom@ietf.org; Fri, 14 May 2004 16:48:49 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BOjY6-0007WR-00 for midcom@ietf.org; Fri, 14 May 2004 16:44:54 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i4EKkN7f004681; Fri, 14 May 2004 15:46:23 -0500 Reply-To: From: "Christopher A. Martin" To: "'Harrington, David'" , "'Melinda Shore'" , Subject: RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt Date: Fri, 14 May 2004 15:44:24 -0500 Organization: SIP1 Information Services Message-ID: <008f01c439f4$40469ef0$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA01AC34D9@NHROCMBX1.ets.enterasys.com> 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=AWL 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 Thanks, this is exactly what I was looking for. _____ Christopher A. Martin P.O. Box 1264 Cedar Hill, Texas 75104 _____ DOMAINS.SIP1.COM RegisterForwardDomainAlert MonitoringWeb HostingSite BuilderEmailTraffic Blazer & Quick SizzleSSLInternet UtilitiesCopyright -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Harrington, David Sent: Friday, May 14, 2004 11:01 AM To: Chris@sip1.com; Melinda Shore; midcom@ietf.org Subject: RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt Hi, SNMPv3 was designed to handle circumstances like devices behind a NAT. The engineID concept separates the engine identity from its address. Multiple engines can exist at the same address (the view from the public side of a NAT) and each will have a different engineID. (The engineID also helps in the router situation where multiple unique interfaces share an SNMP agent; if the data sets originate from the same engineID, they can be recognized as being the same SNMP engine, even though their addresses are different). An SNMPv3 message contains two engineIDs - one to identify the "next-hop" snmp engine, and one to identify the originator of the data contained in the PDU. The proxy capability allows a proxy-capable engine to forward SNMP packets to different pre-configured contextEngineIDs and their associated addresses. The one place where SNMPv3 cannot easily solve the NAT problem is in the traditional approach to engine discovery. A discovery performed from the public side of a NAT won't work because the messages cannot be uniquely addressed to the managed entities within the NAT without scoping it through the public NAT address. A middlebox solution might be a viable approach. Recognize that configuring SNMPv3 proxies has a key distribution issue to be aware of. The public-to-NAT messaging requires shared SNMPv3 keys, and the NAT-to-private messaging will require SNMPv3 keys. A middlebox solution probably should not try to distribute shared keys that don't already exist in the NAT box, but should enable/disable SNMPv3 proxy forwarding as needed, given pre-shared security principals (users) and keys. The design of the SNMPv3 proxy application (RFC3417) supports this separation of the security credentials (the TargetParams table) and the addresses (TargetAddrTable), so a middlebox might be able to configure where SNMP packets should be forwarded without being allowed to know the security credentials necessary to do the forwarding. David Harrington dbh@enterasys.com co-chair, IETF SNMPv3 WG, concluded > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On > Behalf Of Christopher A. Martin > Sent: Wednesday, May 12, 2004 10:39 PM > To: 'Melinda Shore'; midcom@ietf.org > Subject: RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt > > Hi Melinda, everyone, > Its been awhile. You know I notice that we now have the mib draft and > was wondering, is it out of scope to look into a way to > manage via SNMP > via a middle-box using midcom to provide the mechanism for > nat traversal > for snmp? > > Just a thought...SNMP has always been the sore spot when it comes to > managing devices behind a nat. Before snmp v3 I would never have asked > rfor such functionality, but now... > > Any comments from anyone on this would be appreciated. > > _____ > > Christopher A. Martin > P.O. Box 1264 > Cedar Hill, Texas 75104 > _____ > > > DOMAINS.SIP1.COM > Select your option below by clicking on the icon. > RegisterForwardDomainAlert MonitoringWeb HostingSite > BuilderEmailTraffic > Blazer & Quick SizzleSSLInternet UtilitiesCopyright > > > > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On > Behalf Of > Melinda Shore > Sent: Wednesday, May 12, 2004 1:21 PM > To: midcom@ietf.org > Subject: Fwd: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt > > > This is our final deliverable - the end is in sight. Please give the > draft a careful read and post comments to the mailing list. > WG review > is, > perhaps, the most important stage in moving documents towards > publication, > and this is the time to catch and fix any problems that may > lurk in the > draft. > > Thanks, > > Melinda > > > Begin forwarded message: > > > From: Internet-Drafts@ietf.org > > Date: Wed May 12, 2004 9:41:12 AM US/Eastern > > To: i-d-announce@ietf.org > > Cc: midcom@ietf.org > > Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Middlebox Communication > Working Group > > > of the IETF. > > > > Title : Definitions of Managed Objects for Middlebox > > Communication > > Author(s) : J. Quittek, et al. > > Filename : draft-ietf-midcom-mib-01.txt > > Pages : 82 > > Date : 2004-5-11 > > > > 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 > > configuring middleboxes, such as firewalls and network address > > translators, in order to enable communication across > these devices. > > The definitions of managed objects in this documents > follow closely > > the MIDCOM semantics defined in RFC XXXX. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-01.txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > > > the message. You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > 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-ietf-midcom-mib-01.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-ietf-midcom-mib-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > Content-Type: text/plain > > Content-ID: <2004-5-12094156.I-D@ietf.org> > > > _______________________________________________ > 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 > > _______________________________________________ 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 Fri May 14 17:59:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01089 for ; Fri, 14 May 2004 17:59:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkg0-0001jH-Fa for midcom-archive@odin.ietf.org; Fri, 14 May 2004 17:57:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ELv8Vs006624 for midcom-archive@odin.ietf.org; Fri, 14 May 2004 17:57:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkZB-0000Rj-AQ; Fri, 14 May 2004 17:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkSU-0007VA-Va for midcom@optimus.ietf.org; Fri, 14 May 2004 17:43:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29989 for ; Fri, 14 May 2004 17:43:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOkSS-0002xf-F4 for midcom@ietf.org; Fri, 14 May 2004 17:43:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOkRA-0002I6-00 for midcom@ietf.org; Fri, 14 May 2004 17:41:48 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BOkPl-0000uz-00 for midcom@ietf.org; Fri, 14 May 2004 17:40:21 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i4ELfi7f004829; Fri, 14 May 2004 16:41:44 -0500 Reply-To: From: "Christopher A. Martin" To: Cc: "'Melinda Shore'" , Subject: RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt Date: Fri, 14 May 2004 16:39:44 -0500 Organization: SIP1 Information Services Message-ID: <00ba01c439fb$f979f370$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20040514202458.GA1793@iu-bremen.de> 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=AWL 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 I agree, just haven't seen many implementations of SNMP proxies. Is anyone aware of any generally available SNMPv3 proxies? _____ Christopher A. Martin P.O. Box 1264 Cedar Hill, Texas 75104 _____ DOMAINS.SIP1.COM Select your option below by clicking on the icon. RegisterForwardDomainAlert MonitoringWeb HostingSite BuilderEmailTraffic Blazer & Quick SizzleSSLInternet UtilitiesCopyright -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Friday, May 14, 2004 3:25 PM To: Christopher A. Martin Cc: 'Melinda Shore'; midcom@ietf.org Subject: Re: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt On Wed, May 12, 2004 at 09:39:16PM -0500, Christopher A. Martin wrote: > Just a thought...SNMP has always been the sore spot when it comes to > managing devices behind a nat. Before snmp v3 I would never have asked > rfor such functionality, but now... See RFC 2962 for a discussion why the proper way to handle NATs is the usage of SNMPv3 proxies. Note: I am not saying it is easy - just that it is possible. ;-) /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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon May 17 17:54:21 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05257 for ; Mon, 17 May 2004 17:54:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpnj-0005uf-4m for midcom-archive@odin.ietf.org; Mon, 17 May 2004 17:37:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HLbZKF022730 for midcom-archive@odin.ietf.org; Mon, 17 May 2004 17:37:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpT9-000321-Gj; Mon, 17 May 2004 17:16:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoVp-0000Wc-QS for midcom@optimus.ietf.org; Mon, 17 May 2004 16:15:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21916 for ; Mon, 17 May 2004 16:14:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPoVo-0001z0-3K for midcom@ietf.org; Mon, 17 May 2004 16:15:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPoU2-0001CA-00 for midcom@ietf.org; Mon, 17 May 2004 16:13:11 -0400 Received: from smtpi1.usherbrooke.ca ([132.210.244.92]) by ietf-mx with esmtp (Exim 4.12) id 1BPoSr-0000dw-00 for midcom@ietf.org; Mon, 17 May 2004 16:11:57 -0400 Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by smtpi1.usherbrooke.ca (8.12.10/8.12.10) with ESMTP id i4HKBNuU010541; Mon, 17 May 2004 16:11:23 -0400 From: "Joel Tran" To: , , , Date: Mon, 17 May 2004 16:10:49 -0400 Message-ID: <004c01c43c4b$0c04c730$b248d284@kamel> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca 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=AWL autolearn=no version=2.60 Subject: [midcom] Comments on draft-ietf-midcom-mib-01.txt 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: , Here are my few comments on the midcom mib draft. I have also few questions on the draft. 1 - Is there any correlation between the midcomGroupTable and the midcomRuleGroup? 2 - The draft does not address HOW and WHO is creating the midomRuleGroup. ...J Page 14 ------- 1 - Title : 5.1.1. MidcomSession Should be : MidcomSessionTable 2 - o midcomSessionOwner This string indicated the user that created and owns the session. It is the firswt index element of this table. All policy rules (and policy rule groups) have the same owner as the first not firswt. Page 15 ------- o midcomSessionRuleGroupIndex The group for which a free index in the policyRuleTable is obtained by reading object midcomSessionRuleNewIndex. This object must be set properly before reading a free index from midcomSessionRuleIndexNext. 3 - It is in the midcomRuleTable not policyRuleTable that we are searching a free index. 4 - I don't understand the part "is obtained by reading object midcomSessionRuleNewIndex". In my understanding, the phrase should be something like: "The group for which a free index midcomSessionRuleNewIndex is associated." 5 - At the end, it should by midcomSessionRuleNewIndex to be consistent in the document and in the MIBS. 6 - o midcomSessionRuleIndexNext This object returns a part of an index that is so far unused in the midcomRuleTable. The full unused index is given by the combination of values of the objects midcomSessionOwner and midcomSessionRuleGroupIndex of the same row of the midcomSessionTable in combination with the returned value. o midcomSessionRuleIndexNext SHOULD be midcomSessionRuleNewIndex to be consistent in the document and in the MIBS. 7 - Entries in this table can only be created after a valid value for the midcomRuleIndex has been read from midcomSessionRuleIndexNext in the corresponding entry of the midcomSessionTable. Entries are removed, midcomSessionRuleIndexNext SHOULD be midcomSessionRuleNewIndex to be consistent with the documents and the MIBS. Page 16 ------- 8 - o midcomRulePortRange This object indicates a port ramnge for which a policy reserve rule or policy enable rule was requested or established, respectively. ramnge SHOULD be range. 9 - o midcomRuleRowStatus This object allows entries to be added to the table. There is no such object in the MIBS. This text should be deleted. 10 - - A0 - internal endpoint: address tuple A0 specifies a communication endpoint of a devices within the - with respect to a devices SHOULD be a device. Page 18 ------- 11 - o midcomGroupIndex The index of this entry must be unique in combination with the midcomSessionOwner of the entry. entry SHOULD be table since it is the index of the table we are talking. Page 24 ------- 12 - 2. The MIDCOM client reads the midcomSessionNextIndex object in order to receive an index for creating a session. midcomSessionNextIndex SHOULD be midcomSessionIndexNext to be consistent in the document. Page 25 ------- 13 - USM user name and by the index read from the midcomSessionNextIndex object in step 2. midcomSessionNextIndex SHOULD be midcomSessionIndexNext to be consistent in the document. 14 - 4. If the MIDCOM client wants to have all policy rules it creates to be member of the same particular policy rule group, then the MIDCOM client should set the midcomSessionRuleGroupIndex to the group index that is to be used. "group index" at the end SHOULD be "midcomRuleGroup" to ease the reading. 15 - Comments: there are no indications of where, how and by whom are the policy rules are created. 16 - 2. The SNMP manager reads the midcomSessionRuleNewIndex from an open entry in the modcomSessionTable in order to trigger creation of a new entry in the midcomRuleTable. The new entry in the midcomRuleTable has the following index elements: midcomSessionOwner has the same value as the session from which the value of midcomSessionRuleNewIndex was read; midcomGroupIndex has the value of midcomSessionRuleGroupIndex at the time the value of midcomSessionRuleNewIndex was read; and midcomRuleIndex has the value read from midcomSessionRuleNextIndex. "midcomGroupIndex has the value of the midcomSessionRuleGroupIndex" SHOULD be "midcomGroupIndex has the value of the midcomGroup associated with the midcomRuleTable" Page 29 ------- 17 - 1. The MIDCOM MIB implementation sends a midcomRuleEvent notification containing a lifetime value of 0 to the SNMP manager owning the session. Should it be more the SNMP manager owning the midcomGroup. Once the rule is created, it is impossible to find the correlation between a session and a rule. The only correlation possible is between a group/user/rule with the midcomGroup table. Page 31 ------- 18 - - optional monitoring objects that provide information about used resource and statistics resource SHOULD be resources 19 - In the signaling objects branch there are four groups of managed objects defined: SHOULD be "In the signaling objects branch, there are..." Page 32 ------- 20 - -- The table contains objects identify a destination for -- notifications to be sent to the MIDCOM client. -- Also it serves for creating new rows in the -- midcomRuleTable. identify SHOULD be identifying Page 35 ------- 35 - "This object indicated for which policy rule group a policy rule index is generated when object midcomSessionRuleNewIndex is read." SHOULD be "This object indicates from which" Page 36 ------- 36 - The index of the new entry of the midcomRuleTable consists of three elements. The first one is the midcomSession index of the entry at which the value of midcomSessionRuleNewIndex was read. The second index is the current value of midcomSessionRuleGroupIndex in the same entry of the midcomSessionTable. The third element is the value returned then this object is read. "The second index is the current value of midcomSessionRuleGroupIndex in the same entry of the midcomSessionTable" The second index is the value of the midcomGroup Index associated. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue May 18 17:10:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18686 for ; Tue, 18 May 2004 17:10:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBd6-0005FJ-Q4 for midcom-archive@odin.ietf.org; Tue, 18 May 2004 16:56:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IKu4uo020146 for midcom-archive@odin.ietf.org; Tue, 18 May 2004 16:56:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBOi-0007j2-Fl; Tue, 18 May 2004 16:41:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAcD-0007e9-Tk for midcom@optimus.ietf.org; Tue, 18 May 2004 15:51:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10290 for ; Tue, 18 May 2004 15:51:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQAcB-0002Xc-Vw for midcom@ietf.org; Tue, 18 May 2004 15:51:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQAbG-0002U8-00 for midcom@ietf.org; Tue, 18 May 2004 15:50:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BQAaM-0002Os-00 for midcom@ietf.org; Tue, 18 May 2004 15:49:11 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 18 May 2004 12:48:25 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4IJmcSu017591 for ; Tue, 18 May 2004 12:48:39 -0700 (PDT) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with SMTP id AUF94282; Tue, 18 May 2004 12:48:37 -0700 (PDT) Date: Tue, 18 May 2004 15:48:32 -0400 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <57DA244C-A904-11D8-8468-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.553) 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Moving things along 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 Many thanks to Joel Tran for his review of the MIB draft. We're currently shooting for the end of June to have the document into WG last call, which means that we need to get serious about giving the good document a good read and identifying problems or issues that need to be resolved. I'm requesting a 2-hour slot for the August IETF meeting, but ideally the MIB will be in the hands of the IESG and we'll be able to cancel the session. Efforts to help out by providing document review are very much appreciated. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed May 19 05:53:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25959 for ; Wed, 19 May 2004 05:53:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNcN-00060o-Uf for midcom-archive@odin.ietf.org; Wed, 19 May 2004 05:44:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9i7vW022974 for midcom-archive@odin.ietf.org; Wed, 19 May 2004 05:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN7c-0007jh-0l; Wed, 19 May 2004 05:12:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQMRK-0002a0-Ly for midcom@optimus.ietf.org; Wed, 19 May 2004 04:28:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21191 for ; Wed, 19 May 2004 04:28:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQMRH-0001WT-S8 for midcom@ietf.org; Wed, 19 May 2004 04:28:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQMQH-0001OI-00 for midcom@ietf.org; Wed, 19 May 2004 04:27:34 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BQMPT-0001Gg-00 for midcom@ietf.org; Wed, 19 May 2004 04:26:43 -0400 Received: from [10.1.1.109] (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 275FAF674; Wed, 19 May 2004 10:31:43 +0200 (CEST) Date: Wed, 19 May 2004 10:26:20 +0200 From: Martin Stiemerling To: Joel Tran , midcom@ietf.org, srisuresh@yahoo.com, quittek@netlab.nec.de Message-ID: <2147483647.1084962380@[10.1.1.109]> In-Reply-To: <004c01c43c4b$0c04c730$b248d284@kamel> References: <004c01c43c4b$0c04c730$b248d284@kamel> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Comments on draft-ietf-midcom-mib-01.txt 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 Joel, Thanks for doing the really careful review. My responses are inline. Cheers, Martin --On Montag, 17. Mai 2004 16:10 Uhr -0400 Joel Tran wrote: | Here are my few comments on the midcom mib draft. | | I have also few questions on the draft. | | 1 - Is there any correlation between the midcomGroupTable and the | midcomRuleGroup? The midcomRuleGroup does not correlate with midcomGroupTable. The midcomRuleGroup is out of the compliance section (midcomCompliance) and describes with objects are mandatory and which are optional. midcomGroupGroup correlates with midcomGroupTable. | | 2 - The draft does not address HOW and WHO is creating the midomRuleGroup. The exact way of creating/deleting entries in midcomRuleGroup is described in the MIDCOM semantics (draft-ietf-midcom-semantics-07.txt): Entries in this table are created implicitly whenever an entry in midcomRuleTable with a new group ID is created and deleted when the last entry with the corresponding group ID is deleted in midcomRuleTable. | | ...J | | | Page 14 | ------- | | 1 - Title : 5.1.1. MidcomSession | Should be : MidcomSessionTable OK, fixed. | | 2 - | o midcomSessionOwner | This string indicated the user that created and owns the | session. It is the firswt index element of this table. All | policy rules (and policy rule groups) have the same owner as the | | first not firswt. OK, fixed. | | Page 15 | ------- | | o midcomSessionRuleGroupIndex | The group for which a free index in the policyRuleTable is | obtained by reading object midcomSessionRuleNewIndex. This | object must be set properly before reading a free index from | midcomSessionRuleIndexNext. | | 3 - It is in the midcomRuleTable not policyRuleTable that we are | searching a free index. Thanks that's a leftover, fixed. | | 4 - I don't understand the part "is obtained by reading object | midcomSessionRuleNewIndex". In my understanding, the phrase should be | something like: "The group for which a free index | midcomSessionRuleNewIndex is associated." The sentence is chopped somehow. Here is proposal for new text replacing the first sentence: The group index that is used as value for object midcomGroupIndex when obtaining a new rule index by reading object midcomSessionRuleNewIndex. | | 5 - At the end, it should by midcomSessionRuleNewIndex to be consistent in | the document and in the MIBS. Yes, should be the same, fixed. | | 6 - | o midcomSessionRuleIndexNext | This object returns a part of an index that is so far unused in | the midcomRuleTable. The full unused index is given by the | combination of values of the objects midcomSessionOwner and | midcomSessionRuleGroupIndex of the same row of the | midcomSessionTable in combination with the returned value. | | o midcomSessionRuleIndexNext SHOULD be midcomSessionRuleNewIndex to be | consistent in the document and in the MIBS. Ok, fixed. | | 7 - | Entries in this table can only be created after a valid value for the | midcomRuleIndex has been read from midcomSessionRuleIndexNext in the | corresponding entry of the midcomSessionTable. Entries are removed, | | midcomSessionRuleIndexNext SHOULD be midcomSessionRuleNewIndex to be | consistent with the documents and the MIBS. OK, fixed. | | | Page 16 | ------- | | 8 - | o midcomRulePortRange | This object indicates a port ramnge for which a policy reserve | rule or policy enable rule was requested or established, | respectively. | | ramnge SHOULD be range. OK, fixed. | | 9 - | o midcomRuleRowStatus | This object allows entries to be added to the table. | | There is no such object in the MIBS. This text should be deleted. OK, that's an old entry, fixed. | | 10 - | | - A0 - internal endpoint: address tuple A0 specifies a | communication endpoint of a devices within the - with respect to | | a devices SHOULD be a device. OK, fixed. | | Page 18 | ------- | | 11 - | o midcomGroupIndex | The index of this entry must be unique in combination with the | midcomSessionOwner of the entry. | | entry SHOULD be table since it is the index of the table we are talking. Right, fixed. | | Page 24 | ------- | | 12 - | | 2. The MIDCOM client reads the midcomSessionNextIndex object in order | to receive an index for creating a session. | | midcomSessionNextIndex SHOULD be midcomSessionIndexNext to be consistent | in the document. OK, fixed. | | Page 25 | ------- | 13 - | USM user name and by the index read from the | midcomSessionNextIndex object in step 2. | | midcomSessionNextIndex SHOULD be midcomSessionIndexNext to be consistent | in the document. Right, fixed. | | 14 - | 4. If the MIDCOM client wants to have all policy rules it creates to | be member of the same particular policy rule group, then the | MIDCOM client should set the midcomSessionRuleGroupIndex to the | group index that is to be used. | | "group index" at the end SHOULD be "midcomRuleGroup" to ease the | reading. I see, but the object for group indices is midcomGroupIndex. | | 15 - Comments: there are no indications of where, how and by whom are the | policy rules are created. This is intentionally not given, since this is specific to MIDCOM MIB implementations. | | 16 - | 2. The SNMP manager reads the midcomSessionRuleNewIndex from an open | entry in the modcomSessionTable in order to trigger creation of a | new entry in the midcomRuleTable. The new entry in the | midcomRuleTable has the following index elements: | midcomSessionOwner has the same value as the session from which | the value of midcomSessionRuleNewIndex was read; midcomGroupIndex | has the value of midcomSessionRuleGroupIndex at the time the value | of midcomSessionRuleNewIndex was read; and midcomRuleIndex has the | value read from midcomSessionRuleNextIndex. | | "midcomGroupIndex has the value of the midcomSessionRuleGroupIndex" | SHOULD be "midcomGroupIndex has the value of the midcomGroup associated | with the midcomRuleTable" No, text is OK. midcomGroupIndex has really the value of midcomSessionGroupIndex. The midcomGroupGroup is just a compliancy statement. | | Page 29 | ------- | | 17 - | 1. The MIDCOM MIB implementation sends a midcomRuleEvent notification | containing a lifetime value of 0 to the SNMP manager owning the | session. | | Should it be more the SNMP manager owning the midcomGroup. Once the rule | is created, it is impossible to find the correlation between a session | and a rule. The only correlation possible is between a group/user/rule | with the midcomGroup table. It is not the midcomGroup. You can find the relation between a session and the rules by using midcomSessionOwner of the midcomRuleTable index. | | Page 31 | ------- | 18 - | - optional monitoring objects that provide information | about used resource and statistics | | resource SHOULD be resources OK, fixed. | | 19 - | In the signaling objects branch there are four groups of | managed objects defined: | | SHOULD be "In the signaling objects branch, there are..." OK, fixed. | | Page 32 | ------- | 20 - | -- The table contains objects identify a destination for | -- notifications to be sent to the MIDCOM client. | -- Also it serves for creating new rows in the | -- midcomRuleTable. | | identify SHOULD be identifying OK, fixed. | | Page 35 | ------- | 35 - | "This object indicated for which policy rule group | a policy rule index is generated when object | midcomSessionRuleNewIndex is read." | | SHOULD be "This object indicates from which" The text is correct, since the the policy rule index is not generated out of the poliy rule group, but the relationship betwenn both is given. | | Page 36 | ------- | 36 - | The index of the new entry of the midcomRuleTable | consists of three elements. The first one is the | midcomSession index of the entry at which the value | of midcomSessionRuleNewIndex was read. The second | index is the current value of midcomSessionRuleGroupIndex | in the same entry of the midcomSessionTable. The third | element is the value returned then this object is read. | | "The second index is the current value of midcomSessionRuleGroupIndex in | the same entry of the midcomSessionTable" The second index is the value of | the midcomGroup Index associated. | | The original text is OK, since not midcomGroup is not associated with midcomGroupIndex or midcomSessionRuleGroupIndex. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed May 19 16:05:20 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10177 for ; Wed, 19 May 2004 16:05:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWw1-0003Uh-PA for midcom-archive@odin.ietf.org; Wed, 19 May 2004 15:41:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JJf1S3013427 for midcom-archive@odin.ietf.org; Wed, 19 May 2004 15:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWla-0007sF-LP; Wed, 19 May 2004 15:30:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVxw-0000JC-51 for midcom@optimus.ietf.org; Wed, 19 May 2004 14:38:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29403 for ; Wed, 19 May 2004 14:38:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQVxt-0006vN-Ba for midcom@ietf.org; Wed, 19 May 2004 14:38:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQVx6-0006pH-00 for midcom@ietf.org; Wed, 19 May 2004 14:38:06 -0400 Received: from smtp1.usherbrooke.ca ([132.210.244.17] helo=courrier3.usherbrooke.ca) by ietf-mx with esmtp (Exim 4.12) id 1BQVv5-0006bp-00 for midcom@ietf.org; Wed, 19 May 2004 14:35:59 -0400 Received: from traj1901.gel.usherb.ca (traj1901.gel.usherb.ca [132.210.72.178]) by courrier3.usherbrooke.ca (8.11.6/8.11.6) with ESMTP id i4JIZJp22266; Wed, 19 May 2004 14:35:19 -0400 From: Joel Tran Reply-To: joel.tran@USherbrooke.ca To: Martin Stiemerling Cc: midcom@ietf.org, srisuresh@yahoo.com, quittek@netlab.nec.de In-Reply-To: <2147483647.1084962380@[10.1.1.109]> References: <004c01c43c4b$0c04c730$b248d284@kamel> <2147483647.1084962380@[10.1.1.109]> Content-Type: text/plain Organization: Université de Sherbrooke Message-Id: <1084991719.2550.38.camel@traj1901.gel.usherb.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 19 May 2004 14:35:19 -0400 X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Comments on draft-ietf-midcom-mib-01.txt 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 Thanks you the infos. I didn't understood at first the goal of the midcomConformance MIB section. One last quick question, what is the relation between the midcomSessionTable and the midcomGroupTable? In my understanding, when a midcomSession is created, a midcomGroupTable entry can be associated in order to associate midcomRuleTable entry together (i.e. group midcomRuleTable entry). Comments inline. ...J > | > | Page 15 > | ------- > | > | o midcomSessionRuleGroupIndex > | The group for which a free index in the policyRuleTable is > | obtained by reading object midcomSessionRuleNewIndex. This > | object must be set properly before reading a free index from > | midcomSessionRuleIndexNext. > | > | 3 - It is in the midcomRuleTable not policyRuleTable that we are > | searching a free index. > > Thanks that's a leftover, fixed. > > | > | 4 - I don't understand the part "is obtained by reading object > | midcomSessionRuleNewIndex". In my understanding, the phrase should be > | something like: "The group for which a free index > | midcomSessionRuleNewIndex is associated." > > The sentence is chopped somehow. Here is proposal for new text replacing > the first sentence: > > The group index that is used as value for object midcomGroupIndex when > obtaining a new rule index by reading object midcomSessionRuleNewIndex. I agree with your new sentence. However, I think there is a name confusion in the document. I think that the object midcomSessionRuleGroupIndex of the midcomSessionTable SHOULD be midcomSessionGroupIndex. The current name (midcomSessionRuleGroupIndex) is confusing considering that there is a midcomSessionRuleGroup. One might think that it is the index of this table (even if it is a conformance stuff). In the other case, there is a mistake in the page 25. There is no object midcomSessionGroupIndex in the MIBs. > | 14 - > | 4. If the MIDCOM client wants to have all policy rules it creates to > | be member of the same particular policy rule group, then the > | MIDCOM client should set the midcomSessionRuleGroupIndex to the > | group index that is to be used. > | > | "group index" at the end SHOULD be "midcomRuleGroup" to ease the > | reading. > > I see, but the object for group indices is midcomGroupIndex. Understanding the conformance section now, I fully agree. > | > | 15 - Comments: there are no indications of where, how and by whom are the > | policy rules are created. > > This is intentionally not given, since this is specific to MIDCOM MIB > implementations. > > | > | 16 - > | 2. The SNMP manager reads the midcomSessionRuleNewIndex from an open > | entry in the modcomSessionTable in order to trigger creation of a > | new entry in the midcomRuleTable. The new entry in the > | midcomRuleTable has the following index elements: > | midcomSessionOwner has the same value as the session from which > | the value of midcomSessionRuleNewIndex was read; midcomGroupIndex > | has the value of midcomSessionRuleGroupIndex at the time the value > | of midcomSessionRuleNewIndex was read; and midcomRuleIndex has the > | value read from midcomSessionRuleNextIndex. > | > | "midcomGroupIndex has the value of the midcomSessionRuleGroupIndex" > | SHOULD be "midcomGroupIndex has the value of the midcomGroup associated > | with the midcomRuleTable" > > No, text is OK. midcomGroupIndex has really the value of > midcomSessionGroupIndex. The midcomGroupGroup is just a compliancy > statement. Again, the object name midcomSessionRuleGroupIndex confused me. I was thinking that it was reference to the midcomRuleGroup. This should be changed to midcomSessionGroupIndex for a better understanding and avoid confusion. > > | > | Page 29 > | ------- > | > | 17 - > | 1. The MIDCOM MIB implementation sends a midcomRuleEvent notification > | containing a lifetime value of 0 to the SNMP manager owning the > | session. > | > | Should it be more the SNMP manager owning the midcomGroup. Once the rule > | is created, it is impossible to find the correlation between a session > | and a rule. The only correlation possible is between a group/user/rule > | with the midcomGroup table. > > It is not the midcomGroup. You can find the relation between a session and > the rules by using midcomSessionOwner of the midcomRuleTable index. > > I understand your point. However, my point is that a session in midcomSessionTable might be terminated and some rule might be still active. Do we want to send a TRAP to the owner of the session (NONE) or to the owner identified by midcomSessionOwner? The midcomGroup table is probably not the best way. I think that a trap to the midcomSesionOwner is enough. > | > | Page 35 > | ------- > | 35 - > | "This object indicated for which policy rule group > | a policy rule index is generated when object > | midcomSessionRuleNewIndex is read." > | > | SHOULD be "This object indicates from which" > > The text is correct, since the the policy rule index is not generated out > of the poliy rule group, but the relationship betwenn both is given. My mistake. Sorry. > | > | Page 36 > | ------- > | 36 - > | The index of the new entry of the midcomRuleTable > | consists of three elements. The first one is the > | midcomSession index of the entry at which the value > | of midcomSessionRuleNewIndex was read. The second > | index is the current value of midcomSessionRuleGroupIndex > | in the same entry of the midcomSessionTable. The third > | element is the value returned then this object is read. > | > | "The second index is the current value of midcomSessionRuleGroupIndex in > | the same entry of the midcomSessionTable" The second index is the value of > | the midcomGroup Index associated. > | > | > > The original text is OK, since not midcomGroup is not associated with > midcomGroupIndex or midcomSessionRuleGroupIndex. Sorry, I ment midcomGroupTable... Chears! _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom