[midcom] Comments on draft-ietf-midcom-mib-01.txt

"Joel Tran" <joel.tran@USherbrooke.ca> Mon, 17 May 2004 21:54 UTC

Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05257 for <midcom-archive@odin.ietf.org>; Mon, 17 May 2004 17:54:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpnj-0005uf-4m for midcom-archive@odin.ietf.org; Mon, 17 May 2004 17:37:35 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HLbZKF022730 for midcom-archive@odin.ietf.org; Mon, 17 May 2004 17:37:35 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpT9-000321-Gj; Mon, 17 May 2004 17:16:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoVp-0000Wc-QS for midcom@optimus.ietf.org; Mon, 17 May 2004 16:15:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21916 for <midcom@ietf.org>; Mon, 17 May 2004 16:14:59 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPoVo-0001z0-3K for midcom@ietf.org; Mon, 17 May 2004 16:15:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPoU2-0001CA-00 for midcom@ietf.org; Mon, 17 May 2004 16:13:11 -0400
Received: from smtpi1.usherbrooke.ca ([132.210.244.92]) by ietf-mx with esmtp (Exim 4.12) id 1BPoSr-0000dw-00 for midcom@ietf.org; Mon, 17 May 2004 16:11:57 -0400
Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by smtpi1.usherbrooke.ca (8.12.10/8.12.10) with ESMTP id i4HKBNuU010541; Mon, 17 May 2004 16:11:23 -0400
From: Joel Tran <joel.tran@USherbrooke.ca>
To: midcom@ietf.org, srisuresh@yahoo.com, stiemerling@netlab.nec.de, quittek@netlab.nec.de
Date: Mon, 17 May 2004 16:10:49 -0400
Message-ID: <004c01c43c4b$0c04c730$b248d284@kamel>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel
X-UdeS-MailScanner: Aucun code suspect détecté
X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90)
X-MailScanner-From: joel.tran@usherbrooke.ca
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [midcom] Comments on draft-ietf-midcom-mib-01.txt
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
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>

Here are my few comments on the midcom mib draft.

I have also few questions on the draft.

1 - Is there any correlation between the midcomGroupTable and the
midcomRuleGroup?

2 - The draft does not address HOW and WHO is creating the midomRuleGroup.

...J


Page 14
-------

1 - Title : 5.1.1. MidcomSession
Should be : MidcomSessionTable

2 -
    o   midcomSessionOwner
        This string indicated the user that created and owns the
        session.  It is the firswt index element of this table.  All
        policy rules (and policy rule groups) have the same owner as the

first not firswt.

Page 15
-------

    o   midcomSessionRuleGroupIndex
        The group for which a free index in the policyRuleTable is
        obtained by reading object midcomSessionRuleNewIndex.  This
        object must be set properly before reading a free index from
        midcomSessionRuleIndexNext.

3 - It is in the midcomRuleTable not policyRuleTable that we are searching a
free index.

4 - I don't understand the part "is obtained by reading object
midcomSessionRuleNewIndex". In my understanding, the phrase should be
something like: "The group for which a free index midcomSessionRuleNewIndex
is associated."

5 - At the end, it should by midcomSessionRuleNewIndex to be consistent in
the document and in the MIBS.

6 -
    o   midcomSessionRuleIndexNext
        This object returns a part of an index that is so far unused in
        the midcomRuleTable.  The full unused index is given by the
        combination of values of the objects midcomSessionOwner and
        midcomSessionRuleGroupIndex of the same row of the
        midcomSessionTable in combination with the returned value.

  o   midcomSessionRuleIndexNext SHOULD be midcomSessionRuleNewIndex to be
consistent in the document and in the MIBS.

7 -
   Entries in this table can only be created after a valid value for the
   midcomRuleIndex has been read from midcomSessionRuleIndexNext in the
   corresponding entry of the midcomSessionTable.  Entries are removed,

 midcomSessionRuleIndexNext SHOULD be midcomSessionRuleNewIndex to be
