From midcom-bounces@ietf.org Sun Oct 08 18:45:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWhOX-0002P3-Us; Sun, 08 Oct 2006 18:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWhOX-0002Oj-1Y for midcom@ietf.org; Sun, 08 Oct 2006 18:45:17 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWhOR-0004JB-KZ for midcom@ietf.org; Sun, 08 Oct 2006 18:45:17 -0400 Received: from [192.168.1.128] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id D32EB1BAC4D; Mon, 9 Oct 2006 00:45:09 +0200 (CEST) Date: Mon, 09 Oct 2006 00:45:05 +0200 From: Juergen Quittek To: "Romascanu, Dan (Dan)" Subject: RE: [midcom] RE: Last Call: 'Definitions of Managed Objects forMiddlebox Communication' to Proposed Standard (draft-ietf-midcom-mib) Message-ID: <53BF315D9FC50C3DBCBD2182@[192.168.1.128]> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: midcom@ietf.org, Martin Stiemerling , Pyda Srisuresh X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Hi Dan, I added the note that you suggested in the text below to all occurrences of error code 'inconsistentValue'. Thanks, Juergen --On 26.09.2006 12:54 Uhr +0300 Romascanu, Dan (Dan) wrote: > Thanks, I have just one comment on one of the points, see below. > > Dan > > > > > >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@netlab.nec.de] > > >> >> 4. Several DESCRIPTION clauses (e.g. midcomRuleAdminStatus, >> >> midcomRuleStorageType) include SNMP-specific error messages when >> >> describing the behavior of the object. This is OK, as the >> MIDCOM-MIB >> >> is designed to be used with SNMP as MIDCOM protocol, yet I would >> >> include a note on this subject because this is not >> customary within >> >> other MIB documents which are written with a >> protocol-independent orientation. >> >> >> > [suresh] I will leave to Juergen or Martin to comment on this. >> >> We assume that you refer to error code 'inconsistentValue' >> that we mention in several DESCRIPTION clauses. >> >> We think this is still customary in recent MIB modules from >> where we got the idea to use this error code. See, for >> example, RFCs 4001, 4087, 4131, 4149, 4268, 4368, 4444, and 4546. > > You are correct, however discussions between MIB Doctors recently led us > to the conclusion that it would be useful to make clear in texts of new > documents that errors like 'inconsistentValue' are specific to the usage > of the SMIv2 MIB module with SNMP, while if the MIB is used by other > protocols there probably would be similar errors under different names. > > As I said, no special problem here, as SNMP is the MIDCOM protocol, but > a note like the following cannot harm. > > 'Note that this error code is SNMP specific. If the MIB module is used > with other protocols than SNMP, errors with similar semantics specific > to those protocols should be returned.' > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Mon Oct 09 15:51:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX19t-0001mE-KD; Mon, 09 Oct 2006 15:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX191-00006O-Ds; Mon, 09 Oct 2006 15:50:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX191-0005fb-BO; Mon, 09 Oct 2006 15:50:35 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GX18z-0004Sr-BA; Mon, 09 Oct 2006 15:50:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 0429F175C1; Mon, 9 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GX18U-0007Ra-HX; Mon, 09 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: midcom@ietf.org Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-09.txt X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org --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-09.txt Pages : 90 Date : 2006-10-9 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 3989. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-09.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-09.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-09.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: <2006-10-9122058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-9122058.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom --NextPart-- From midcom-bounces@ietf.org Tue Oct 10 03:48:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXCLU-0007tn-Mh; Tue, 10 Oct 2006 03:48:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXCLT-0007th-TJ for midcom@ietf.org; Tue, 10 Oct 2006 03:48:11 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXCLP-0004Xy-Cp for midcom@ietf.org; Tue, 10 Oct 2006 03:48:11 -0400 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 76D6D1BAC4D for ; Tue, 10 Oct 2006 09:48:06 +0200 (CEST) Date: Tue, 10 Oct 2006 09:48:04 +0200 From: Juergen Quittek To: midcom@ietf.org Subject: Re: [midcom] I-D ACTION:draft-ietf-midcom-mib-09.txt Message-ID: <0BA5BD16CB34BA2564B8B035@[10.1.1.104]> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Dear all, This new version of the MIDCOM MIB addresses the comments received during IETF last call. Changes include - description of behavior of object midcomRuleStorageTime in case of permanent rule entries - specification of default value to midcomRuleFlowDirection - several minor clarifications and fixes Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 09.10.2006 15:50 Uhr -0400 Internet-Drafts@ietf.org wrote: > 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-09.txt > Pages : 90 > Date : 2006-10-9 > > 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 3989. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-09.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-09.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-09.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. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Wed Oct 25 07:45:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GchBq-0002YL-A8; Wed, 25 Oct 2006 07:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GchBo-0002YB-R2 for midcom@ietf.org; Wed, 25 Oct 2006 07:44:56 -0400 Received: from [202.177.174.130] (helo=mail.spanservices.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GchBl-0005zz-Gh for midcom@ietf.org; Wed, 25 Oct 2006 07:44:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Oct 2006 17:15:36 +0530 Message-ID: <8DA47B9A5400DE40ADB30B051C215CCE02C05964@mail.spanservices.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP over TLS via NAT/Firewall/SIP-ALG Thread-Index: Acb393ZlkAt5rz3qTq+gBEVYw1RJ/AABxuJ/AAsg/UA= References: <8DA47B9A5400DE40ADB30B051C215CCE02C05957@mail.spanservices.com> <8DA47B9A5400DE40ADB30B051C215CCE02C0595A@mail.spanservices.com> From: "SUNIL J. KUMAR" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [midcom] SIP over TLS via NAT/Firewall/SIP-ALG X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Hi All, I am Sunil developing a SIP-ALG which will coexist with NAT/Firewall on = the edge of a trusted network. Aparting from NATting functionality which = ALG will perform, we want to provide support for SIP Security as well = because there could be lot many possible Attacks on the SIP messages = e.g. like Eavesdropping, Session hijacking, DOS Attacks, Sessions tear = down, Impersonnating a server, Registration hijacking etc and as a = solution SIP RFC 3261 suggests that TLS can be a good way to provide = security, which strictly offers hop-by-hop security and this security we = want to provide at SIP-ALG itself sitting along with NAT/Firewall on the = edge. TLS features are: 1. TLS strictly offers hop-by-hop security 2. TLS only allows SIP entities to authenticate servers to which they = are adjacent. 3. TLS does not allow clients to authenticate proxy servers to whom = they cannot form a direct TCP connection. And hence TLS-encrypted message cannot be intercepted by a NAT or = firewall device because SIP-ALG/NAT/Frewall is NOT a SIP Entity (like = proxy/redirect/UA etc). But since I am planning to provide support for TLS at SIP-ALG/NAT so = that we can provide SIP Security from various possible Attacks discussed = above, which means that I should have a SIP Proxy that will co-exist = with SIP-ALG/NAT/Firewall so that it can be on the path of any SIP = Message > > in-coming to or outgoing from the trusted network and I shall be = able to intercept SIP Messages recieved through TLS. Please let us know = whether it'll be an advantageous solution else any suggestion on other = solutions would be of great help. In future I am planning High Avalability support as well for SIP ALG. Regards, Sunil _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Thu Oct 26 12:42:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8J0-0003pn-Kk; Thu, 26 Oct 2006 12:42:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Iy-0003Tt-Qq for midcom@ietf.org; Thu, 26 Oct 2006 12:42:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8Ip-0004iu-Al for midcom@ietf.org; Thu, 26 Oct 2006 12:42:08 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BDA1213F6 for ; Thu, 26 Oct 2006 18:41:58 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 18:41:58 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 18:41:58 +0200 Message-ID: <4540E556.6070408@ericsson.com> Date: Thu, 26 Oct 2006 18:41:58 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 16:41:58.0002 (UTC) FILETIME=[A721DD20:01C6F91D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [midcom] Normative References in draft-ietf-midcom-mib-09 X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Hi In the IESG evaluation of the document it was realized that there was three normative references (RFC 3303, RFC 3404, RFC 3989) that are to informative documents. These are not allowed unless it can be accepted under RFC3967. I have discussed this with the authors and from our point of view RFC 3304 can be changed informative reference, it is not required for implementing the protocol. However RFC 3989 is clearly required to be implemented and that it seems that also RFC 3303 can be consider to be a normative reference. Is anyone in the WG disagreeing about this classification? If the WG is agreeing on a classification that contains any informational RFCs in the normative section the document will require a new IETF last call that calls out these downrefs. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom