From midcom-bounces@ietf.org Tue Sep 26 05:05:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS8si-0004kP-DY; Tue, 26 Sep 2006 05:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS8sh-0004kJ-Cj for midcom@ietf.org; Tue, 26 Sep 2006 05:05:35 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS8sd-0006TW-LN for midcom@ietf.org; Tue, 26 Sep 2006 05:05:35 -0400 Received: from [192.168.1.128] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 533101BACA1; Tue, 26 Sep 2006 11:05:30 +0200 (CEST) Date: Tue, 26 Sep 2006 11:05:26 +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: <0ADCFB1A06A28CFC6ECA00AE@[10.1.1.104]> In-Reply-To: <20060828060020.4179.qmail@web33301.mail.mud.yahoo.com> References: <20060828060020.4179.qmail@web33301.mail.mud.yahoo.com> 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: 6a45e05c1e4343200aa6b327df2c43fc 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 Dear Dan, We are very sorry for the late reply on your comments and on Suresh's replies. The reason is that we (Martin and Juergen) wanted to discuss them and did not find time to do so until today, because of our vacation and business trip schedules. Please find our replies inline. If you are fine with them, we will post a new version of the I-D. Thanks, Martin and Juergen --On 28.08.2006 8:00 Uhr +0200 Pyda Srisuresh wrote: > > 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. 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. >> 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. This is a good catch. We did not consider storage type 'permanent' well when writing the DESCRIPTION clause. If the storage time is permanent, the value should never become 0. In this case, we suggest this object to have a permanent value of 4294967295. We propose appending the following paragraph to the DESCRIPTION clause: "If object midcomRuleStorageType indicates that the policy rule has storage type permanent(4), then this object has a constant value of 4294967295." > 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. The errors a re well defined in the MIDCOM protocol semantics (RFC 3989, sections 2.3.9 and 2.3.10). We suggest appending to the DESCRIPTION clause: "The semantics of these error messages and the corresponding behavior of the MIDCOM MIB implementation are specified in sections 2.3.9 and 2.3.10 of RFC 3989." and adding a reference clause REFERENCE "RFC 3989, sections 2.3.9 and 2.3.10" >> 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. As stated in the DESCRIPTION clause of midcomRuleStorageType, a permanent(4) row has all write access to other objects in the row disabled. >> 8 . There is no DEFVAL for midcomRuleFlowDirection >> > [suresh] Right, that was intentional. We added DEFVAL { outbound } as Suresh had suggested in another email. >> 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. The notifications to be sent are of type midcomUnsolicitedRuleEvent. Suggestion: s/notifications/midcomUnsolicitedRuleEvent Thanks, Martin and Juergen > 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Fri Sep 29 10:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJF8-0000aG-9p; Fri, 29 Sep 2006 10:21:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJF6-0000Zr-9G for midcom@ietf.org; Fri, 29 Sep 2006 10:21:32 -0400 Received: from wall.ikr.uni-stuttgart.de ([129.69.170.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTJF5-00047S-P6 for midcom@ietf.org; Fri, 29 Sep 2006 10:21:32 -0400 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4A2AE56DEF for ; Fri, 29 Sep 2006 16:21:29 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 43921BC080; Fri, 29 Sep 2006 16:21:29 +0200 (CEST) Received: from ikr.uni-stuttgart.de (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id D5647BC07E for ; Fri, 29 Sep 2006 16:21:28 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Fri, 29 Sep 2006 16:21:28 +0200 Date: Fri, 29 Sep 2006 16:21:28 +0200 From: Sebastian Kiesel To: midcom@ietf.org Message-ID: <20060929142128.GC27827@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on netsrv1 X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [midcom] Updated Internet Draft and performance studies on "SIMCO over SCTP" 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, Please find below the announcement for a new version of our Internet Draft that specifies how to transport SIMCO [RFC 4540] over SCTP. Changes compared to previous versions of this Internet Draft are only minor, clarifying one special case, fixing a typo, adding the identifiers and port numbers registered with IANA, and updating the references. Any comments are welcome. We have conducted analytical studies as well as measurements on a prototype implementation that compare the SIMCO transaction response time when using TCP or SCTP with different numbers of streams, respectively. For further information see http://www.ikr.uni-stuttgart.de/Content/Publications/View/Standalone/FullRecord.html?36515 http://www.ikr.uni-stuttgart.de/Content/Publications/View/Standalone/FullRecord.html?36482 Any comments are welcome. Thanks, Sebastian -- Sebastian Kiesel University of Stuttgart Tel: +49 711 685 69017 Institute of Communication Networks and Fax: +49 711 685 67983 Computer Engineering (IKR, formerly: IND) kiesel@ikr.uni-stuttgart.de Pfaffenwaldring 47, 70569 Stuttgart, Germany ----- Forwarded message from Internet-Drafts@ietf.org ----- X-Original-To: sebastian.kiesel@ikr.uni-stuttgart.de Delivered-To: kiesel@ikr.uni-stuttgart.de To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Date: Tue, 26 Sep 2006 10:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: I-D ACTION:draft-kiesel-midcom-simco-sctp-02.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIMCO over SCTP Author(s) : S. Kiesel Filename : draft-kiesel-midcom-simco-sctp-02.txt Pages : 13 Date : 2006-9-26 This document specifies how to use SCTP for the transport of the SIMCO (Version 3.0) protocol. SIMCO (SImple Middlebox COnfiguration) is a protocol that implements the MIDCOM semantics. It can be used for controlling middleboxes such as firewalls and network address translators. SCTP (Stream Control Transmission Protocol) is a transport layer protocol that is expected to have advantages for this type of application, compared to TCP, which is the default transport layer protocol for SIMCO. The specific requirements for SIMCO when using SCTP instead of TCP are specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kiesel-midcom-simco-sctp-02.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-kiesel-midcom-simco-sctp-02.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-kiesel-midcom-simco-sctp-02.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. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ----- End forwarded message ----- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom