Subject: Re: open issues in agentX MIB

From: "Smitha Gudur" <[email-masked]>
Date: Mon, 03 Aug 1998 09:58:26 PDT

>From [email-masked] Fri Jul 31 15:29:56 1998
>Received: from [192.152.208.5] (helo=acecomm.com)
>	by relay2.smtp.psi.net with smtp (Exim 1.90 #1)
>	id 0z2NgO-0005N2-00; Fri, 31 Jul 1998 18:29:53 -0400
>Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM)
>	id AA17422; Fri, 31 Jul 1998 18:32:10 -0400
>Message-Id: <[email-masked]>
>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1
>Date: Fri, 31 Jul 1998 18:32:19 -0400
>To: "Smitha Gudur" <[email-masked]>
>From: Bob Natale <[email-masked]>
>Subject: Re: open issues in agentX MIB
>Cc: [email-masked], [email-masked]
>In-Reply-To: <[email-masked]>
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>
>>At 7/31/98 02:45 PM, Smitha Gudur wrote:
>
>Hi Smitha,
>
>>There is relationship between sessionID defined in RFC2257 and
>>the agentxSessionIndex.
>
>Logically, that's true.  The value used for agentxSessionIndex
>to identify the session should be the same as that used for
>the SessionID as given by the master agent to the subagent.
>The problem Mike alludes to here derives from the "should not
>be re-used" semantics used for agentxSessionIndex in the MIB
>but which are missing from the RFC references to SessionID.
>
>I would argue that the RFC text should be tightened in this
>respect, to stipulate non-reuse; but it is clear that a
>reasonable argument can be made for not stipulating it and
>leaving it up to the implementation.
>
>In my view, however, management apps will be able to use
>the MIB better to monitor the overall AgentX system if
>the non-reuse semantics of agentxSessionIndex are carried
>over to SessionID.  This value, via agentxSessionIndex,
>is critical to all three of the tables currently defined
>in the MIB [btw, we should all be reading from the -02.txt
>version of the MIB document, dated April 14, 1998, at this
>point]:
>
>	agentxConnectionTable
>	agentxSessionTable
>	agentxRegistrationTable
>
>In thinking through the relationships, it seems that we
>need to add agentxConnIndex to the AgentxSessionEntry and 
>agentxSessionIndex to the AgentxRegistrationEntry.  In this
>way, each registration entry can point to the session in
>which it lives and each session can point to the connection
>in which it lives.
>

>[Note to Smitha and Lauren here in particular:]
>The rationale and the consequent OBJECT-TYPE macros
>should be obvious (I think), but if not let me know.

Currently, the agentxConnIndex is one of the indices for 
agentxSessionEntry, and agentxSessionIndex is also one of the indices
for agentxRegistrationEntry. Do we still need each of these object-type 
for  the respective entries?

smitha.

>
>>Current description for agentxSessionIndex includes:
>>
>>"Index values assigned for a given registration are constant
>>for the lifetime of this table."
>>
>>is inappropriate and needs to be removed.
>
>Right.
>
>>The other part of the description is consistent with the RFC.
>
>That's the debatable part.
>
>>thanks for the inputs.
>
>Likewise.
>
>Cordially,
>
>BobN
>------------ ISO 9001 Registered Quality Supplier -----------
>Bob Natale         | ACE*COMM              | 301-721-3000 [v]
>Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
>[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
>------------- Free downloads at www.winsnmp.com -------------
>
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: Bob Natale <[email-masked]>
Date: Mon, 03 Aug 1998 14:20:14 -0400

>At 8/3/98 09:58 AM, Smitha Gudur wrote:
>Subject was: Re: open issues in agentX MIB

Hi Smitha,

<...>
>>which it lives and each session can point to the connection
<...>
>agentxSessionEntry, and agentxSessionIndex is also one of
>the indices for agentxRegistrationEntry.

Implicit in my comments was the notion that each of the
three tables needs only a single simple index, respectively:

   agentxConnectionTable     agentxConnIndex
   agentxSessionTable        agentxSessionIndex
   agentxRegistrationTable   agentxRegIndex

I can see no need for the multiple indices on agentxSessionTable
(agentxConnIndex, agentxSessionIndex) or agentxRegistrationTable
(agentxConnIndex, agentxSessionIndex, agentxRegIndex).

It would lead to unnecessary ambiguity about the semantics
of some of the protocol elements (SessionID, in particular);
it would preclude certain useful queries (due to the
not-accessible max access clauses of the index elements);
and it just violates Occam's razor--using an (effectively)
unique integer valued primary index for each table solves
the problem w/o further adornment.

The key relationship is on the agentxSessionIndex (SessionID).
The registration info clearly depends on it and *if* we add
the traffic/error info via the proposed agentxResponsesTable
that would also tie to the agentxSessionIndex (indeed, it
could be added directly to the agentxSessionTable as is...
we would keep it separate only if we want to allow it to
be a MODULE-COMPLIANCE option).

>Do we still need each of these object-type for the
>respective entries?

Yes, but not as an "in addition to" (obviously) but
(IMHO) rather "in lieu" of the multiple indexing.

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------