[midcom] AD evaluation comments on draft-ietf-midcom-mib-07

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 26 July 2006 20:50 UTC

Received: from [] (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 [] (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 ([] 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 ([]) 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 []) 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 ([]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 16:39:07 +0200
Received: from [] ([]) 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 <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird (Windows/20060516)
MIME-Version: 1.0
To: midcom@ietf.org, Pyda Srisuresh <srisuresh@yahoo.com>, Juergen Quittek <quittek@netlab.nec.de>, Martin Stiemerling <stiemerling@netlab.nec.de>
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
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: <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


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.


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
"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."


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