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

[Martin Stiemerling <stiemerling at netlab.nec.de>]

Hi Joel,

I have been on some trips without email, so sorry for sending my answer so 
late.


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

Entries in midcomGroupTable is associated with entries in midcomRuleTable. 
There is actually not a direct link between creating a session and 
resulting  group. Of course, groups are generated out of a session.


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

The naming of objects is sometimes not ideal in MIBs.  The nomenclature of 
SNMP says that there are groups in the conformance section and in this MIB 
this might be confusing since MIDCOM uses the term groups, too. Perhaps we 
can introduce a short paragraph pointing this out explicitly.

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

OK, fixed.


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

See remark above about SNMP nomenclature.

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

The behaviour how to generate asynchronous rule events (ARE) is described 
in Section 6.10 and in the MIB. MIB implementations generate those AREs and 
sent them to the session owner (this might result in multiple message if 
there is a session owner owning several session in parallel).  When there 
is no session owner left, no ARE is sent.


Thanks again for the review

Cheers,

 Martin

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