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

[Pyda Srisuresh <[e-mail]>]

Magnus,

Please see my comments below inline.

regards,
suresh

--- Magnus Westerlund <[e-mail]> wrote:

> 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.
> 
[suresh] The midcomGroupTable entries are created implicitly when rules are
created in the RuleTable. So, it is only natural that the lifetime of a group
entry match the largest (not the smallest) lifetime of the memeber entries.
Now, if the midcom client chooses to reduce the timing for the rules beloning
to a group, the group entry provides a shortcut to set the ceiling on lifetime
for all member entries. Hope this helps.

> > 
> >> 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."
> 
[suresh] The firewall table is per-port specific. So, the "all" would be right
when the FirewallIndex is 0. Would the following rewording work for you.

    The firewall rule group to which all firewall rules for the 
    specified interface of the MIDCOM server are assigned. When 
    midcomConfigFirewallIndex is set to 0, all firewall rules
    of the MIDCOM server are assigned the same firewall rule group.

Similarly, the description for midcomConfigFirewallPriority can be changed as
follows.

OLD:
      "The priority assigned to all firewall rules
           of the MIDCOM server."
NEW: 

      "The priority assigned to all firewall rules for the specified
       interface of the MIDCOM server. When midcomConfigFirewallIndex
       is set to 0, all firewall rules of the MIDCOM server are assigned
       the same priority."

regards,
suresh
"
> 
> 
> >>
> >> 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 [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