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

Juergen Quittek <quittek@netlab.nec.de> Thu, 27 July 2006 19:06 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BBp-0006to-Oi; Thu, 27 Jul 2006 15:06:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BBp-0006tj-3w for midcom@ietf.org; Thu, 27 Jul 2006 15:06:33 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BBm-0004ms-Ga for midcom@ietf.org; Thu, 27 Jul 2006 15:06:33 -0400
Received: from [192.168.1.129] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 7FE7A1BACA4; Thu, 27 Jul 2006 20:50:20 +0200 (CEST)
Date: Thu, 27 Jul 2006 21:06:25 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
To: Pyda Srisuresh <srisuresh@yahoo.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <4CC6A3D0C6702AA36AF66BA9@[192.168.1.129]>
In-Reply-To: <20060727182334.76152.qmail@web33303.mail.mud.yahoo.com>
References: <20060727182334.76152.qmail@web33303.mail.mud.yahoo.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: midcom@ietf.org, Martin Stiemerling <stiemerling@netlab.nec.de>
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 Magnus and Suresh,

--On 27.07.2006 11:23 Uhr -0700 Pyda Srisuresh wrote:

> Magnus,
>
> Please see my comments below inline.
>
> regards,
> suresh
>
> --- Magnus Westerlund <magnus.westerlund@ericsson.com> 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.

 [...]

>> >> 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 text is not really precise here. As Suresh explains below, all
firewall rules for a particular interface are assigned to the same
firewall group.  However, for different interfaces the groups may
be different.

>> "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.

This text is better, but still not fully correct.
Even if there is an entry with index 0, then there still may
be entries for other interfaces as indicted in the DESCRIPTION clause
of midcomConfigFirewallTable:

%        The table is indexed by the object midcomConfigFirewallIndex.
%        For indexing a single interface, this object contains the
%        value of the ifIndex object that is associated with the
%        interface.  If an entry with midcomIfIndex = 0 occurs, then
%        bits set in objects of this entry apply to all interfaces
%        for which there is no entry in this table for the
%        interface's index."

Consequently, we should state:

NEW

    The firewall rule group to which all firewall rules are assigned
    that the MIDCOM server creates for the interface indicated by
    object midcomConfigFirewallIndex. If the value of object
    midcomConfigFirewallIndex is 0, then all firewall rules of the
    MIDCOM server that are created for interfaces with no specific
    entry in the midcomConfigFirewallTable are assigned to the
    firewall rule group indicated by the value of this object.

Not forgetting to fix the mistake in the DESCRIPTION clause of the
midcomConfigFirewallTable:

OLD:
        interface.  If an entry with midcomIfIndex = 0 occurs, then
NEW:
        interface.  If an entry with midcomConfigFirewallIndex = 0 occurs, then

> 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."

Similarly, this text should be something like

NEW

    The priority assigned to all firewall rules that the MIDCOM
    server creates for the interface indicated by object
    midcomConfigFirewallIndex. If the value of object
    midcomConfigFirewallIndex is 0, then this priority is assigned
    to all firewall rules of the MIDCOM server that are created for
    interfaces for which there is no specific entry in the
    midcomConfigFirewallTable.



Finally, I fixed another small mistake to be fixed in the DESCRIPTION
clause of object midcomConfigIfTable:

OLD:
         The table is indexed by the object midcomIfIndex.
NEW:
         The table is indexed by the object midcomConfigIfIndex.

OLD:
         midcomIfIndex = 0 occurs, then bits set in objects
NEW:
         midcomConfigIfIndex = 0 occurs, then bits set in objects


Thanks,

    Juergen

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom