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

Martin Stiemerling <stiemerling@netlab.nec.de> Wed, 19 May 2004 09:53 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25959 for <midcom-archive@odin.ietf.org>; Wed, 19 May 2004 05:53:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNcN-00060o-Uf for midcom-archive@odin.ietf.org; Wed, 19 May 2004 05:44:09 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9i7vW022974 for midcom-archive@odin.ietf.org; Wed, 19 May 2004 05:44:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN7c-0007jh-0l; Wed, 19 May 2004 05:12:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQMRK-0002a0-Ly for midcom@optimus.ietf.org; Wed, 19 May 2004 04:28:38 -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 EAA21191 for <midcom@ietf.org>; Wed, 19 May 2004 04:28:36 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQMRH-0001WT-S8 for midcom@ietf.org; Wed, 19 May 2004 04:28:35 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQMQH-0001OI-00 for midcom@ietf.org; Wed, 19 May 2004 04:27:34 -0400
Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BQMPT-0001Gg-00 for midcom@ietf.org; Wed, 19 May 2004 04:26:43 -0400
Received: from [10.1.1.109] (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 275FAF674; Wed, 19 May 2004 10:31:43 +0200 (CEST)
Date: Wed, 19 May 2004 10:26:20 +0200
From: Martin Stiemerling <stiemerling@netlab.nec.de>
To: Joel Tran <joel.tran@USherbrooke.ca>, midcom@ietf.org, srisuresh@yahoo.com, quittek@netlab.nec.de
Message-ID: <2147483647.1084962380@[10.1.1.109]>
In-Reply-To: <004c01c43c4b$0c04c730$b248d284@kamel>
References: <004c01c43c4b$0c04c730$b248d284@kamel>
X-Mailer: Mulberry/3.1.2 (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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [midcom] Re: 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>
Content-Transfer-Encoding: 7bit

Hi Joel,

Thanks for doing the really careful review.  My responses are inline.

Cheers,

  Martin

--On Montag, 17. Mai 2004 16:10 Uhr -0400 Joel Tran 
<joel.tran@USherbrooke.ca> wrote:

| 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?

The midcomRuleGroup does not correlate with midcomGroupTable.  The 
midcomRuleGroup is out of the compliance section (midcomCompliance) and 
describes with objects are mandatory and which are optional. 
midcomGroupGroup correlates with midcomGroupTable.

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

The exact way of creating/deleting entries in midcomRuleGroup is described 
in the MIDCOM semantics (draft-ietf-midcom-semantics-07.txt):  Entries in 
this table are created implicitly whenever an entry in midcomRuleTable with 
a new group ID is created and deleted when the last entry with the 
corresponding group ID is deleted in midcomRuleTable.

|
| ...J
|
|
| Page 14
| -------
|
| 1 - Title : 5.1.1. MidcomSession
| Should be : MidcomSessionTable

OK, fixed.

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

OK, fixed.

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

Thanks that's a leftover, fixed.

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

The sentence is chopped somehow. Here is proposal for new text replacing 
the first sentence:

The group index that is used as value for object midcomGroupIndex when
obtaining a new rule index by reading object midcomSessionRuleNewIndex.

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

Yes, should be the same, fixed.

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

Ok, fixed.

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

OK, fixed.

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

OK, fixed.

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

OK, that's an old entry, fixed.

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

OK, fixed.

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

Right, fixed.

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

OK, fixed.

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

Right, fixed.

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

I see, but the object for group indices is midcomGroupIndex.

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

This is intentionally not given, since this is specific to MIDCOM MIB 
implementations.

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

No, text is OK.  midcomGroupIndex has really the value of 
midcomSessionGroupIndex.  The midcomGroupGroup is just a compliancy 
statement.

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

It is not the midcomGroup.  You can find the relation between a session and 
the rules by using midcomSessionOwner of the midcomRuleTable index.


|
| Page 31
| -------
| 18 -
|               - optional monitoring objects that provide information
|                 about used resource and statistics
|
|  resource SHOULD be resources

OK, fixed.

|
| 19 -
|             In the signaling objects branch there are four groups of
|             managed objects defined:
|
|  SHOULD be "In the signaling objects branch, there are..."

OK, fixed.

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

OK, fixed.

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

The text is correct, since the the policy rule index is not generated out 
of the poliy rule group, but the relationship betwenn both is given.

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

The original text is OK, since not midcomGroup is not associated with 
midcomGroupIndex or midcomSessionRuleGroupIndex.





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