Re: AD evaluation comments on draft-ietf-midcom-mib-07

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: [email protected]