From midcom-bounces@ietf.org Tue Aug 01 11:34:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wGO-0002qn-C3; Tue, 01 Aug 2006 11:34:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wG2-0001qI-1p; Tue, 01 Aug 2006 11:34:10 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7wG1-0002G4-PJ; Tue, 01 Aug 2006 11:34:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BA19332874; Tue, 1 Aug 2006 15:34:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G7dm5-0007YA-HK; Mon, 31 Jul 2006 15:50:01 -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, 31 Jul 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: midcom@ietf.org Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-08.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-08.txt Pages : 88 Date : 2006-7-31 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-08.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-08.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-08.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-7-31125633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-31125633.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 Thu Aug 03 13:10:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ghv-0002m7-N5; Thu, 03 Aug 2006 13:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ghs-0002lX-QN; Thu, 03 Aug 2006 13:10:00 -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 1G8ghs-0005C1-O3; Thu, 03 Aug 2006 13:10:00 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8ghr-0000ww-06; Thu, 03 Aug 2006 13:10:00 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id CA47A17662; Thu, 3 Aug 2006 17:09:28 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G8ghM-0007if-Fb; Thu, 03 Aug 2006 13:09:28 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 03 Aug 2006 13:09:28 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: midcom@ietf.org Subject: [midcom] Last Call: 'Definitions of Managed Objects for Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib) X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org The IESG has received a request from the Middlebox Communication WG to consider the following document: - 'Definitions of Managed Objects for Middlebox Communication ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-17. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-08.txt _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Mon Aug 07 13:53:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9Hp-0004ck-Rz; Mon, 07 Aug 2006 13:53:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA5gL-0000ZF-F0; Mon, 07 Aug 2006 10:02:13 -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 1GA4ZH-000325-8R; Mon, 07 Aug 2006 08:50:51 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GA4Vs-0001qm-Q9; Mon, 07 Aug 2006 08:47:22 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k77CfqhU006038; Mon, 7 Aug 2006 08:41:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Aug 2006 15:47:11 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: 'Definitions of Managed Objects for Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib) Thread-Index: Aca3IFkphxgcN7+9QMmb2v9ih8IrXQC33a9w From: "Romascanu, Dan \(Dan\)" To: , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: -2.5 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-Mailman-Approved-At: Mon, 07 Aug 2006 13:53:09 -0400 Cc: midcom@ietf.org Subject: [midcom] RE: Last Call: 'Definitions of Managed Objects for Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib) 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 1. Is the 'strict' SNMP terminology intentionally avoided in Section 4.2 and associated diagrams, and why? Meaning why do we say 'SNMP get message' instead of 'SNMP GetRequest PDU', etc. ? 2. Section 5.3.1 > The MIDCOM MIB module does not require a middlebox to implement further specific MIB modules for supported middlebox functions, such as, for example, the NAT MIB module [RFC4008]. =20 This should probably be 'further specific middlebox (NAT devices, firewall) MIB modules' 3. Object midcomRuleAdminStatus > midcomRuleAdminStatus OBJECT-TYPE SYNTAX INTEGER { reserve(1), enable(2), notSet(3) } ... When retrieved, the object returns the last set value. If no value has been set, it returns one of the two possible values." DEFVAL { notSet } I do not understand what are the 'two possible values'. What happens of a retrieval happens before the object is set for the first time?=20 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.=20 5. What happens with the object midcomRuleObjectTime when midcomRuleObjectType is permanent(4)? The DESCRIPTION clause of the type object suggests that time is read-only. With DEFVAL 0 this means automatic destruction of the row at the end of the transaction. Is this the desired behavior, or did I mis-understand something?=20 6. I do not feel comfortable with the DESCRIPTION clause of midcomRuleError RECOMMENDing values for this object without defining what behavior each message is supposed to cover. This type of object is not interoperable, and this would be made clear if it was said that these are examples rather than RECOMMENDations.=20 7. Another side-effect of the midcomRuleObjectType being permanent(4) is that the permanent rules cannot be applied to interfaces, so they can be only global. Same about transport protocol and other read-write objects. 8 . There is no DEFVAL for midcomRuleFlowDirection=20 9.=20 > Valid values for midcomRuleTransportProtocol other than zero are defined at: http://www.iana.org/assignments/protocol-numbers Does this need a new type of registry from IANA? There is nothing in the IANA considerations about this.=20 10. What notification needs to be sent when midcomConfigIfEnabled is set to false? Neither the DESCRIPTION of the object nor the one of the notifications do provide any clue.=20 =20 =20 > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org]=20 > Sent: Thursday, August 03, 2006 8:09 PM > To: IETF-Announce > Cc: midcom@ietf.org > Subject: Last Call: 'Definitions of Managed Objects for=20 > Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib)=20 >=20 > The IESG has received a request from the Middlebox=20 > Communication WG to consider the following document: >=20 > - 'Definitions of Managed Objects for Middlebox Communication ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and=20 > solicits final comments on this action. Please send any=20 > comments to the iesg@ietf.org or ietf@ietf.org mailing lists=20 > by 2006-08-17. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-08.txt >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Mon Aug 28 02:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHaQG-0005xB-7I; Mon, 28 Aug 2006 02:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHaPl-0005JL-D2 for midcom@ietf.org; Mon, 28 Aug 2006 02:16:05 -0400 Received: from web33301.mail.mud.yahoo.com ([68.142.206.116]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHaAZ-0007PU-BA for midcom@ietf.org; Mon, 28 Aug 2006 02:00:26 -0400 Received: (qmail 4181 invoked by uid 60001); 28 Aug 2006 06:00:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bEGI9qbfc9loFCvxaT4C7erE4UVwTSdDuD/pw0Ik5gt5ut+eASO7QOON8AsU49MPkflk6y7IaogAEoxnJKlm0jaW4Et6qc5/1tT3NCjzZMn8P5isCYjElA8a8K9YYTYiGtO7bx2u76XU8BKrUP4nNaJ85m+p9FoBu1pbK+HN57w= ; Message-ID: <20060828060020.4179.qmail@web33301.mail.mud.yahoo.com> Received: from [69.236.82.106] by web33301.mail.mud.yahoo.com via HTTP; Sun, 27 Aug 2006 23:00:20 PDT Date: Sun, 27 Aug 2006 23:00:20 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: Last Call: 'Definitions of Managed Objects for Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib) To: "Romascanu, Dan \(Dan\)" , iesg@ietf.org, ietf@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: midcom@ietf.org 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 Dan, Thank you for your detailed comments. Sorry for the delayed response. I was away on vacation and just got back. Please see my responses below inline. regards, suresh --- "Romascanu, Dan (Dan)" wrote: > 1. Is the 'strict' SNMP terminology intentionally avoided in Section 4.2 > and associated diagrams, and why? Meaning why do we say 'SNMP get > message' instead of 'SNMP GetRequest PDU', etc. ? [suresh] The objective of section 4.2 was essentially to indicate how the MIDCOM transactions can be mapped to SNMP. I.e., make the description of MIDCOM transactions to SNMP mapping easy to underdtand. Terms like "SNMP get message" and "SNMP put message" are simply easier for the reader to relate while talking about transactions. > 2. Section 5.3.1 > > The MIDCOM MIB module does not require a middlebox to implement > further specific MIB modules for supported middlebox functions, such > as, for example, the NAT MIB module [RFC4008]. > > This should probably be 'further specific middlebox (NAT devices, > firewall) MIB modules' > as, for example, the NAT MIB module [RFC4008]. > [suresh] OK; with a minor tweak to your suggested text as follows. s/"(NAT devices, firewall)"/"(NAT, Firewll)/ > 3. Object midcomRuleAdminStatus > > > midcomRuleAdminStatus OBJECT-TYPE > SYNTAX INTEGER { > reserve(1), > enable(2), > notSet(3) > } > ... > When retrieved, the object returns the last set value. If > no value has been set, it returns one of the two possible > values." > DEFVAL { notSet } > > I do not understand what are the 'two possible values'. What happens of > a retrieval happens before the object is set for the first time? > [suresh] Oops... Will change the text to read as follows. When retrieved, the object returns the last set value. If no value has been set, it returns the default value of notset(3). > 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. > 5. What happens with the object midcomRuleObjectTime when > midcomRuleObjectType is permanent(4)? The DESCRIPTION clause of the type > object suggests that time is read-only. With DEFVAL 0 this means > automatic destruction of the row at the end of the transaction. Is this > the desired behavior, or did I mis-understand something? [suresh] Yes, I believe, that is the desired behaviour. Note, however, the DESCRIPTION for midcomRuleStorageType says that attempts to set this object to permanent will always fail with an inconsistentValue error. And, the default value for this object is volatile(2). > > 6. I do not feel comfortable with the DESCRIPTION clause of > midcomRuleError RECOMMENDing values for this object without defining > what behavior each message is supposed to cover. This type of object is > not interoperable, and this would be made clear if it was said that > these are examples rather than RECOMMENDations. > [suresh] I am OK with listing the error strings as examples, rather than as recommendations. I will leave to Juergen or Martin to further comment on this. > 7. Another side-effect of the midcomRuleObjectType being permanent(4) is > that the permanent rules cannot be applied to interfaces, so they can be > only global. Same about transport protocol and other read-write objects. > [suresh] As I said earlier, attempts to set midcomRuleStorageType to permanent will always fail with an inconsistentValue error. > 8 . There is no DEFVAL for midcomRuleFlowDirection > [suresh] Right, that was intentional. > 9. > > Valid values for midcomRuleTransportProtocol > other than zero are defined at: > http://www.iana.org/assignments/protocol-numbers > > Does this need a new type of registry from IANA? There is nothing in the > IANA considerations about this. [suresh] Well, nothing specific to MIDCOM MIB per se. IANA assigns IP protocol numbers independently, right. > > 10. What notification needs to be sent when midcomConfigIfEnabled is set > to false? Neither the DESCRIPTION of the object nor the one of the > notifications do provide any clue. > [suresh] The DESCRIPTION for midcomConfigIfEnabled does say the following. Setting this object to false(2) immediately stops middlebox support at the indexed IP interface. This implies that all policy rules that use NAT or firewall resources at the indexed IP interface are terminated immediately. In this case, The MIDCOM agent MUST send notifications to all MIDCOM clients that have access to one of the terminated rules. As for the rule termination event, please refer section 7.9. regards, suresh > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: Thursday, August 03, 2006 8:09 PM > > To: IETF-Announce > > Cc: midcom@ietf.org > > Subject: Last Call: 'Definitions of Managed Objects for > > Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib) > > > > The IESG has received a request from the Middlebox > > Communication WG to consider the following document: > > > > - 'Definitions of Managed Objects for Middlebox Communication ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and > > solicits final comments on this action. Please send any > > comments to the iesg@ietf.org or ietf@ietf.org mailing lists > > by 2006-08-17. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-08.txt > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > > _______________________________________________ > 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 midcom-bounces@ietf.org Mon Aug 28 12:35:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHk4d-0004Xc-42; Mon, 28 Aug 2006 12:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHk4b-0004O2-6e for midcom@ietf.org; Mon, 28 Aug 2006 12:34:53 -0400 Received: from web33314.mail.mud.yahoo.com ([68.142.206.129]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHjyH-0005bq-5O for midcom@ietf.org; Mon, 28 Aug 2006 12:28:22 -0400 Received: (qmail 33840 invoked by uid 60001); 28 Aug 2006 16:28:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MgEBghYIxTYKP74I0t44VBZtgVd3E583OArWrqG1/1NsLUDC4jqB2h0Yw9opTBE6Jj64InMHfcoAhuLpcE+s0sSAGd5PViAJgSuuw7/LSdgJlf2Ng7bu436N6uSND9nK01FS+Lq/YHP0ig/1+ALT2R+YVeP+f7A1AXLj2uTmiUk= ; Message-ID: <20060828162820.33838.qmail@web33314.mail.mud.yahoo.com> Received: from [69.236.82.106] by web33314.mail.mud.yahoo.com via HTTP; Mon, 28 Aug 2006 09:28:20 PDT Date: Mon, 28 Aug 2006 09:28:20 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] RE: Last Call: 'Definitions of Managed Objects for Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib) To: "Romascanu, Dan \(Dan\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: midcom@ietf.org 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, Thanks. Please see my responses inline. regards, suresh --- "Romascanu, Dan (Dan)" wrote: > Hi Suresh, > > (I took out the ietf and iesg lists from the distribution) > > Thank you for the answers. I am happy with many of them, I am waiting > for clarification from you co-authors on a couple of issues, and have > two more comments on your answers: > [suresh] Sounds good. Thanks. > > > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > >> > > > 8 . There is no DEFVAL for midcomRuleFlowDirection > > > > > [suresh] Right, that was intentional. > > > > In the absence of a DEFVAL what is supposed to return an agent on a read > operation before the object was first time written? > [suresh] I see what you mean. I think, it should be OK to set the DEFVAL to outbound(2). > > > 10. What notification needs to be sent when > > midcomConfigIfEnabled is > > > set to false? Neither the DESCRIPTION of the object nor the > > one of the > > > notifications do provide any clue. > > > > > [suresh] The DESCRIPTION for midcomConfigIfEnabled does say > > the following. > > > > Setting > > this object to false(2) immediately stops middlebox > > support at the indexed IP interface. This implies that > > all policy rules that use NAT or firewall resources at > > the indexed IP interface are terminated immediately. > > In this case, The MIDCOM agent MUST send notifications > > to all MIDCOM clients that have access to one of the > > terminated rules. > > > > I saw this text, but my question was what notifications are being sent? > [suresh] midcomUnsolicitedRuleEvent notifications are sent for each of the rules that refer the ifindex. We will add this to the DESCRIPTION text. Thanks. > Regards, > > Dan regards, suresh _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Wed Aug 30 05:24:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIMIU-0008Im-P5; Wed, 30 Aug 2006 05:23:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIMIT-0008Ih-Sr for midcom@ietf.org; Wed, 30 Aug 2006 05:23:45 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIMIK-0006eh-ES for midcom@ietf.org; Wed, 30 Aug 2006 05:23:45 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5F7754F0043; Wed, 30 Aug 2006 11:22:23 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Aug 2006 11:22:22 +0200 Received: from [147.214.31.168] ([147.214.31.168]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Aug 2006 11:22:21 +0200 Message-ID: <44F558CD.1000007@ericsson.com> Date: Wed, 30 Aug 2006 11:22:21 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Pyda Srisuresh Subject: Re: [midcom] RE: Last Call: 'Definitions of Managed Objects forMiddlebox Communication' to Proposed Standard (draft-ietf-midcom-mib) References: <20060828162820.33838.qmail@web33314.mail.mud.yahoo.com> In-Reply-To: <20060828162820.33838.qmail@web33314.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2006 09:22:21.0837 (UTC) FILETIME=[CC2ABBD0:01C6CC15] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: midcom@ietf.org, "Romascanu, Dan \(Dan\)" 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, If I interpret the last call comments correctly there is need for an updated version of the draft before progressing to IESG evaluation. 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 From midcom-bounces@ietf.org Wed Aug 30 08:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIPFt-0002fO-Ik; Wed, 30 Aug 2006 08:33:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIPFs-0002fD-5R for midcom@ietf.org; Wed, 30 Aug 2006 08:33:16 -0400 Received: from web33309.mail.mud.yahoo.com ([68.142.206.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIPFn-0007Fx-Q3 for midcom@ietf.org; Wed, 30 Aug 2006 08:33:16 -0400 Received: (qmail 96633 invoked by uid 60001); 30 Aug 2006 12:33:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=v87nGsusPcHAuHOMTHeVtCVMQEu4i6r3+noe3oyfEElcUFIryw4Rr57UNCuJRAZp5MPZHPVWIYKGaLaJLcd2n0xIVNlKA/sDKu4TePg0FtfKlRZdf91F8IjjCDxlQuXO6BWcvCFG4cD6zoaU6CSfyV8j6pTTk8Yj06mfmsWa47o= ; Message-ID: <20060830123309.96630.qmail@web33309.mail.mud.yahoo.com> Received: from [69.236.82.106] by web33309.mail.mud.yahoo.com via HTTP; Wed, 30 Aug 2006 05:33:09 PDT Date: Wed, 30 Aug 2006 05:33:09 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: Last Call: 'Definitions of Managed Objects forMiddlebox Communication' to Proposed Standard (draft-ietf-midcom-mib) To: Magnus Westerlund In-Reply-To: <44F558CD.1000007@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: midcom@ietf.org, "Romascanu, Dan \(Dan\)" 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 Right. We will have an updated version of the draft shortly. Thank you. regards, suresh --- Magnus Westerlund wrote: > Hi, > > If I interpret the last call comments correctly there is need for an > updated version of the draft before progressing to IESG evaluation. > > 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