[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
- [midcom] Comments on draft-ietf-midcom-mib-01.txt Joel Tran
- [midcom] Re: Comments on draft-ietf-midcom-mib-01… Martin Stiemerling
- [midcom] Re: Comments on draft-ietf-midcom-mib-01… Joel Tran