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

From: "Joel Tran" <[email-masked]>
Date: Mon, 17 May 2004 16:10:49 -0400

Here are my few comments on the midcom mib draft.

I have also few questions on the draft.

1 - Is there any correlation between the midcomGroupTable and the
midcomRuleGroup?

2 - The draft does not address HOW and WHO is creating the midomRuleGroup.

...J

Page 14
-------

1 - Title : 5.1.1. MidcomSession
Should be : MidcomSessionTable

2 -
    o   midcomSessionOwner
        This string indicated the user that created and owns the
        session.  It is the firswt index element of this table.  All
        policy rules (and policy rule groups) have the same owner as the

first not firswt.

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.

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

5 - At the end, it should by midcomSessionRuleNewIndex to be consistent in
the document and in the MIBS.

6 -
    o   midcomSessionRuleIndexNext
        This object returns a part of an index that is so far unused in
        the midcomRuleTable.  The full unused index is given by the
        combination of values of the objects midcomSessionOwner and
        midcomSessionRuleGroupIndex of the same row of the
        midcomSessionTable in combination with the returned value.

  o   midcomSessionRuleIndexNext SHOULD be midcomSessionRuleNewIndex to be
consistent in the document and in the MIBS.

7 -
   Entries in this table can only be created after a valid value for the
   midcomRuleIndex has been read from midcomSessionRuleIndexNext in the
   corresponding entry of the midcomSessionTable.  Entries are removed,

 midcomSessionRuleIndexNext SHOULD be midcomSessionRuleNewIndex to be
consistent with the documents and the MIBS.

Page 16
-------

8 -
    o   midcomRulePortRange
        This object indicates a port ramnge for which a policy reserve
        rule or policy enable rule was requested or established,
        respectively.

 ramnge SHOULD be range.

9 -
     o   midcomRuleRowStatus
        This object allows entries to be added to the table.

  There is no such object in the MIBS. This text should be deleted.

10 -

     - A0 - internal endpoint: address tuple A0 specifies a
       communication endpoint of a devices within the - with respect to

 a devices SHOULD be a device.

Page 18
-------

11 -
    o   midcomGroupIndex
        The index of this entry must be unique in combination with the
        midcomSessionOwner of the entry.

 entry SHOULD be table since it is the index of the table we are talking.

Page 24
-------

12 -

   2. The MIDCOM client reads the midcomSessionNextIndex object in order
      to receive an index for creating a session.

 midcomSessionNextIndex SHOULD be midcomSessionIndexNext to be consistent in
the document.

Page 25
-------
13 -
      USM user name and by the index read from the
      midcomSessionNextIndex object in step 2.

  midcomSessionNextIndex SHOULD be midcomSessionIndexNext to be consistent
in the document.

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.

15 - Comments: there are no indications of where, how and by whom are the
policy rules are created.

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"

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.

Page 31
-------
18 -
              - optional monitoring objects that provide information
                about used resource and statistics

 resource SHOULD be resources

19 -
            In the signaling objects branch there are four groups of
            managed objects defined:

 SHOULD be "In the signaling objects branch, there are..."

Page 32
-------
20 -
   -- The table contains objects identify a destination for
   -- notifications to be sent to the MIDCOM client.
   -- Also it serves for creating new rows in the
   -- midcomRuleTable.

   identify SHOULD be identifying

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"

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.

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 19 May 2004 10:26:20 +0200

Hi Joel,

Thanks for doing the really careful review.  My responses are inline.

Cheers,

  Martin

--On Montag, 17. Mai 2004 16:10 Uhr -0400 Joel Tran 
<[email-masked]> wrote:

| Here are my few comments on the midcom mib draft.
|
| I have also few questions on the draft.
|
| 1 - Is there any correlation between the midcomGroupTable and the
| midcomRuleGroup?

The midcomRuleGroup does not correlate with midcomGroupTable.  The 
midcomRuleGroup is out of the compliance section (midcomCompliance) and 
describes with objects are mandatory and which are optional. 
midcomGroupGroup correlates with midcomGroupTable.

|
| 2 - The draft does not address HOW and WHO is creating the midomRuleGroup.

The exact way of creating/deleting entries in midcomRuleGroup is described 
in the MIDCOM semantics (draft-ietf-midcom-semantics-07.txt):  Entries in 
this table are created implicitly whenever an entry in midcomRuleTable with 
a new group ID is created and deleted when the last entry with the 
corresponding group ID is deleted in midcomRuleTable.

