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

Hi Joel,

Thanks for the comments. The next version of the MIDCOM MIB will 
incorporate your comments given below.

Regards,

  Martin

--On Mittwoch, 16. Juni 2004 9:44 Uhr -0400 Joel Tran 
<[email protected]> wrote:

| Hi Martin,
|
|
| On Tue, 2004-06-15 at 16:29, Martin Stiemerling wrote:
|
|> |> | 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.
|
| Good idea. I think that this might help the readability of the MIBS.
|
|> |
|> |>
|> |> |
|> |> | 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.
|
| I think there might be a confusion in the text (section 6.10) since in
| the document, we are referring often to midcom session (a
| midcomSessionTable) and in this particular place in the document, we are
| referring to the SNMP session owner. One might think that we have to
| search for an active entry in the midcomSessionTable and find its owner.
| To avoid all confusion possible, something like this could be written
| instead :
|
| 1. The MIDCOM MIB implementation sends a midcomRuleEvent
|     notification containing a lifetime value of 0 to the
|     midcomSessionOwner of the rule.
|
| Thanks again for your explanations!
|
| ...J
|