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

Joel Tran <joel.tran@USherbrooke.ca> Wed, 19 May 2004 20:05 UTC

Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10177 for <midcom-archive@odin.ietf.org>; Wed, 19 May 2004 16:05:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWw1-0003Uh-PA for midcom-archive@odin.ietf.org; Wed, 19 May 2004 15:41:03 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JJf1S3013427 for midcom-archive@odin.ietf.org; Wed, 19 May 2004 15:41:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWla-0007sF-LP; Wed, 19 May 2004 15:30:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVxw-0000JC-51 for midcom@optimus.ietf.org; Wed, 19 May 2004 14:38:56 -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 OAA29403 for <midcom@ietf.org>; Wed, 19 May 2004 14:38:53 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQVxt-0006vN-Ba for midcom@ietf.org; Wed, 19 May 2004 14:38:53 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQVx6-0006pH-00 for midcom@ietf.org; Wed, 19 May 2004 14:38:06 -0400
Received: from smtp1.usherbrooke.ca ([132.210.244.17] helo=courrier3.usherbrooke.ca) by ietf-mx with esmtp (Exim 4.12) id 1BQVv5-0006bp-00 for midcom@ietf.org; Wed, 19 May 2004 14:35:59 -0400
Received: from traj1901.gel.usherb.ca (traj1901.gel.usherb.ca [132.210.72.178]) by courrier3.usherbrooke.ca (8.11.6/8.11.6) with ESMTP id i4JIZJp22266; Wed, 19 May 2004 14:35:19 -0400
From: Joel Tran <joel.tran@USherbrooke.ca>
Reply-To: joel.tran@USherbrooke.ca
To: Martin Stiemerling <stiemerling@netlab.nec.de>
Cc: midcom@ietf.org, srisuresh@yahoo.com, quittek@netlab.nec.de
In-Reply-To: <2147483647.1084962380@[10.1.1.109]>
References: <004c01c43c4b$0c04c730$b248d284@kamel> <2147483647.1084962380@[10.1.1.109]>
Content-Type: text/plain
Organization: Université de Sherbrooke
Message-Id: <1084991719.2550.38.camel@traj1901.gel.usherb.ca>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5)
Date: Wed, 19 May 2004 14:35:19 -0400
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
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

Thanks you the infos. I didn't understood at first the goal of the 
midcomConformance MIB section. 

One last quick question, what is the relation between the
midcomSessionTable and the midcomGroupTable? In my understanding, when a
midcomSession is created, a midcomGroupTable entry can be associated in
order to associate midcomRuleTable entry together (i.e. group
midcomRuleTable entry).

Comments inline.

...J

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

I agree with your new sentence.

However, I think there is a name confusion in the document. I think that
the object  midcomSessionRuleGroupIndex of the midcomSessionTable SHOULD
be midcomSessionGroupIndex. The current name
(midcomSessionRuleGroupIndex) is confusing considering that there is a
midcomSessionRuleGroup. One might think that it is the index of this
table (even if it is a conformance stuff).

In the other case, there is a mistake in the page 25. There is no object
midcomSessionGroupIndex in the MIBs.


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

Understanding the conformance section now, I fully agree.


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

Again, the object name midcomSessionRuleGroupIndex confused me. I was
thinking that it was reference to the midcomRuleGroup. This should be
changed to midcomSessionGroupIndex for a better understanding and avoid
confusion.

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

I understand your point. However, my point is that a session in
midcomSessionTable might be terminated and some rule might be still
active. Do we want to send a TRAP to the owner of the session (NONE) or
to the owner identified by midcomSessionOwner? The midcomGroup table is
probably not the best way. I think that a trap to the midcomSesionOwner
is enough.


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

My mistake. Sorry.

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

Sorry, I ment midcomGroupTable...

Chears!


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