|
| ...J
|
|
| Page 14
| -------
|
| 1 - Title : 5.1.1. MidcomSession
| Should be : MidcomSessionTable

OK, fixed.

|
| 2 -
|     o   midcomSessionOwner
|         This string indicated the user that created and owns the
|         session.  It is the firswt index element of this table.  All
|         policy rules (and policy rule groups) have the same owner as the
|
| first not firswt.

OK, fixed.

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

|
| 5 - At the end, it should by midcomSessionRuleNewIndex to be consistent in
| the document and in the MIBS.

Yes, should be the same, fixed.

|
| 6 -
|     o   midcomSessionRuleIndexNext
|         This object returns a part of an index that is so far unused in
|         the midcomRuleTable.  The full unused index is given by the
|         combination of values of the objects midcomSessionOwner and
|         midcomSessionRuleGroupIndex of the same row of the
|         midcomSessionTable in combination with the returned value.
|
|   o   midcomSessionRuleIndexNext SHOULD be midcomSessionRuleNewIndex to be
| consistent in the document and in the MIBS.

Ok, fixed.

|
| 7 -
|    Entries in this table can only be created after a valid value for the
|    midcomRuleIndex has been read from midcomSessionRuleIndexNext in the
|    corresponding entry of the midcomSessionTable.  Entries are removed,
|
|  midcomSessionRuleIndexNext SHOULD be midcomSessionRuleNewIndex to be
| consistent with the documents and the MIBS.

OK, fixed.

|
|
| Page 16
| -------
|
| 8 -
|     o   midcomRulePortRange
|         This object indicates a port ramnge for which a policy reserve
|         rule or policy enable rule was requested or established,
|         respectively.
|
|  ramnge SHOULD be range.

OK, fixed.

|
| 9 -
|      o   midcomRuleRowStatus
|         This object allows entries to be added to the table.
|
|   There is no such object in the MIBS. This text should be deleted.

OK, that's an old entry, fixed.

|
| 10 -
|
|      - A0 - internal endpoint: address tuple A0 specifies a
|        communication endpoint of a devices within the - with respect to
|
|  a devices SHOULD be a device.

OK, fixed.

|
| Page 18
| -------
|
| 11 -
|     o   midcomGroupIndex
|         The index of this entry must be unique in combination with the
|         midcomSessionOwner of the entry.
|
|  entry SHOULD be table since it is the index of the table we are talking.

Right, fixed.

|
| Page 24
| -------
|
| 12 -
|
|    2. The MIDCOM client reads the midcomSessionNextIndex object in order
|       to receive an index for creating a session.
|
|  midcomSessionNextIndex SHOULD be midcomSessionIndexNext to be consistent
| in the document.

OK, fixed.

|
| Page 25
| -------
| 13 -
|       USM user name and by the index read from the
|       midcomSessionNextIndex object in step 2.
|
|   midcomSessionNextIndex SHOULD be midcomSessionIndexNext to be consistent
| in the document.

Right, fixed.

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

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

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

|
| Page 31
| -------
| 18 -
|               - optional monitoring objects that provide information
|                 about used resource and statistics
|
|  resource SHOULD be resources

OK, fixed.

|
| 19 -
|             In the signaling objects branch there are four groups of
|             managed objects defined:
|
|  SHOULD be "In the signaling objects branch, there are..."

OK, fixed.

|
| Page 32
| -------
| 20 -
|    -- The table contains objects identify a destination for
|    -- notifications to be sent to the MIDCOM client.
|    -- Also it serves for creating new rows in the
|    -- midcomRuleTable.
|
|    identify SHOULD be identifying

OK, fixed.

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

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

---

From: Joel Tran <[email-masked]>
Date: 19 May 2004 14:35:19 -0400

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

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

> I see, but the object for group indices is midcomGroupIndex.

Understanding the conformance section now, I fully agree.

> midcomSessionGroupIndex.  The midcomGroupGroup is just a compliancy 

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.

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

> of the poliy rule group, but the relationship betwenn both is given.

My mistake. Sorry.

> midcomGroupIndex or midcomSessionRuleGroupIndex.

Sorry, I ment midcomGroupTable...

Chears!