consistent with the documents and the MIBS.


Page 16
-------

8 -
    o   midcomRulePortRange
        This object indicates a port ramnge for which a policy reserve
        rule or policy enable rule was requested or established,
        respectively.

 ramnge SHOULD be range.

9 -
     o   midcomRuleRowStatus
        This object allows entries to be added to the table.

  There is no such object in the MIBS. This text should be deleted.

10 -

     - A0 - internal endpoint: address tuple A0 specifies a
       communication endpoint of a devices within the - with respect to

 a devices SHOULD be a device.

Page 18
-------

11 -
    o   midcomGroupIndex
        The index of this entry must be unique in combination with the
        midcomSessionOwner of the entry.

 entry SHOULD be table since it is the index of the table we are talking.

Page 24
-------

12 -

   2. The MIDCOM client reads the midcomSessionNextIndex object in order
      to receive an index for creating a session.

 midcomSessionNextIndex SHOULD be midcomSessionIndexNext to be consistent in
the document.

Page 25
-------
13 -
      USM user name and by the index read from the
      midcomSessionNextIndex object in step 2.

  midcomSessionNextIndex SHOULD be midcomSessionIndexNext to be consistent
in the document.

14 -
    4. If the MIDCOM client wants to have all policy rules it creates to
      be member of the same particular policy rule group, then the
      MIDCOM client should set the midcomSessionRuleGroupIndex to the
      group index that is to be used.

  "group index" at the end SHOULD be "midcomRuleGroup" to ease the reading.

15 - Comments: there are no indications of where, how and by whom are the
policy rules are created.

16 -
   2. The SNMP manager reads the midcomSessionRuleNewIndex from an open
      entry in the modcomSessionTable in order to trigger creation of a
      new entry in the midcomRuleTable.  The new entry in the
      midcomRuleTable has the following index elements:
      midcomSessionOwner has the same value as the session from which
      the value of midcomSessionRuleNewIndex was read; midcomGroupIndex
      has the value of midcomSessionRuleGroupIndex at the time the value
      of midcomSessionRuleNewIndex was read; and midcomRuleIndex has the
      value read from midcomSessionRuleNextIndex.

  "midcomGroupIndex has the value of the midcomSessionRuleGroupIndex" SHOULD
be   "midcomGroupIndex has the value of the midcomGroup associated with the
midcomRuleTable"

Page 29
-------

17 -
   1. The MIDCOM MIB implementation sends a midcomRuleEvent notification
      containing a lifetime value of 0 to the SNMP manager owning the
      session.

  Should it be more the SNMP manager owning the midcomGroup. Once the rule
is created, it is impossible to find the correlation between a session and a
rule. The only correlation possible is between a group/user/rule with the
midcomGroup table.

Page 31
-------
18 -
              - optional monitoring objects that provide information
                about used resource and statistics

 resource SHOULD be resources

19 -
            In the signaling objects branch there are four groups of
            managed objects defined:

 SHOULD be "In the signaling objects branch, there are..."

Page 32
-------
20 -
   -- The table contains objects identify a destination for
   -- notifications to be sent to the MIDCOM client.
   -- Also it serves for creating new rows in the
   -- midcomRuleTable.

   identify SHOULD be identifying

Page 35
-------
35 -
           "This object indicated for which policy rule group
            a policy rule index is generated when object
            midcomSessionRuleNewIndex is read."

   SHOULD be "This object indicates from which"

Page 36
-------
36 -
            The index of the new entry of the midcomRuleTable
            consists of three elements.  The first one is the
            midcomSession index of the entry at which the value
            of midcomSessionRuleNewIndex was read.  The second
            index is the current value of midcomSessionRuleGroupIndex
            in the same entry of the midcomSessionTable.  The third
            element is the value returned then this object is read.

 "The second index is the current value of midcomSessionRuleGroupIndex in
the same entry of the midcomSessionTable" The second index is the value of
the midcomGroup Index associated.




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