RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt
"Christopher A. Martin" <chris@sip1.com> Fri, 14 May 2004 21:21 UTC
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 <midcom-archive@odin.ietf.org>; 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 <midcom@ietf.org>; 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: Chris@sip1.com
From: "Christopher A. Martin" <chris@sip1.com>
To: "'Harrington, David'" <dbh@enterasys.com>, 'Melinda Shore' <mshore@cisco.com>, midcom@ietf.org
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: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=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
- [midcom] I-D ACTION:draft-ietf-midcom-mib-01.txt Internet-Drafts
- Fwd: [midcom] I-D ACTION:draft-ietf-midcom-mib-01… Melinda Shore
- RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.… Medhavi Bhatia
- RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.… Christopher A. Martin
- RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.… Martin Stiemerling
- RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.… Harrington, David
- Re: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.… Juergen Schoenwaelder
- RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.… Christopher A. Martin
- RE: [midcom] I-D ACTION:draft-ietf-midcom-mib-01.… Christopher A. Martin