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

[Juergen Quittek <[e-mail]>]

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 [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]



_______________________________________________
midcom mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/midcom