[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