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

Thanks, Martin & Juergen. I agree with all the responses below. 

regards,
suresh

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