Subject: Re: Thanks & Confusion ........

From: Randy Presuhn <[email-masked]>
Date: Thu, 5 Aug 1999 10:22:43 -0700 (PDT)

Hi -

> From: [email-masked]
> To: [email-masked] ('agentx')
> Subject: Thanks & Confusion ........
> Date: Thu, 5 Aug 1999 11:30:08 +0530
...
> 	Suppose a subagent S1 has registered full Interfaces( 1.3.6.1.2.1.2 ) subtree/region. Now a subagent S2 tries to register                        an individual row in the IF table as 1.3.6.1.2.1.2.2.1.[1-22].7. Will the master agent allow this registeration?. 

These registration requests are perfectly legal.

> 	If yes, how the master agent knows previously that, this row was not registered by subagent S1 as while registering S1 	need not allocate index for row registration since it has registered full table.

Until S2's registration request is accepted by the master agent, an SNMP
operation affecting 1.3.6.1.2.1.2.2.1.[1-22].7  would be dispatched to S1.

The master agent does not need to know anything about the indexing structure.
The dispatching is purely in terms of the OID tree.  The subagent claiming
the longest matching registration "wins".

> 	In the same above scenario Is there need for S1 to allocate index for each row it is supporting ?
...

No.  Any request involving an object beneath 1.3.6.1.2.1.2 that is not
claimed by another subagent's registrations will be dispatched to S1.
However, if S1 were to also explicitly register its rows, doing so would
cause no harm.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com/
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's is probably coincidental.
 ------------------------------------------------------------------------

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 5 Aug 1999 16:34:14 -0700 (PDT)

Hi -

> Date: Thu, 05 Aug 1999 19:16:13 -0400
> To: Randy Presuhn <[email-masked]>
> From: Bob Natale <[email-masked]>
> Subject: Re: Thanks & Confusion ........
> Cc: [email-masked]
...
> Mark said:
> >>I've re-read RFC 2257, sxn 7.1.5 (4).  My interpretation still comes up as
> >>'duplicate', not 'overlapping'.  Specifically, the first paragraph of RFC 
> >>2275, sxn 7.1.5. (4) says:
> >> 
> >>       If r.region (or any of its set of Object Identifiers, if r.range
> >>       is non-zero) is exactly the same as any currently registered value
> >>       of r.region (or any of its set of Object Identifiers), this
> >>       registration is termed a duplicate region.
> 
> Randy said:
> >In the text you quote, "r.region" of the registration request must be
> >"exactly the same" as a current registration.
> 
> I read the parenthetical comment "(or any of its set of Object Identifiers)"
> as covering the set of ranged OIDs...such that:

That was not how I had read 2257 at all.  The text on r.range_subid
(elsewere refered to as r.range) led me to understand "set of Object
Identifiers" in this context as being either the one-element set
{r.region} or the two-element set {r.region,  r.upper_bound}, depending
on the value of the r.range(_subid) element.  The language in the
paragraph following the quoted one reinforces this reading, since it
distinguishes "contains" and "subtree" from this case.

> >For the sequence of registrations Dave Harrington described,
> 
> S3 would have definitely been a duplicate of one of S2 ranged registrations.
> 
> >The corresponding text in the draft defines "duplicate" so that it
> >includes this case, thus avoiding the conundrum in dispatching.
> 
> Good...all's well that ends well.
...

Yup.

---

From: [email-masked]
Date: Fri, 6 Aug 1999 13:17:33 +0530

Hi,

When S1 has registered full Interfaces( 1.3.6.1.2.1.2 ) subtree/region,  it means is that the table is entirely local to it, and that all the rows (instances) in the table belong to S1. Now if S2 registers 1.3.6.1.2.1.2.2.1.[1-22].7, it should get an error saying that the row is not free.

The same thing applies even if S1 had registered a range 1.3.6.1.2.1.  To  1.3.6.1.2.2. The master agent will not be aware that a table with OID 1.3.6.1.2.1.2.2.1 exists within the registered range. Hence it straight away should rehect the registration from S2 for 1.3.6.1.2.1.2.2.1.[1-22].7

Regards
Gouri

-----Original Message-----
From:	Mark Ellison [SMTP:world.std.com!ellison]
Sent:	Thursday, August 05, 1999 11:19 PM
To:	kailash.future.futsoft.com!ravinderv 
Cc:	"'agentx'"; Mark Ellison
Subject:	Re: Thanks & Confusion ........

Hi, Ravinder

In your example, a compliant master agent would allow both the registration from S1 and the registration from S2.  Your example shows an overlapping registration.  A compliant master agent will dispatch to S1 for all requests that fall under 1.3.6.1.2.1.2  except for the portion registered by S2, namely
1.3.6.1.2.1.2.2.1.[1-22].7.  Here, the compliant master agent would dispatch to S2

The Elements of Procedure specifies the master agent reject duplicate registrations and allow overlapping registrations.

Possibly sections 7.1.4, "Processing the agentx-Register-PDU" and
 7.2.1, "Dispatching AgentX PDUs", expecially the part about "Honoring the registry" will help here.

You're encouraged to keep at this while any confusion remains :-)

Regards,

Mark

[email-masked] wrote:

> Hi,
>         First of all thanks a lot for prompt reply. I think i am unable to put clearity in my question so the same follows below :
>
>         I have the following doubt in table sharing ::
>
> Bye
> Ravinder.
> ----------
> From:   Randy Presuhn[SMTP:dorothy.bmc.com!rpresuhn]
> Sent:   Thursday, August 05, 1999 1:31 AM
> To:     dorothy.bmc.com!agentx
> Subject:        Re:  Table Sharing
>
> Hi -
>
> > Subject: Table Sharing
> > Date: Wed, 4 Aug 1999 15:16:45 +0530
> ..
> >       When a Agentx Subagent registers a MIB region containing a sharable table like ifTable , then how the rest of the agentx subagents will get themselves registered for a particular row.  As per the RFC rows cannot be shared then how the second or so subagent can register itself for that table.
> ..
>
> See RFC 2257, especially clause 7.1.5.1.  Since the registrations for
> individual rows will have more sub-identifiers than the registration
> for the table as a whole, there is no problem; it's not even necessary
> to resort to looking at the priority field to resolve the requests.
>
> I'm curious as to what you mean by "rows cannot be shared".  While this
> would certainly be unusual, at a protocol level it is indeed possible
> for different subagents to take responsibility for different columns
> in the same table, resulting in a situation where different subagents
> will end up with resposibility for different objects in the same
> conceptual row.
>

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 9 Aug 1999 12:01:54 -0700 (PDT)

Hi -

> From: [email-masked]
> To: [email-masked] ('Mark Ellison'),
>         [email-masked] ("kailash.future.futsoft.com!ravinderv ")
> Cc: [email-masked] ("\"'agentx'\"")
> Subject: RE: Thanks & Confusion ........
> Date: Fri, 6 Aug 1999 13:17:33 +0530
> 
> Hi,
> 

This is simply not true.  Both RFC 2257 and the current agentx draft
clearly allow for this case; supporting such configurations was a design
requirement for AgentX.

...

Again, not true.  See the examples on pages 49 and 50 of RFC 2257, which
directly contradict this assertion.