Subject: AgentX "WG Last Call", etc.

From: "Bert Wijnen" <[email-masked]>
Date: Mon, 5 Jul 99 16:14:45 DST

Ref:  Your note of Fri, 02 Jul 1999 10:08:23 -0700

Subject: Re:   AgentX "WG Last Call", etc.

Lauren writes:
> >
> > Ref:  Your note of Thu, 01 Jul 1999 16:22:19 -0400
> >
> > Subject: Re:   AgentX "WG Last Call" for draft-ietf-agentx-mib-03.txt
> >
> > - I am surprised about agentxSessionAdminStatus.
> >   Can the value "up" be SET via SNMP? I doubt it.
> >   And after a set to "down", is the row then gone?
> >   If so, then maybe a RowStatus is the better TC to use??
>
> Mike Thatcher and I suggested this, I think at Chicago AgentX session,
> and I recall I mentioned this on the list even earlier than that.
> However, no one seemed thrilled about using RowStatus (didn't even get
> any head-nodding or your famous, mmmms) so I dropped the issue.  And
> yes, "down" is equivalent to "destroy", and "up" can't be set via SNMP.
>
So... I would say RowStatus is probably best.
But in nay event, you should explain that 'up' cannot be SET.
And in the Compliance you should specify that too as a WRITE-SYNTAX
and then only list the 'down' value.

>
> > - I would suggest that the various xxxTimeOut objects should
> >   have MAX-ACCESS of read-write. You would want a manager to
> >   be able to reset an excessive value requested by a subagent, no?
> >   Of course it is OK to put a MIN-ACCESS of read-only in the
> >   compliance section.
>
> agentxSessionTimeout and agentxRegTimeout (MAX-ACCESS, read-only)
> descriptions indicate these values are reflective of the subagent
> protocol element.  So, do we want to be able to both report the protocol
> elements AND be able to override them as you suggest?  Might we instead
> redefine the agentxDefaultTimeout so that it also defines a timeout
> ceiling, or perhaps add a agentxMaxTimeout variable?  Of course, if
> reporting the protocol elements isn't essential, we could just change as
> you suggested and rewrite the descriptions, etc..
>
In my original (saMIB) I did have a ..MaxTimeOut, so that the
NMS could limit the max timeout a subagent can use. Also.. I did
allow a NMS to overwrite any value that a subagent had
requested... just so a NMS can excercise control.
See if MaxTimeOut is say 255 tpo begin with and a sub request 255
and then a NMS sets MaxTimeOut to say 10... do you then go automatically
to reset all subagent values to max 10 too? or do you leave them in
tact and only apply the max value for the new connections. Guess you
could do so, because an NMS could always destroy (down) the
connection and cause the sub to reconnect in whcih case the new
MaxTimeout value would apply.
Anyway... it is not that I feel VERY STRONG about these things,
I just brought it up, because I know I had this capability
in my original saMIB (IBM enterprise specific MIB used with DPI).

> > - Sect 7, talks about the existence of read-create objects,
> >   but I do not see any. So... we need to fix that. I guess that
> >   is what you get when template text gets used.
> >
> > Bert
>
> Since the text reads "read-write and/or read-create", it seems
> technically correct, although maybe a little too generic.  So, are you
> suggesting that
> we change the boilerplate, or just edit this one reference, or both?
>
Our security guildelines are GUIDELINES.
So in this case I would remove the "and/or read-create"
although I do agree that it is not incorrect according to the letter
of the words. Up to you.

Bert

---

From: Bob Natale <[email-masked]>
Date: Mon, 05 Jul 1999 12:50:58 -0400

>At 7/5/99:12:14 PM, Bert Wijnen wrote:

Hi Bert and Lauren,

>Subject: Re:   AgentX "WG Last Call", etc.

I've changed the subject header to more clearly identify

>requested... just so a NMS can excercise control.

Yes, I think [an interpretation of the agentxDefaultTimeout value as]
a maxTimeOut value is very useful.  I do not think we should hold either
the NMS or the master agent hostage to a given sub-agent timeout value.
Of course, the sub-agent may still take as long as it needs to perform
its processing and this may well result in a timeout condition followed
by an "out-dated" response from the sub-agent that will just have to be
discarded...thus if either the sub-agent's requested timeout value and/or
its inability to respond within a user-specified amount of time (via the
NMS) is unacceptable in a given user scenario, we can expect market forces
to play their legitimate role.

>to reset all subagent values to max 10 too?

