[midcom] Re: AD evaluation comments on draft-ietf-midcom-mib-07
Pyda Srisuresh <srisuresh@yahoo.com> Thu, 27 July 2006 15:46 UTC
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
From: Pyda Srisuresh <srisuresh@yahoo.com>
To: Juergen Quittek <quittek@netlab.nec.de>, Magnus Westerlund <magnus.westerlund@ericsson.com>, midcom@ietf.org, Martin Stiemerling <stiemerling@netlab.nec.de>
In-Reply-To: <A948C73A4E452D02087ECB28@[10.1.1.104]>
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: <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
Thanks, Martin & Juergen. I agree with all the responses below. regards, suresh --- Juergen Quittek <quittek@netlab.nec.de> 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
- [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