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

[Joel Tran <joel.tran at USherbrooke.ca>]

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


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