That's what I would do...their really is no need to "reset" higher
sub-agent values to a lower master agent maxTimeOut value...the lower
value applies automatically in any case.  In fact, you (i.e., the
master agent implementation) should not change the value requested
by the sub-agent...in setting the timer on any request to a sub-
agent, the master simply checks its notion of maxTimeOut versus
the sub's notion and applies the shorter.  If the master's maxTimeOut
value is later changed to something higher than a given sub-agent's
requested timeout value, then that sub-agent's value applies on
requests to it.

>or do you leave them in tact and only apply the max value for the
>new connections. Guess you could do so, because an NMS could always
>destroy (down) the connection and cause the sub to reconnect in whcih
>case the new MaxTimeout value would apply.

I would not recommend that...it is unnecessary (see above) and would
be highly costly in terms of operational overhead and performance.

>in my original saMIB (IBM enterprise specific MIB used with DPI).

Right...I think we can just re-state the semantics of the
agentxDefaultTimeout object as applying a maxTimeOut value
as well.  In other words, if a sub-agent does not specify
a specific timeout value, the agentxDefaultTimeout value will
be applied to requests to that sub-agent.  If a sub-agent does
supply a specific timeout value and it is *less than* the
agentxDefaultTimeout value, then it will be used for such
requests.  Otherwise, if it is higher than agentxDefaultTimeout,
then it will simply be retained for use should the value of
agentxDefaultTimeout be administratively increased to a value
higher than the sub-agent's specific timeout value.

Assuming that basic interpretation is acceptable, I am
certain the Laren and Mark can put that into a much nicer
(clearer and more concise) wording! :-)

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

---

From: Mike Daniele <[email-masked]>
Date: Tue, 06 Jul 1999 11:40:39 -0400

>and then only list the 'down' value.

RowStatus seems inappropriate to me for rows that can only be de-activated
(as opposed to created and/or activated) by a SetRequest.

I agree the description should state the only possible value to Set is 'down'.

Mike

---

From: Mike Daniele <[email-masked]>
Date: Tue, 06 Jul 1999 11:51:27 -0400

> >> >   be able to reset an excessive value requested by a subagent, no?

I don't see the value in this.  There is no way (via AgentX) for the subagent to know
its requested timeout value was replaced by a new value.

> the NMS or the master agent hostage to a given sub-agent timeout value.

That's a reasonable implementation, but it's unfortunately not reflected in the spec:
From 7.2.1:

   4) Timeout Values

     The master agent chooses a timeout value for each MIB region being
     queried, which is

         a) the value specified during registration of the MIB region,
            if it was non-zero

         b) otherwise, the value specified during establishment of the
            session in which this region was subsequently registered, if
            that value was non-zero

         c) otherwise, the master agent's implementaton-specific default
            value

     When an AgentX PDU that references multiple MIB regions is
     dispatched, the timeout value used for the PDU is the maximum
     value of the timeouts so determined for each of the referenced MIB
     regions.

I think it would be reasonable to state that the above is SHOULD processing,
but the master agent MAY select a different value (one choice being the master's default).

Mike

---

From: Bob Natale <[email-masked]>
Date: Tue, 06 Jul 1999 12:30:56 -0400

>At 7/6/99:11:51 AM, Mike Daniele wrote:

Hi Mike,

<...>
>That's a reasonable implementation, but it's unfortunately not reflected in 
<...>
>but the master agent MAY select a different value (one choice being the 

I can certainly live with that.

Cordially,

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

---

From: Lauren Heintz <[email-masked]>
Date: Tue, 06 Jul 1999 09:39:57 -0700

Comments follow...

> (as opposed to created and/or activated) by a SetRequest.

But to quote from the RowStatus description clause in rfc1903:

"The RowStatus textual convention is used to manage the creation and
deletion of conceptual rows, and is used as the value of the SYNTAX
clause for the status column of a conceptual row (as described in
Section 7.7.1 of [2].)... "

Seems that agentxSessionAdminStatus is just a constrained subset of the
RowStatus capability, so RowStatus does apply.  If not, then this
description needs more clarification on when RowStatus is intended --
and not intended -- to be used.

> I agree the description should state the only possible value to Set is 'down'.

So, if a row has status of "up" (or "active"), does a SET request fail
if it is setting the row status to the same value (whether that makes
sense or not)?  If we use RowStatus, then the SET should (according to
the RowStatus state table in rfc1903) succeed.  I think what we want to
make sure we constrain is the notion that the new rows can be created
via SNMP.

Lauren