[midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 27 July 2006 16:43 UTC
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 <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
References: <44C77E8B.2090509@ericsson.com> <A948C73A4E452D02087ECB28@[10.1.1.104]>
In-Reply-To: <A948C73A4E452D02087ECB28@[10.1.1.104]>
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 <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, 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
- [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