From midcom-bounces@ietf.org Wed Jul 26 16:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qKj-0006uP-Ae; Wed, 26 Jul 2006 16:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qKi-0006sm-GL for midcom@ietf.org; Wed, 26 Jul 2006 16:50:20 -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 1G5kcx-0007Fd-HH for midcom@ietf.org; Wed, 26 Jul 2006 10:44:47 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5kYq-0001L1-Me for midcom@ietf.org; Wed, 26 Jul 2006 10:40:36 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 432626E0001; Wed, 26 Jul 2006 16:39:08 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 16:39:07 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 16:39:07 +0200 Message-ID: <44C77E8B.2090509@ericsson.com> Date: Wed, 26 Jul 2006 16:39:07 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: midcom@ietf.org, Pyda Srisuresh , Juergen Quittek , Martin Stiemerling Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2006 14:39:07.0305 (UTC) FILETIME=[3FD9C190:01C6B0C1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: [midcom] AD evaluation comments on draft-ietf-midcom-mib-07 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, I have reviewed the draft and do have a few comments. Please answer my questions and I think the draft will benefit from a smaller update. I will start my vacation on Monday so I hope we can resolve things this week. 1. midcomGroupLifetime: I wonder why this object is defined as providing the longest time until something expires. Would not the MIDCOM client be more interested in the shortest time until something in the group expires? 2. Section 5.2.1: " The second object indicates whether or not the middlebox capabilities described by midcomConfigIfBits are available or not available at the indexed IP interface." I think this refer to "midcomConfigIfEnabled" however the description does not match the declaration. 3. Section 7.3, first bullet: How does the MIDCOM client determine which midcomGroupIndex that are unused if it wants to create a new group? 4. Section 9: midcomRulePortRange: What if one like to create a rule with a larger range of ports than a single one or two. I have seen at least some applications that uses port ranges. They are also not dependent on the even odd rule. Because of this I ask if there wouldn't make sense to allow larger ranges. I haven't analyzed if that would have impact on other things. As I see the alternative is to try to reserve the complete range using single or pairs? 5. midcomRuleInternalIpAddr, midcomRuleExternalIpAddr, midcomRuleInsideIpAddr and midcomRuleOutsideIpAddr: I think the descriptions should include the A0-A3 designation of what addresses one is discussing. Because the current definitions are not particular clear on what address one refers to. 6. midcomRuleInternalIpAddr and midcomRuleInternalIpPrefixLength: The wildcarding of the addresses does not seem 100% to me. You can use the prefix length to wildcard an address. However the support is optional. So what happens when one like to wildcard or not specify an address because one can't or it does not make sense? Especially for the outsideIpAddr that the MIDCOM client may not know and is actually requesting the MIDCOM server to assign? 7. midcomConfigFirewallGroupId: I don't understand what scope and effect this object has. It is not clear if it can be used to reassign rules or if only rules created after the value takes effect. In fact I have some problem seeing what it is used for at all with the definition it has. Nits: 1. Page 10, last paragraph: "The manager polls status information at the SNMP agent using SNMP get transactions until it detects the end of the processing the request." This sentence is missing an "of" before "the request". 2. Section 4.2.4.3: "Potentially, the monitoring transactions Policy Rule List (PRL), Policy Rule Status (PRS) Group List (GL) and Group Status (GS) are not atomic, because these transactions may be implemented by more than one SNMP get operations." Seem to be missing a comma after (PRS). 3. Section 9, midcomRulePortRange: "Requesting the a consecutive pair of port numbers is required for supporting the RTP and RTCP protocols, see RFC1889." I would like to change this to: "Requesting a consecutive pair of port numbers may be used by RTP [RFC3550] and may even be required to support older RTP applications." 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 Thu Jul 27 11:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67eT-0002A6-2M; Thu, 27 Jul 2006 11:19:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67eS-0002A1-2u for midcom@ietf.org; Thu, 27 Jul 2006 11:19:52 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G67eQ-0000Zb-C5 for midcom@ietf.org; Thu, 27 Jul 2006 11:19:52 -0400 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id DCC101BAC4D; Thu, 27 Jul 2006 17:03:41 +0200 (CEST) Date: Thu, 27 Jul 2006 17:19:46 +0200 From: Juergen Quittek To: Magnus Westerlund , midcom@ietf.org, Pyda Srisuresh , Martin Stiemerling Message-ID: In-Reply-To: <44C77E8B.2090509@ericsson.com> References: <44C77E8B.2090509@ericsson.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: 7698d1420ecbbce1995432e99bb6d1a1 Cc: Subject: [midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07 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 Magnus, Many thanks for the review! Please find replies inline. We can post a new version immediately after agreeing on the changes. Best regards, Martin and Juergen --On 26.07.2006 16:39 Uhr +0200 Magnus Westerlund wrote: > Hi, > > I have reviewed the draft and do have a few comments. > Please answer my questions and I think the draft will benefit > from a smaller update. I will start my vacation on Monday so > I hope we can resolve things this week. > > 1. midcomGroupLifetime: > > I wonder why this object is defined as providing the longest > time until something expires. Would not the MIDCOM client be > more interested in the shortest time until something in the > group expires? Groups in the MIDOCOM MIB only exist conceptually. There are no explicit group instances containing any state beyond the the state contained in members. Please see the DESCRIPTION clause of midcomGroupTable: Entries in this table are created or removed implicitly when entries in the midcomRuleTable are created or removed, respectively. A group entry in this table only exists as long as there are member rules of this group in the midcomRuleTable. Groups are instantiated by instantiating the first member and they are removed by removing the last remaining member. Therefore, the lifetime of the group is the maximum of all member lifetimes. > 2. Section 5.2.1: > " The second object indicates whether or not the middlebox capabilities > described by midcomConfigIfBits are available or not available at the > indexed IP interface." > > I think this refer to "midcomConfigIfEnabled" however the description > does not match the declaration. We suggest clarifying this sentence by replacing OLD: The second object indicates whether or not the middlebox capabilities with NEW: The second object called midcomConfigIfEnabled indicates whether or not the middlebox capabilities The DESCRIPTION clause of object midcomConfigIfEnabled in the MIB module needs fixing: replace OLD: "The value of this object indicates the availability of the middlebox service described by midcomCapabilitiesBits at the indexed IP interface. with NEW: "The value of this object indicates the availability of the middlebox service described by midcomConfigIfBits at the indexed IP interface. > 3. Section 7.3, first bullet: How does the MIDCOM client determine > which midcomGroupIndex that are unused if it wants to create a new group? A group is identified by the combination of midcomRuleOwner and midcomGroupIndex. Every client can maintain its own group name space indepenedent of others clients, except they act at the same midcomRuleOwner, which the document recommends only for fail-overs and other particular cases. If, for example after a failover, the client does not know which groups do already exist, it may browse the group table. > 4. Section 9: midcomRulePortRange: > > What if one like to create a rule with a larger range of ports than a single > one or two. I have seen at least some applications that uses port ranges. > They are also not dependent on the even odd rule. Because of this I ask > if there wouldn't make sense to allow larger ranges. I haven't analyzed > if that would have impact on other things. As I see the alternative is to > try to reserve the complete range using single or pairs? Initially, we allowed ranges of arbitrary sizes. But then usefulness of this was questioned in the working group. The only use case the WG identified where dynamic configuration of a port range larger than 1 is required was the RTP/RTCP case. All other applications requesting port ranges usually do so because of lack of dynamic configuration means. For instance, for a FTP server port ranges for incoming data connections are solely defined, because the server cannot instruct the firewall on a per FTP-session base to open pinholes. This is not a problem for the MIDCOM MIB. Finally, because it was not covered by the MIDCOM requirements in RFC 3304, the WG agreed on just supporting single ports and port pairs. > 5. midcomRuleInternalIpAddr, midcomRuleExternalIpAddr, midcomRuleInsideIpAddr > and midcomRuleOutsideIpAddr: > > I think the descriptions should include the A0-A3 designation of what > addresses one is discussing. Because the current definitions are not > particular clear on what address one refers to. OK. For the DESCRIPTION clause of object midcomRuleInternalIpAddr replace OLD: "The internal IP address. with NEW: "The internal IP address (A0). For the DESCRIPTION clause of object midcomRuleExternalIpAddr replace OLD: "The external IP address. with NEW: "The external IP address (A3). For the DESCRIPTION clause of object midcomRuleInsideIpAddr replace OLD: "The inside IP address at the middlebox. with NEW: "The inside IP address at the middlebox (A1). For the DESCRIPTION clause of object midcomRuleOutsideIpAddr replace OLD: "The outside IP address at the middlebox. with NEW: "The outside IP address at the middlebox (A2). > 6. midcomRuleInternalIpAddr and midcomRuleInternalIpPrefixLength: > > The wildcarding of the addresses does not seem 100% to me. > You can use the prefix length to wildcard an address. However the > support is optional. So what happens when one like to wildcard or > not specify an address because one can't or it does not make > sense? Especially for the outsideIpAddr that the MIDCOM client may > not know and is actually requesting the MIDCOM server to assign? insideIpAddr and outSideIpAddr are read-only. They are not among the input parameters listed in the DESCRIPTION clause of object midcomRuleAdminStatus. Both are output parameters of client request and their values are assigned by the middlebox. > 7. midcomConfigFirewallGroupId: I don't understand what scope and > effect this object has. It is not clear if it can be used to > reassign rules or if only rules created after the value takes effect. > In fact I have some problem seeing what it is used for > at all with the definition it has. The midcomConfigFirewallGroupId defines to which firewall rule group the MIDCOM rules are added. Some firewalls support grouping of rules into sets/groups. This allows easier reading of rule sets. See, for instance, groups o sets in ipf or IPFW on FreeBSD. > > Nits: > > 1. Page 10, last paragraph: > "The manager polls status > information at the SNMP agent using SNMP get transactions until it > detects the end of the processing the request." > > This sentence is missing an "of" before "the request". fixed. > 2. Section 4.2.4.3: > "Potentially, the monitoring transactions Policy Rule List (PRL), > Policy Rule Status (PRS) Group List (GL) and Group Status (GS) are > not atomic, because these transactions may be implemented by more > than one SNMP get operations." > > Seem to be missing a comma after (PRS). fixed. > 3. Section 9, midcomRulePortRange: > "Requesting the a consecutive pair of port numbers > is required for supporting the RTP and RTCP protocols, > see RFC1889." > > I would like to change this to: > "Requesting a consecutive pair of port numbers may be used by RTP > [RFC3550] and may even be required to support older RTP applications." done. > > 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 Thu Jul 27 11:46:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6847-0007lj-Iu; Thu, 27 Jul 2006 11:46:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6846-0007l3-5a for midcom@ietf.org; Thu, 27 Jul 2006 11:46:22 -0400 Received: from web33312.mail.mud.yahoo.com ([68.142.206.127]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6845-0002N0-It for midcom@ietf.org; Thu, 27 Jul 2006 11:46:22 -0400 Received: (qmail 3886 invoked by uid 60001); 27 Jul 2006 15:46:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nvPeQo9gqpOcTlLslzceHPkMktAqvdQFuPDWHdqe8GZ4I4GhekW+QRtFTGNoXHonUjQ4xEPLFJg9Gr/yB5EmkVc0VhFMuM64D9Zl3vFQdiz9mhefoGSdAo7rjVM02QvHOnPfxdZMPifFKxfuvKCKu9Vf3YnkpkXxP5zR35H5Y3Y= ; Message-ID: <20060727154621.3884.qmail@web33312.mail.mud.yahoo.com> Received: from [69.236.100.67] by web33312.mail.mud.yahoo.com via HTTP; Thu, 27 Jul 2006 08:46:20 PDT Date: Thu, 27 Jul 2006 08:46:20 -0700 (PDT) From: Pyda Srisuresh To: Juergen Quittek , Magnus Westerlund , midcom@ietf.org, Martin Stiemerling 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: dd7e0c3fd18d19cffdd4de99a114001d Cc: Subject: [midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07 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 Thanks, Martin & Juergen. I agree with all the responses below. regards, suresh --- Juergen Quittek wrote: > Hi Magnus, > > Many thanks for the review! > > Please find replies inline. > We can post a new version immediately after agreeing on the changes. > > Best regards, > > Martin and Juergen > > > --On 26.07.2006 16:39 Uhr +0200 Magnus Westerlund wrote: > > > Hi, > > > > I have reviewed the draft and do have a few comments. > > Please answer my questions and I think the draft will benefit > > from a smaller update. I will start my vacation on Monday so > > I hope we can resolve things this week. > > > > 1. midcomGroupLifetime: > > > > I wonder why this object is defined as providing the longest > > time until something expires. Would not the MIDCOM client be > > more interested in the shortest time until something in the > > group expires? > > Groups in the MIDOCOM MIB only exist conceptually. > There are no explicit group instances containing any state > beyond the the state contained in members. > > Please see the DESCRIPTION clause of midcomGroupTable: > > Entries in this table are created or removed > implicitly when entries in the midcomRuleTable are > created or removed, respectively. A group entry > in this table only exists as long as there are > member rules of this group in the midcomRuleTable. > > Groups are instantiated by instantiating the first member > and they are removed by removing the last remaining member. > Therefore, the lifetime of the group is the maximum of all member > lifetimes. > > > > 2. Section 5.2.1: > > " The second object indicates whether or not the middlebox capabilities > > described by midcomConfigIfBits are available or not available at the > > indexed IP interface." > > > > I think this refer to "midcomConfigIfEnabled" however the description > > does not match the declaration. > > We suggest clarifying this sentence by replacing > > OLD: > > The second object indicates whether or not the middlebox capabilities > > with NEW: > > The second object called midcomConfigIfEnabled indicates whether or not > the middlebox capabilities > > > The DESCRIPTION clause of object midcomConfigIfEnabled > in the MIB module needs fixing: > > replace OLD: > > "The value of this object indicates the availability of > the middlebox service described by midcomCapabilitiesBits > at the indexed IP interface. > > with NEW: > > "The value of this object indicates the availability of > the middlebox service described by midcomConfigIfBits > at the indexed IP interface. > > > > 3. Section 7.3, first bullet: How does the MIDCOM client determine > > which midcomGroupIndex that are unused if it wants to create a new group? > > A group is identified by the combination of midcomRuleOwner and > midcomGroupIndex. > Every client can maintain its own group name space indepenedent of others > clients, except they act at the same midcomRuleOwner, which the document > recommends only for fail-overs and other particular cases. > > If, for example after a failover, the client does not know which groups > do already exist, it may browse the group table. > > > > 4. Section 9: midcomRulePortRange: > > > > What if one like to create a rule with a larger range of ports than a > single > > one or two. I have seen at least some applications that uses port ranges. > > They are also not dependent on the even odd rule. Because of this I ask > > if there wouldn't make sense to allow larger ranges. I haven't analyzed > > if that would have impact on other things. As I see the alternative is to > > try to reserve the complete range using single or pairs? > > Initially, we allowed ranges of arbitrary sizes. But then usefulness > of this was questioned in the working group. The only use case the WG > identified where dynamic configuration of a port range larger than 1 > is required was the RTP/RTCP case. All other applications requesting port > ranges usually do so because of lack of dynamic configuration means. > For instance, for a FTP server port ranges for incoming data connections > are solely defined, because the server cannot instruct the firewall > on a per FTP-session base to open pinholes. > This is not a problem for the MIDCOM MIB. > > Finally, because it was not covered by the MIDCOM requirements in RFC > 3304, the WG agreed on just supporting single ports and port pairs. > > > 5. midcomRuleInternalIpAddr, midcomRuleExternalIpAddr, > midcomRuleInsideIpAddr > > and midcomRuleOutsideIpAddr: > > > > I think the descriptions should include the A0-A3 designation of what > > addresses one is discussing. Because the current definitions are not > > particular clear on what address one refers to. > > OK. For the DESCRIPTION clause of object midcomRuleInternalIpAddr > > replace OLD: > > "The internal IP address. > > with NEW: > > "The internal IP address (A0). > > > For the DESCRIPTION clause of object midcomRuleExternalIpAddr > > replace OLD: > > "The external IP address. > > with NEW: > > "The external IP address (A3). > > > For the DESCRIPTION clause of object midcomRuleInsideIpAddr > > replace OLD: > > "The inside IP address at the middlebox. > > with NEW: > > "The inside IP address at the middlebox (A1). > > > For the DESCRIPTION clause of object midcomRuleOutsideIpAddr > > replace OLD: > > "The outside IP address at the middlebox. > > with NEW: > > "The outside IP address at the middlebox (A2). > > > > 6. midcomRuleInternalIpAddr and midcomRuleInternalIpPrefixLength: > > > > The wildcarding of the addresses does not seem 100% to me. > > You can use the prefix length to wildcard an address. However the > > support is optional. So what happens when one like to wildcard or > > not specify an address because one can't or it does not make > > sense? Especially for the outsideIpAddr that the MIDCOM client may > > not know and is actually requesting the MIDCOM server to assign? > > insideIpAddr and outSideIpAddr are read-only. They are not among > the input parameters listed in the DESCRIPTION clause of object > midcomRuleAdminStatus. Both are output parameters of client request > and their values are assigned by the middlebox. > > > 7. midcomConfigFirewallGroupId: I don't understand what scope and > > effect this object has. It is not clear if it can be used to > > reassign rules or if only rules created after the value takes effect. > > In fact I have some problem seeing what it is used for > > at all with the definition it has. > > The midcomConfigFirewallGroupId defines to which firewall rule group > the MIDCOM rules are added. Some firewalls support grouping of rules > into sets/groups. This allows easier reading of rule sets. See, for > instance, groups o sets in ipf or IPFW on FreeBSD. > > > > > Nits: > > > > 1. Page 10, last paragraph: > > "The manager polls status > > information at the SNMP agent using SNMP get transactions until it > > detects the end of the processing the request." > > > > This sentence is missing an "of" before "the request". > > fixed. > > > 2. Section 4.2.4.3: > > "Potentially, the monitoring transactions Policy Rule List (PRL), > > Policy Rule Status (PRS) Group List (GL) and Group Status (GS) are > > not atomic, because these transactions may be implemented by more > > than one SNMP get operations." > > > > Seem to be missing a comma after (PRS). > > fixed. > > > 3. Section 9, midcomRulePortRange: > > "Requesting the a consecutive pair of port numbers > > is required for supporting the RTP and RTCP protocols, > > see RFC1889." > > > > I would like to change this to: > > "Requesting a consecutive pair of port numbers may be used by RTP > > [RFC3550] and may even be required to support older RTP applications." > > done. > > > > > 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 Thu Jul 27 12:43:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68ww-0002aD-7T; Thu, 27 Jul 2006 12:43:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68wv-0002a8-C4 for midcom@ietf.org; Thu, 27 Jul 2006 12:43:01 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G68wu-0007AU-9e for midcom@ietf.org; Thu, 27 Jul 2006 12:43:01 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7AAA04F00FE; Thu, 27 Jul 2006 18:42:59 +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, 27 Jul 2006 18:42:59 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 18:42:58 +0200 Message-ID: <44C8ED12.3060900@ericsson.com> Date: Thu, 27 Jul 2006 18:42:58 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juergen Quittek References: <44C77E8B.2090509@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 16:42:58.0773 (UTC) FILETIME=[B7C38850:01C6B19B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: midcom@ietf.org, Martin Stiemerling , Pyda Srisuresh Subject: [midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07 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, Thanks for the quick reply. I do have some follow up below. When these have been resolved please submit a new document. Then I should be able to put it on IETF last call so it will be ready to go to IESG when I am back from my vacation. Juergen Quittek wrote: >> >> 1. midcomGroupLifetime: >> >> I wonder why this object is defined as providing the longest >> time until something expires. Would not the MIDCOM client be >> more interested in the shortest time until something in the >> group expires? > > Groups in the MIDOCOM MIB only exist conceptually. > There are no explicit group instances containing any state > beyond the the state contained in members. > > Please see the DESCRIPTION clause of midcomGroupTable: > > Entries in this table are created or removed > implicitly when entries in the midcomRuleTable are > created or removed, respectively. A group entry > in this table only exists as long as there are > member rules of this group in the midcomRuleTable. > > Groups are instantiated by instantiating the first member > and they are removed by removing the last remaining member. > Therefore, the lifetime of the group is the maximum of all member > lifetimes. > Yes, you are correct that the groups lifetime is the maximum of the included rules. However from a usability point of view it seems that the minimum would be better. However if the WG thinks this is fine, then I will not persist with my point of view. > >> 2. Section 5.2.1: >> " The second object indicates whether or not the middlebox capabilities >> described by midcomConfigIfBits are available or not available at the >> indexed IP interface." >> >> I think this refer to "midcomConfigIfEnabled" however the description >> does not match the declaration. > > We suggest clarifying this sentence by replacing > > OLD: > > The second object indicates whether or not the middlebox capabilities > > with NEW: > > The second object called midcomConfigIfEnabled indicates whether or > not the middlebox capabilities > > > The DESCRIPTION clause of object midcomConfigIfEnabled > in the MIB module needs fixing: > > replace OLD: > > "The value of this object indicates the availability of > the middlebox service described by midcomCapabilitiesBits > at the indexed IP interface. > > with NEW: > > "The value of this object indicates the availability of > the middlebox service described by midcomConfigIfBits > at the indexed IP interface. > Thanks, seems good. > >> 3. Section 7.3, first bullet: How does the MIDCOM client determine >> which midcomGroupIndex that are unused if it wants to create a new group? > > A group is identified by the combination of midcomRuleOwner and > midcomGroupIndex. > Every client can maintain its own group name space indepenedent of others > clients, except they act at the same midcomRuleOwner, which the document > recommends only for fail-overs and other particular cases. > > If, for example after a failover, the client does not know which groups > do already exist, it may browse the group table. Okay, that is true. I would have preferred some clarification on this. > > >> 4. Section 9: midcomRulePortRange: >> >> What if one like to create a rule with a larger range of ports than a >> single >> one or two. I have seen at least some applications that uses port ranges. >> They are also not dependent on the even odd rule. Because of this I ask >> if there wouldn't make sense to allow larger ranges. I haven't analyzed >> if that would have impact on other things. As I see the alternative is to >> try to reserve the complete range using single or pairs? > > Initially, we allowed ranges of arbitrary sizes. But then usefulness > of this was questioned in the working group. The only use case the WG > identified where dynamic configuration of a port range larger than 1 > is required was the RTP/RTCP case. All other applications requesting port > ranges usually do so because of lack of dynamic configuration means. > For instance, for a FTP server port ranges for incoming data connections > are solely defined, because the server cannot instruct the firewall > on a per FTP-session base to open pinholes. > This is not a problem for the MIDCOM MIB. > > Finally, because it was not covered by the MIDCOM requirements in RFC > 3304, the WG agreed on just supporting single ports and port pairs. Sure, I am fine without any changes on this. There are ways around the problem. > >> 5. midcomRuleInternalIpAddr, midcomRuleExternalIpAddr, >> midcomRuleInsideIpAddr >> and midcomRuleOutsideIpAddr: >> >> I think the descriptions should include the A0-A3 designation of what >> addresses one is discussing. Because the current definitions are not >> particular clear on what address one refers to. > > OK. For the DESCRIPTION clause of object midcomRuleInternalIpAddr > > replace OLD: > > "The internal IP address. > > with NEW: > > "The internal IP address (A0). > > > For the DESCRIPTION clause of object midcomRuleExternalIpAddr > > replace OLD: > > "The external IP address. > > with NEW: > > "The external IP address (A3). > > > For the DESCRIPTION clause of object midcomRuleInsideIpAddr > > replace OLD: > > "The inside IP address at the middlebox. > > with NEW: > > "The inside IP address at the middlebox (A1). > > > For the DESCRIPTION clause of object midcomRuleOutsideIpAddr > > replace OLD: > > "The outside IP address at the middlebox. > > with NEW: > > "The outside IP address at the middlebox (A2). > Thanks. > >> 6. midcomRuleInternalIpAddr and midcomRuleInternalIpPrefixLength: >> >> The wildcarding of the addresses does not seem 100% to me. >> You can use the prefix length to wildcard an address. However the >> support is optional. So what happens when one like to wildcard or >> not specify an address because one can't or it does not make >> sense? Especially for the outsideIpAddr that the MIDCOM client may >> not know and is actually requesting the MIDCOM server to assign? > > insideIpAddr and outSideIpAddr are read-only. They are not among > the input parameters listed in the DESCRIPTION clause of object > midcomRuleAdminStatus. Both are output parameters of client request > and their values are assigned by the middlebox. > Okay, so these are always know entities. Thus not a big problem. Only when defining like firewall rules for whole networks one will have real use for wildcarding. Thanks for the clarification. >> 7. midcomConfigFirewallGroupId: I don't understand what scope and >> effect this object has. It is not clear if it can be used to >> reassign rules or if only rules created after the value takes effect. >> In fact I have some problem seeing what it is used for >> at all with the definition it has. > > The midcomConfigFirewallGroupId defines to which firewall rule group > the MIDCOM rules are added. Some firewalls support grouping of rules > into sets/groups. This allows easier reading of rule sets. See, for > instance, groups o sets in ipf or IPFW on FreeBSD. > Okay, however is really the "all" part of the below description correct then? "The firewall rule group to which all firewall rules of the MIDCOM server are assigned." >> >> Nits: >> >> 1. Page 10, last paragraph: >> "The manager polls status >> information at the SNMP agent using SNMP get transactions until it >> detects the end of the processing the request." >> >> This sentence is missing an "of" before "the request". > > fixed. > >> 2. Section 4.2.4.3: >> "Potentially, the monitoring transactions Policy Rule List (PRL), >> Policy Rule Status (PRS) Group List (GL) and Group Status (GS) are >> not atomic, because these transactions may be implemented by more >> than one SNMP get operations." >> >> Seem to be missing a comma after (PRS). > > fixed. > >> 3. Section 9, midcomRulePortRange: >> "Requesting the a consecutive pair of port numbers >> is required for supporting the RTP and RTCP protocols, >> see RFC1889." >> >> I would like to change this to: >> "Requesting a consecutive pair of port numbers may be used by RTP >> [RFC3550] and may even be required to support older RTP applications." > > done. > Thanks. 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 Thu Jul 27 14:23:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AWG-000233-Vq; Thu, 27 Jul 2006 14:23:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AWF-00022y-QL for midcom@ietf.org; Thu, 27 Jul 2006 14:23:35 -0400 Received: from web33303.mail.mud.yahoo.com ([68.142.206.118]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6AWF-0000XL-4G for midcom@ietf.org; Thu, 27 Jul 2006 14:23:35 -0400 Received: (qmail 76154 invoked by uid 60001); 27 Jul 2006 18:23:34 -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=fDH0oKbxODoqI9ihgPUUtapV2QOriEMvI5LdF5gRxi1WiVCKNInqBW+muhmZrwq6CtL+qM+BIt6dFirRhwwCeCEjhwbEPqosfPJWdh0cSyM2TgN88enyCcoX6vBVodspjIEJS7amFYgNpdcLvotortdJ07imX3/9U88L3oMmBWQ= ; Message-ID: <20060727182334.76152.qmail@web33303.mail.mud.yahoo.com> Received: from [69.236.100.67] by web33303.mail.mud.yahoo.com via HTTP; Thu, 27 Jul 2006 11:23:34 PDT Date: Thu, 27 Jul 2006 11:23:34 -0700 (PDT) From: Pyda Srisuresh To: Magnus Westerlund , Juergen Quittek In-Reply-To: <44C8ED12.3060900@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: 52f402fbded34a6df606921f56b8bdd8 Cc: midcom@ietf.org, Martin Stiemerling , Pyda Srisuresh Subject: [midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07 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 Magnus, Please see my comments below inline. regards, suresh --- Magnus Westerlund wrote: > Hi, > > Thanks for the quick reply. I do have some follow up below. When these > have been resolved please submit a new document. Then I should be able > to put it on IETF last call so it will be ready to go to IESG when I am > back from my vacation. > > > Juergen Quittek wrote: > >> > >> 1. midcomGroupLifetime: > >> > >> I wonder why this object is defined as providing the longest > >> time until something expires. Would not the MIDCOM client be > >> more interested in the shortest time until something in the > >> group expires? > > > > Groups in the MIDOCOM MIB only exist conceptually. > > There are no explicit group instances containing any state > > beyond the the state contained in members. > > > > Please see the DESCRIPTION clause of midcomGroupTable: > > > > Entries in this table are created or removed > > implicitly when entries in the midcomRuleTable are > > created or removed, respectively. A group entry > > in this table only exists as long as there are > > member rules of this group in the midcomRuleTable. > > > > Groups are instantiated by instantiating the first member > > and they are removed by removing the last remaining member. > > Therefore, the lifetime of the group is the maximum of all member > > lifetimes. > > > > Yes, you are correct that the groups lifetime is the maximum of the > included rules. However from a usability point of view it seems that the > minimum would be better. However if the WG thinks this is fine, then I > will not persist with my point of view. > [suresh] The midcomGroupTable entries are created implicitly when rules are created in the RuleTable. So, it is only natural that the lifetime of a group entry match the largest (not the smallest) lifetime of the memeber entries. Now, if the midcom client chooses to reduce the timing for the rules beloning to a group, the group entry provides a shortcut to set the ceiling on lifetime for all member entries. Hope this helps. > > > >> 2. Section 5.2.1: > >> " The second object indicates whether or not the middlebox capabilities > >> described by midcomConfigIfBits are available or not available at the > >> indexed IP interface." > >> > >> I think this refer to "midcomConfigIfEnabled" however the description > >> does not match the declaration. > > > > We suggest clarifying this sentence by replacing > > > > OLD: > > > > The second object indicates whether or not the middlebox capabilities > > > > with NEW: > > > > The second object called midcomConfigIfEnabled indicates whether or > > not the middlebox capabilities > > > > > > The DESCRIPTION clause of object midcomConfigIfEnabled > > in the MIB module needs fixing: > > > > replace OLD: > > > > "The value of this object indicates the availability of > > the middlebox service described by midcomCapabilitiesBits > > at the indexed IP interface. > > > > with NEW: > > > > "The value of this object indicates the availability of > > the middlebox service described by midcomConfigIfBits > > at the indexed IP interface. > > > > Thanks, seems good. > > > > >> 3. Section 7.3, first bullet: How does the MIDCOM client determine > >> which midcomGroupIndex that are unused if it wants to create a new group? > > > > A group is identified by the combination of midcomRuleOwner and > > midcomGroupIndex. > > Every client can maintain its own group name space indepenedent of others > > clients, except they act at the same midcomRuleOwner, which the document > > recommends only for fail-overs and other particular cases. > > > > If, for example after a failover, the client does not know which groups > > do already exist, it may browse the group table. > > Okay, that is true. I would have preferred some clarification on this. > > > > > > >> 4. Section 9: midcomRulePortRange: > >> > >> What if one like to create a rule with a larger range of ports than a > >> single > >> one or two. I have seen at least some applications that uses port ranges. > >> They are also not dependent on the even odd rule. Because of this I ask > >> if there wouldn't make sense to allow larger ranges. I haven't analyzed > >> if that would have impact on other things. As I see the alternative is to > >> try to reserve the complete range using single or pairs? > > > > Initially, we allowed ranges of arbitrary sizes. But then usefulness > > of this was questioned in the working group. The only use case the WG > > identified where dynamic configuration of a port range larger than 1 > > is required was the RTP/RTCP case. All other applications requesting port > > ranges usually do so because of lack of dynamic configuration means. > > For instance, for a FTP server port ranges for incoming data connections > > are solely defined, because the server cannot instruct the firewall > > on a per FTP-session base to open pinholes. > > This is not a problem for the MIDCOM MIB. > > > > Finally, because it was not covered by the MIDCOM requirements in RFC > > 3304, the WG agreed on just supporting single ports and port pairs. > > Sure, I am fine without any changes on this. There are ways around the > problem. > > > > >> 5. midcomRuleInternalIpAddr, midcomRuleExternalIpAddr, > >> midcomRuleInsideIpAddr > >> and midcomRuleOutsideIpAddr: > >> > >> I think the descriptions should include the A0-A3 designation of what > >> addresses one is discussing. Because the current definitions are not > >> particular clear on what address one refers to. > > > > OK. For the DESCRIPTION clause of object midcomRuleInternalIpAddr > > > > replace OLD: > > > > "The internal IP address. > > > > with NEW: > > > > "The internal IP address (A0). > > > > > > For the DESCRIPTION clause of object midcomRuleExternalIpAddr > > > > replace OLD: > > > > "The external IP address. > > > > with NEW: > > > > "The external IP address (A3). > > > > > > For the DESCRIPTION clause of object midcomRuleInsideIpAddr > > > > replace OLD: > > > > "The inside IP address at the middlebox. > > > > with NEW: > > > > "The inside IP address at the middlebox (A1). > > > > > > For the DESCRIPTION clause of object midcomRuleOutsideIpAddr > > > > replace OLD: > > > > "The outside IP address at the middlebox. > > > > with NEW: > > > > "The outside IP address at the middlebox (A2). > > > > Thanks. > > > > >> 6. midcomRuleInternalIpAddr and midcomRuleInternalIpPrefixLength: > >> > >> The wildcarding of the addresses does not seem 100% to me. > >> You can use the prefix length to wildcard an address. However the > >> support is optional. So what happens when one like to wildcard or > >> not specify an address because one can't or it does not make > >> sense? Especially for the outsideIpAddr that the MIDCOM client may > >> not know and is actually requesting the MIDCOM server to assign? > > > > insideIpAddr and outSideIpAddr are read-only. They are not among > > the input parameters listed in the DESCRIPTION clause of object > > midcomRuleAdminStatus. Both are output parameters of client request > > and their values are assigned by the middlebox. > > > > > Okay, so these are always know entities. Thus not a big problem. Only > when defining like firewall rules for whole networks one will have real > use for wildcarding. Thanks for the clarification. > > >> 7. midcomConfigFirewallGroupId: I don't understand what scope and > >> effect this object has. It is not clear if it can be used to > >> reassign rules or if only rules created after the value takes effect. > >> In fact I have some problem seeing what it is used for > >> at all with the definition it has. > > > > The midcomConfigFirewallGroupId defines to which firewall rule group > > the MIDCOM rules are added. Some firewalls support grouping of rules > > into sets/groups. This allows easier reading of rule sets. See, for > > instance, groups o sets in ipf or IPFW on FreeBSD. > > > > Okay, however is really the "all" part of the below description correct > then? > > "The firewall rule group to which all firewall > rules of the MIDCOM server are assigned." > [suresh] The firewall table is per-port specific. So, the "all" would be right when the FirewallIndex is 0. Would the following rewording work for you. The firewall rule group to which all firewall rules for the specified interface of the MIDCOM server are assigned. When midcomConfigFirewallIndex is set to 0, all firewall rules of the MIDCOM server are assigned the same firewall rule group. Similarly, the description for midcomConfigFirewallPriority can be changed as follows. OLD: "The priority assigned to all firewall rules of the MIDCOM server." NEW: "The priority assigned to all firewall rules for the specified interface of the MIDCOM server. When midcomConfigFirewallIndex is set to 0, all firewall rules of the MIDCOM server are assigned the same priority." regards, suresh " > > > >> > >> Nits: > >> > >> 1. Page 10, last paragraph: > >> "The manager polls status > >> information at the SNMP agent using SNMP get transactions until it > >> detects the end of the processing the request." > >> > >> This sentence is missing an "of" before "the request". > > > > fixed. > > > >> 2. Section 4.2.4.3: > >> "Potentially, the monitoring transactions Policy Rule List (PRL), > >> Policy Rule Status (PRS) Group List (GL) and Group Status (GS) are > >> not atomic, because these transactions may be implemented by more > >> than one SNMP get operations." > >> > >> Seem to be missing a comma after (PRS). > > > > fixed. > > > >> 3. Section 9, midcomRulePortRange: > >> "Requesting the a consecutive pair of port numbers > >> is required for supporting the RTP and RTCP protocols, > >> see RFC1889." > >> > >> I would like to change this to: > >> "Requesting a consecutive pair of port numbers may be used by RTP > >> [RFC3550] and may even be required to support older RTP applications." > > > > done. > > > > Thanks. > > 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 Thu Jul 27 14:27:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AaK-00055w-NL; Thu, 27 Jul 2006 14:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AaJ-00055j-II for midcom@ietf.org; Thu, 27 Jul 2006 14:27:47 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AaH-000179-RQ for midcom@ietf.org; Thu, 27 Jul 2006 14:27:47 -0400 Received: from [192.168.1.129] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id DAC6D1BACA4; Thu, 27 Jul 2006 20:11:34 +0200 (CEST) Date: Thu, 27 Jul 2006 20:27:37 +0200 From: Juergen Quittek To: Magnus Westerlund Message-ID: In-Reply-To: <44C8ED12.3060900@ericsson.com> References: <44C77E8B.2090509@ericsson.com> <44C8ED12.3060900@ericsson.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: dd7e0c3fd18d19cffdd4de99a114001d Cc: midcom@ietf.org, Martin Stiemerling , Pyda Srisuresh Subject: [midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07 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 Magnus, --On 27.07.2006 18:42 Uhr +0200 Magnus Westerlund wrote: > Hi, > > Thanks for the quick reply. I do have some follow up below. > When these have been resolved please submit a new document. > Then I should be able to put it on IETF last call so it will > be ready to go to IESG when I am back from my vacation. > > > Juergen Quittek wrote: >>> >>> 1. midcomGroupLifetime: >>> >>> I wonder why this object is defined as providing the longest >>> time until something expires. Would not the MIDCOM client be >>> more interested in the shortest time until something in the >>> group expires? >> >> Groups in the MIDOCOM MIB only exist conceptually. >> There are no explicit group instances containing any state >> beyond the the state contained in members. >> >> Please see the DESCRIPTION clause of midcomGroupTable: >> >> Entries in this table are created or removed >> implicitly when entries in the midcomRuleTable are >> created or removed, respectively. A group entry >> in this table only exists as long as there are >> member rules of this group in the midcomRuleTable. >> >> Groups are instantiated by instantiating the first member >> and they are removed by removing the last remaining member. >> Therefore, the lifetime of the group is the maximum of all member >> lifetimes. >> > > Yes, you are correct that the groups lifetime is the maximum of > the included rules. However from a usability point of view it seems > that the minimum would be better. However if the WG thinks this is > fine, then I will not persist with my point of view. When we discussed this in the WG, there was consensus that groups provide shortcuts to actions on all members. We consider a group to be existent as long as there is a member. Hence, object midcomGroupLifetime contains the (expected) lifetime of the group. I see no problem with adding another object that provides what you suggest, maybe called groupShortestMemberLifetime. But so far, the group has not seen the need for it. >> >>> 2. Section 5.2.1: >>> " The second object indicates whether or not the middlebox capabilities >>> described by midcomConfigIfBits are available or not available at the >>> indexed IP interface." >>> >>> I think this refer to "midcomConfigIfEnabled" however the description >>> does not match the declaration. >> >> We suggest clarifying this sentence by replacing >> >> OLD: >> >> The second object indicates whether or not the middlebox capabilities >> >> with NEW: >> >> The second object called midcomConfigIfEnabled indicates whether or >> not the middlebox capabilities >> >> >> The DESCRIPTION clause of object midcomConfigIfEnabled >> in the MIB module needs fixing: >> >> replace OLD: >> >> "The value of this object indicates the availability of >> the middlebox service described by midcomCapabilitiesBits >> at the indexed IP interface. >> >> with NEW: >> >> "The value of this object indicates the availability of >> the middlebox service described by midcomConfigIfBits >> at the indexed IP interface. >> > > Thanks, seems good. > >> >>> 3. Section 7.3, first bullet: How does the MIDCOM client determine >>> which midcomGroupIndex that are unused if it wants to create a new group? >> >> A group is identified by the combination of midcomRuleOwner and >> midcomGroupIndex. >> Every client can maintain its own group name space indepenedent of others >> clients, except they act at the same midcomRuleOwner, which the document >> recommends only for fail-overs and other particular cases. >> >> If, for example after a failover, the client does not know which groups >> do already exist, it may browse the group table. > > Okay, that is true. I would have preferred some clarification on this. I suggest appending a clarification to the second paragraph of section 5.1.2. "midcomGroupTable": replace OLD: Entries are indexed by the midcomRuleOwner of the rules that belong to the group and by a specific midcomGroupIndex. with NEW: Entries are indexed by the midcomRuleOwner of the rules that belong to the group and by a specific midcomGroupIndex. This allows each midcomRuleOwner to maintain its own independent group name space. >> >> >>> 4. Section 9: midcomRulePortRange: >>> >>> What if one like to create a rule with a larger range of ports than a >>> single >>> one or two. I have seen at least some applications that uses port ranges. >>> They are also not dependent on the even odd rule. Because of this I ask >>> if there wouldn't make sense to allow larger ranges. I haven't analyzed >>> if that would have impact on other things. As I see the alternative is to >>> try to reserve the complete range using single or pairs? >> >> Initially, we allowed ranges of arbitrary sizes. But then usefulness >> of this was questioned in the working group. The only use case the WG >> identified where dynamic configuration of a port range larger than 1 >> is required was the RTP/RTCP case. All other applications requesting port >> ranges usually do so because of lack of dynamic configuration means. >> For instance, for a FTP server port ranges for incoming data connections >> are solely defined, because the server cannot instruct the firewall >> on a per FTP-session base to open pinholes. >> This is not a problem for the MIDCOM MIB. >> >> Finally, because it was not covered by the MIDCOM requirements in RFC >> 3304, the WG agreed on just supporting single ports and port pairs. > > Sure, I am fine without any changes on this. There are ways around the problem. > >> >>> 5. midcomRuleInternalIpAddr, midcomRuleExternalIpAddr, >>> midcomRuleInsideIpAddr >>> and midcomRuleOutsideIpAddr: >>> >>> I think the descriptions should include the A0-A3 designation of what >>> addresses one is discussing. Because the current definitions are not >>> particular clear on what address one refers to. >> >> OK. For the DESCRIPTION clause of object midcomRuleInternalIpAddr >> >> replace OLD: >> >> "The internal IP address. >> >> with NEW: >> >> "The internal IP address (A0). >> >> >> For the DESCRIPTION clause of object midcomRuleExternalIpAddr >> >> replace OLD: >> >> "The external IP address. >> >> with NEW: >> >> "The external IP address (A3). >> >> >> For the DESCRIPTION clause of object midcomRuleInsideIpAddr >> >> replace OLD: >> >> "The inside IP address at the middlebox. >> >> with NEW: >> >> "The inside IP address at the middlebox (A1). >> >> >> For the DESCRIPTION clause of object midcomRuleOutsideIpAddr >> >> replace OLD: >> >> "The outside IP address at the middlebox. >> >> with NEW: >> >> "The outside IP address at the middlebox (A2). >> > > Thanks. > >> >>> 6. midcomRuleInternalIpAddr and midcomRuleInternalIpPrefixLength: >>> >>> The wildcarding of the addresses does not seem 100% to me. >>> You can use the prefix length to wildcard an address. However the >>> support is optional. So what happens when one like to wildcard or >>> not specify an address because one can't or it does not make >>> sense? Especially for the outsideIpAddr that the MIDCOM client may >>> not know and is actually requesting the MIDCOM server to assign? >> >> insideIpAddr and outSideIpAddr are read-only. They are not among >> the input parameters listed in the DESCRIPTION clause of object >> midcomRuleAdminStatus. Both are output parameters of client request >> and their values are assigned by the middlebox. >> > > > Okay, so these are always know entities. Thus not a big problem. > Only when defining like firewall rules for whole networks one will > have real use for wildcarding. Thanks for the clarification. > >>> 7. midcomConfigFirewallGroupId: I don't understand what scope and >>> effect this object has. It is not clear if it can be used to >>> reassign rules or if only rules created after the value takes effect. >>> In fact I have some problem seeing what it is used for >>> at all with the definition it has. >> >> The midcomConfigFirewallGroupId defines to which firewall rule group >> the MIDCOM rules are added. Some firewalls support grouping of rules >> into sets/groups. This allows easier reading of rule sets. See, for >> instance, groups o sets in ipf or IPFW on FreeBSD. >> > > Okay, however is really the "all" part of the below description correct then? > > "The firewall rule group to which all firewall > rules of the MIDCOM server are assigned." I just saw a message from Suresh arriving on this issue. I will reply to his message. Thanks, Juergen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Thu Jul 27 15:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BBp-0006to-Oi; Thu, 27 Jul 2006 15:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BBp-0006tj-3w for midcom@ietf.org; Thu, 27 Jul 2006 15:06:33 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BBm-0004ms-Ga for midcom@ietf.org; Thu, 27 Jul 2006 15:06:33 -0400 Received: from [192.168.1.129] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 7FE7A1BACA4; Thu, 27 Jul 2006 20:50:20 +0200 (CEST) Date: Thu, 27 Jul 2006 21:06:25 +0200 From: Juergen Quittek To: Pyda Srisuresh , Magnus Westerlund Message-ID: <4CC6A3D0C6702AA36AF66BA9@[192.168.1.129]> In-Reply-To: <20060727182334.76152.qmail@web33303.mail.mud.yahoo.com> References: <20060727182334.76152.qmail@web33303.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: 2beba50d0fcdeee5f091c59f204d4365 Cc: midcom@ietf.org, Martin Stiemerling Subject: [midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07 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 Magnus and Suresh, --On 27.07.2006 11:23 Uhr -0700 Pyda Srisuresh wrote: > Magnus, > > Please see my comments below inline. > > regards, > suresh > > --- Magnus Westerlund wrote: > >> Hi, >> >> Thanks for the quick reply. I do have some follow up below. When these >> have been resolved please submit a new document. Then I should be able >> to put it on IETF last call so it will be ready to go to IESG when I am >> back from my vacation. [...] >> >> 7. midcomConfigFirewallGroupId: I don't understand what scope and >> >> effect this object has. It is not clear if it can be used to >> >> reassign rules or if only rules created after the value takes effect. >> >> In fact I have some problem seeing what it is used for >> >> at all with the definition it has. >> > >> > The midcomConfigFirewallGroupId defines to which firewall rule group >> > the MIDCOM rules are added. Some firewalls support grouping of rules >> > into sets/groups. This allows easier reading of rule sets. See, for >> > instance, groups o sets in ipf or IPFW on FreeBSD. >> > >> >> Okay, however is really the "all" part of the below description correct >> then? The text is not really precise here. As Suresh explains below, all firewall rules for a particular interface are assigned to the same firewall group. However, for different interfaces the groups may be different. >> "The firewall rule group to which all firewall >> rules of the MIDCOM server are assigned." >> > [suresh] The firewall table is per-port specific. So, the "all" would be right > when the FirewallIndex is 0. Would the following rewording work for you. > > The firewall rule group to which all firewall rules for the > specified interface of the MIDCOM server are assigned. When > midcomConfigFirewallIndex is set to 0, all firewall rules > of the MIDCOM server are assigned the same firewall rule group. This text is better, but still not fully correct. Even if there is an entry with index 0, then there still may be entries for other interfaces as indicted in the DESCRIPTION clause of midcomConfigFirewallTable: % The table is indexed by the object midcomConfigFirewallIndex. % For indexing a single interface, this object contains the % value of the ifIndex object that is associated with the % interface. If an entry with midcomIfIndex = 0 occurs, then % bits set in objects of this entry apply to all interfaces % for which there is no entry in this table for the % interface's index." Consequently, we should state: NEW The firewall rule group to which all firewall rules are assigned that the MIDCOM server creates for the interface indicated by object midcomConfigFirewallIndex. If the value of object midcomConfigFirewallIndex is 0, then all firewall rules of the MIDCOM server that are created for interfaces with no specific entry in the midcomConfigFirewallTable are assigned to the firewall rule group indicated by the value of this object. Not forgetting to fix the mistake in the DESCRIPTION clause of the midcomConfigFirewallTable: OLD: interface. If an entry with midcomIfIndex = 0 occurs, then NEW: interface. If an entry with midcomConfigFirewallIndex = 0 occurs, then > Similarly, the description for midcomConfigFirewallPriority can be changed as > follows. > > OLD: > "The priority assigned to all firewall rules > of the MIDCOM server." > NEW: > > "The priority assigned to all firewall rules for the specified > interface of the MIDCOM server. When midcomConfigFirewallIndex > is set to 0, all firewall rules of the MIDCOM server are assigned > the same priority." Similarly, this text should be something like NEW The priority assigned to all firewall rules that the MIDCOM server creates for the interface indicated by object midcomConfigFirewallIndex. If the value of object midcomConfigFirewallIndex is 0, then this priority is assigned to all firewall rules of the MIDCOM server that are created for interfaces for which there is no specific entry in the midcomConfigFirewallTable. Finally, I fixed another small mistake to be fixed in the DESCRIPTION clause of object midcomConfigIfTable: OLD: The table is indexed by the object midcomIfIndex. NEW: The table is indexed by the object midcomConfigIfIndex. OLD: midcomIfIndex = 0 occurs, then bits set in objects NEW: midcomConfigIfIndex = 0 occurs, then bits set in objects Thanks, Juergen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Fri Jul 28 03:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6N7e-0000zL-8a; Fri, 28 Jul 2006 03:51:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6N7c-0000zG-DK for midcom@ietf.org; Fri, 28 Jul 2006 03:51:00 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6N7Y-0002RZ-NV for midcom@ietf.org; Fri, 28 Jul 2006 03:51:00 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1738E6E0002; Fri, 28 Jul 2006 09:50:56 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 09:50:55 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 09:50:54 +0200 Message-ID: <44C9C1DE.4090404@ericsson.com> Date: Fri, 28 Jul 2006 09:50:54 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juergen Quittek References: <44C77E8B.2090509@ericsson.com> <44C8ED12.3060900@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2006 07:50:54.0464 (UTC) FILETIME=[8DCE5000:01C6B21A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: midcom@ietf.org, Martin Stiemerling , Pyda Srisuresh Subject: [midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07 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 Juergen Quittek wrote: > Hi Magnus, > > --On 27.07.2006 18:42 Uhr +0200 Magnus Westerlund wrote: > >> Hi, >> >> Thanks for the quick reply. I do have some follow up below. >> When these have been resolved please submit a new document. >> Then I should be able to put it on IETF last call so it will >> be ready to go to IESG when I am back from my vacation. >> >> >> Juergen Quittek wrote: >>>> >>>> 1. midcomGroupLifetime: >>>> >>>> I wonder why this object is defined as providing the longest >>>> time until something expires. Would not the MIDCOM client be >>>> more interested in the shortest time until something in the >>>> group expires? >>> >>> Groups in the MIDOCOM MIB only exist conceptually. >>> There are no explicit group instances containing any state >>> beyond the the state contained in members. >>> >>> Please see the DESCRIPTION clause of midcomGroupTable: >>> >>> Entries in this table are created or removed >>> implicitly when entries in the midcomRuleTable are >>> created or removed, respectively. A group entry >>> in this table only exists as long as there are >>> member rules of this group in the midcomRuleTable. >>> >>> Groups are instantiated by instantiating the first member >>> and they are removed by removing the last remaining member. >>> Therefore, the lifetime of the group is the maximum of all member >>> lifetimes. >>> >> >> Yes, you are correct that the groups lifetime is the maximum of >> the included rules. However from a usability point of view it seems >> that the minimum would be better. However if the WG thinks this is >> fine, then I will not persist with my point of view. > > When we discussed this in the WG, there was consensus that > groups provide shortcuts to actions on all members. > > We consider a group to be existent as long as there is a member. > Hence, object midcomGroupLifetime contains the (expected) lifetime > of the group. > > I see no problem with adding another object that provides what > you suggest, maybe called groupShortestMemberLifetime. > But so far, the group has not seen the need for it. > Okay, lets leave things as they are. I think my case is in most cases not relevant as it will be the MIDCOM client that has created the group and can easily keep track of the shortest itself. And in extreme cases when it doesn't have this state it can easily either retrieve it or set the midcomGroupLifetime to be certain that all rules in the group has the same lifetime. I am fine with the other changes you propose. Please submit a new draft with these changes. Thanks 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 Fri Jul 28 14:04:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Wgf-0003aJ-N9; Fri, 28 Jul 2006 14:03:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Wgd-0003a7-S5 for midcom@ietf.org; Fri, 28 Jul 2006 14:03:47 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Wgb-0003Vp-Hr for midcom@ietf.org; Fri, 28 Jul 2006 14:03:47 -0400 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2547A1BAC4D; Fri, 28 Jul 2006 19:47:29 +0200 (CEST) Date: Fri, 28 Jul 2006 20:03:40 +0200 From: Juergen Quittek To: Magnus Westerlund Subject: Re: [midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07 Message-ID: <43AECB067806D99DAEE598A5@[192.168.1.128]> In-Reply-To: <44C9C1DE.4090404@ericsson.com> References: <44C77E8B.2090509@ericsson.com> <44C8ED12.3060900@ericsson.com> <44C9C1DE.4090404@ericsson.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: 7655788c23eb79e336f5f8ba8bce7906 Cc: midcom@ietf.org, Juergen Schoenwaelder 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 Magnus, --On 28.07.2006 9:50 Uhr +0200 Magnus Westerlund wrote: [...] > I am fine with the other changes you propose. Please submit a new draft with these changes. Just submitted it. You can preview it at . Please find a diff to version -07 at . 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom