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

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!