Subject: RE: AgentX Registration/Deregistration

From: "Ashish Hanwadikar" <[email-masked]>
Date: Wed, 7 Oct 1998 19:38:29 +0530

-----Original Message-----
From: Bob Natale [mailto:[email-masked]]
Sent: Saturday, August 08, 1998 3:39 AM
To: Shawn A. Routhier
Cc: [email-masked]
Subject: Re: AgentX Registration/Deregistration

>At 8/7/98 04:59 PM, Shawn A. Routhier wrote:

Hi Shawn,

<...>
>I think, but am not sure, that you missed my point.

Perhaps...if so, I apologize.  (Trying to get a bunch of
things done before heading out for a week's worth of
vacation! :-)

>The words in the current draft "...implements objects
>starting at this value" (agentxRegStart) and "...implements
>objects up to but not including this value" (agentxRegEnd)
>cover all of the objects from the first to the last even if
>the registration request had holes in it due to specifying
>objectids after the range.  For a concrete example, assume
>a sub agent registers ifentry.{1--22}.1, the above words
>would also imply that the range covers ifentry.1.2,
>ifentry.1.3 etc.

Hmmm.  I failed to make that interpretation of those
words...and still do.  I believe the various descriptions
we give of such range registrations include a phrase like
"for example, to register an entire row in some table"....

>I don't think that's what we want.

Right...but I think I've just seen the possible source
of the different readings you and I are making.  I read
(into it, perhaps) that the INSTANCE_REGISTRATION bit
was set on the associated agentx-Register-PDU operation
and, therefore, I use the .22 subid as the one to increment
and my agentxRegEnd value becomes ifEntry.23[.1].  That is,
I treat the instance part as a logical suffix not as part
of the ending object name itself.
<Ashish> Well, take the following case:
 Agent #1 registers ifEntry.[1-22].1 and Agent #2 registers
ifEntry.[1-22].2. Then how do we maintain agentxRegStart and agentxRegEnd
for the two regions. It will look like
     			start               end
Region #1         ifEntry.1.1         ifEntry.23.1
Region #2         ifEntry.1.2         ifEntry.23.2
Now, for a SNMP Get Request for ifEntry.1.2, two regions contain
ifEntry.1.2. Both have same length (no one is more specific than the other).
Whoever was registered with higher priority will get AgentX Get Request. The
algorithm for AgentX GET pdu dispatching does not say anything about such
conditions. Eventhough, implicitly, the region #2 should honor the request
because it handles the entries with suffix 2 (if instance registration flag
is set, the suffix can be called as index). In fact, it says little about
regions with range_subid. It does not mention such regions in dispatching
nor in the registration algorithms. I think meaning of region with
range_subid should be made very very clear in the RFC.

>I don't believe we need to change the objects in the mib,
>only the wording of the description to make it clear which
>elements are included in a range.

Ok...if I'm right about the source of our different readings,
then I think we need to change both the MIB description text,
as you say, and perhaps add some clarifying text to RFC 2257,
Section 6.2.3, "The agentx-Register-PDU", as (I think) might
have been recommended by someone else earlier (this concerns
"The master agent may save this information to optimize
subsequent operational dispatching.").

If you have any candidate text for either place, please
post it.

>I also think the concept of having a scheme that won't work
>correctly for certain values of subids (2^^32-1) is suspect
>and would prefer to see some other option.

In general, I agree with you (I think I noted this in an
earlier posting [but might have opted to leave it out for
some wrong reasons!]).  However, it's not really "certain
values"; it's only one value it's not unheard of to allow
for "special processing" on a single boundary value.  Granted,
again, it's not the most beautiful way in the world to do it.

>   It MUST be rejected, per the u.region test in RFC 2257 Sec. 7.1.6,
>   Processing the agentx-Unregister-PDU:
>
>   "4) If u.region, u.priority, and the indicated context do not match
>       an existing registration made during this session, the agentx-
>       Response-PDU is returned with res.error set to
>       'unknownRegistration'."
>
>I think there are different ways of reading that.  When registering,
>a request that has a range included may be viewed as either a single
>blob or a range of regions to register.  You are taking the former
>view.  I do not believe the current wording prohibits the latter view.
>In the latter case if u.region was one of the regions registered then
>it would be valid to unregister it.  Note that u.region would be
>matched against r.region and that the range information is NOT carried
>in the *.region fields.

Literally true...but the range info is carried in the PDU with the
*.region info in both cases and is a virtual extension of those
fields.  I wouldn't mind adding more clarifying text [and I hope
you will propose what you think will work best], but I would not
like to have the meaning changed to allow for such "subset"
deregistrations.

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

Ashish K Hanwadikar
Senior Software Engineer,
Wipro Infotech, Technology Solutions,
Bangalore
INDIA