From midcom-bounces@ietf.org Tue May 02 07:24:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fasyx-0004Ks-Ue; Tue, 02 May 2006 07:23:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fasvh-0001iy-HQ; Tue, 02 May 2006 07:20:33 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fasvg-0005z9-32; Tue, 02 May 2006 07:20:33 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k42BKTnc030806; Tue, 2 May 2006 14:20:31 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 14:20:11 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 14:20:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 May 2006 14:20:11 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB407688@esebe100.NOE.Nokia.com> In-Reply-To: <44567016.9040408@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for a review of the "NAT/Firewall NSIS Signaling Layer Protocol (NSLP) " Thread-Index: AcZtXpAo4ZqImHbcQjOAYQJ4vNANNQAeuKiw From: To: , X-OriginalArrivalTime: 02 May 2006 11:20:11.0209 (UTC) FILETIME=[60454B90:01C66DDA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Tue, 02 May 2006 07:23:54 -0400 Cc: nsis@ietf.org Subject: [midcom] Request for a review of the "NAT/Firewall NSIS Signaling Layer Protocol (NSLP) " 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, Currently, the NSIS working group is finalizing the "NAT/Firewall NSIS Signaling=20 Layer Protocol (NSLP)" for signaling middleboxes. The current document can be found here: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt NSIS is working on a path-coupled signaling protocol, to signal nodes along the data patch. As both NAT and Firewalls are along the data path, NSIS signaling is developing a protocol for allow end nodes to signal these boxes. As both BEHAVE and MIDCOM have been working on related issues, I'd like to encourage people to read the document and send comments and questions to the mailing list - nsis@ietf.org. As long as your subject lines are clearly marked, I'll enable posting rights so that you don't have to join the NSIS mailing list. Additionally, please try not to cross-post discussion on the other mailing lists; unless the BEHAVE & MIDCOM chairs feel that cross-posting would be beneficial. thanks, John=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Wed May 31 09:09:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQRe-0008O9-Eb; Wed, 31 May 2006 09:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQRd-0008O4-Od for midcom@ietf.org; Wed, 31 May 2006 09:09:05 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQRc-0002op-71 for midcom@ietf.org; Wed, 31 May 2006 09:09:05 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6F1124D33C; Wed, 31 May 2006 15:09:03 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 18477-09; Wed, 31 May 2006 15:09:00 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id CBE5F4D337; Wed, 31 May 2006 15:08:55 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id BCFD67398A0; Wed, 31 May 2006 15:08:53 +0200 (CEST) Date: Wed, 31 May 2006 15:08:53 +0200 From: Juergen Schoenwaelder To: Juergen Quittek , Martin Stiemerling , "P. Srisuresh" Message-ID: <20060531130853.GC4696@boskop.local> Mail-Followup-To: Juergen Quittek , Martin Stiemerling , "P. Srisuresh" , Melinda Shore , Magnus Westerlund , Lars Eggert , Dan Romascanu , midcom@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Melinda Shore , Lars Eggert , midcom@ietf.org, Dan Romascanu Subject: [midcom] midcom revised mib review X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Hi, first of all, I have to apologize for the delay (I will spare you the reasons you might not be interested in anyway). I have read once again carefully. I think it is generally of high quality and I do not have major problems with it. Still, I have a few comments I like to share with you and perhaps some of the things can still be improved without much further delay. a) p6: "sending notification to MIDCOM client" - either "a MIDCOM client" or "MIDCOM clients" b) p13: "for request message and reply message" -> "for the request and the reply message" c) p17: "For example, it can" -> "For example, they can" d) p22: "The values provide" -> "The values provided" e) p26: "the idle or" -> "the idle time" f) p27: "MIDCOm" -> "MIDCOM" g) p29: "For some application" -> "For some applications" h) p29: I am wondering why the document does not suggest to use snmpSetSerialNo to solve the idempotency problem. i) p30: "below recommended" -> "below are recommended" j) p31ff: I am still somewhat concerned about the fact that the text encourages implementors to potentially do the wrong thing. You can't rely on notifications. While step 7. in section 7.3 says the right thing, I would prefer if the text would actually be moved where it belonts, namely in step 4. So here is what I propose how step 4 should be written: 4. The MIDCOM client awaits a midcomSolicitedRuleEvent notification concerning the new policy rule in the midcomRuleTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry by one or more SNMP get operation. By moving the text into this step, you can get rid of step 7 and make it clearer that you have to write code to poll for the completion of the operation anyways. Note that this change also affects subsequent sections, namely 7.4, 7.5, 7.6, and 7.10. k) p33: Step 5 in 7.5 refers to step 5 in 7.3 but I think it should be step 4 in 7.3. l) p42: The description of midcomRuleOwner is a bit confusing. It says: This object SHOULD uniquely identify an authenticated MIDCOM client. It is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415, VACM) and allows an management application to identify its entries." This sounds like the SnmpAdminString TC has something special concerning VACM which is not true. Perhaps less is more: This object SHOULD uniquely identify an authenticated MIDCOM client. This object is part of the table index to allow for the use of the SNMPv3 View-Based Access Control Model (RFC 3415, VACM). m) p42: Should 0 not be excluded from midcomRuleIndex? You have done this for the midcomGroupIndex. n) p44: The description of midcomRuleOperStatus says that setting(2) indicates that no request was made. I am not sure how this can actually happen since midcomRuleAdminStatus is either reserve(1) or enable(2) and hence during row creation it has to take on one of these values. Perhaps a cleaner way to deal with this would be to add another state off(3) or whatever you want to call it which can be used when a row is created without already setting reserve(1) or enable(2). The other option would be to be very clear that a midcom client has to set either reserve(1) or enable(2) while creating a row in which case the state setting(2) does not make much sense to me. o) p45: "can be retrieved" -> "are meaningful" (twice on that page). My understanding is that you can always retrieve all columns but depending of the midcomRuleAdminStatus only some of them are meaningful. p) p46: "rule is expired" -> "rule has expired" q) p48: midcomRuleError does not support localization and this seems to be a string that is likely to be shown to human users. I am just mentioning this... r) p54: Is there a reason why you do not use the InetAddressPrefixLength TC for midcomRuleInternalIpPrefixLength and midcomRuleExternalIpPrefixLength? In case you use InetAddressPrefixLength, make sure you allocate the max value for the "no wildcarding" semantics and not just 128. s) p63: How does midcomConfigPersistentRules interact with the StorageType objects? In the light of StorageType, the term "persistent" is probably wrong and should be "nonVolatile". t) p63: First sentence in the DESCRIPTION is missing some words. u) p67: "inteface" -> "interface" v) p73: "request. (" -> "request (" w) p74: "request. (" -> "request (" x) p81: "to managed object" -> "to the managed object" /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