[midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07
Juergen Quittek <quittek@netlab.nec.de> Thu, 27 July 2006 18:27 UTC
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 <quittek@netlab.nec.de>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <C9125AF6718D234E58A9C1E7@[192.168.1.129]>
In-Reply-To: <44C8ED12.3060900@ericsson.com>
References: <44C77E8B.2090509@ericsson.com> <A948C73A4E452D02087ECB28@[10.1.1.104]> <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 <stiemerling@netlab.nec.de>, Pyda Srisuresh <srisuresh@yahoo.com>
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: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=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
- [midcom] AD evaluation comments on draft-ietf-mid… Magnus Westerlund
- [midcom] Re: AD evaluation comments on draft-ietf… Juergen Quittek
- [midcom] Re: AD evaluation comments on draft-ietf… Pyda Srisuresh
- [midcom] Re: AD evaluation comments on draft-ietf… Magnus Westerlund
- [midcom] Re: AD evaluation comments on draft-ietf… Pyda Srisuresh
- [midcom] Re: AD evaluation comments on draft-ietf… Juergen Quittek
- [midcom] Re: AD evaluation comments on draft-ietf… Juergen Quittek
- [midcom] Re: AD evaluation comments on draft-ietf… Magnus Westerlund
- Re: [midcom] Re: AD evaluation comments on draft-… Juergen Quittek