Subject: RE: AgentX Charter/Milestone Update

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 20 Apr 2001 13:41:38 -0500

A compilation...

<MikeA>
	There is also USM, which needs the set of security credentials in
order to support the Own Key Change objects.
</MikeA>
<BertW>
I would think that these USM things belong in the MASTER agent
and so would not have any impact on agentx protocol
</BertW>

	That was supposed to be my point.  There have been (at least one)
MIB(s) all along which could not be supported by AgentX, so why change
direction now for *proposed* MIBs?  If there is real need for such changes,
ther is plenty of room in the timetable to do it either as AgentXv2 or as a
new "AgentI" (agent integration?) protocol.

	As an aside, I have yet to see a MIB, existing or proposed, that
could not have circumvented such needs.  Even the EoS RowOps proposal, upon
light consideration, seems to be implementable by having the master agent
reconstruct the RowOps PDUs into traditional PDUs to pass to the subagents.

<FrankS>
In my opinion, the same is true for other MIB tables that model
general functions or characteristics of an agent or its infrastructure, 
e.g., in the DISMAN-EVENT-MIB or the SNMPCONF-PM-MIB mentioned by Wes.
</FrankS>

<Randy and Frank going back and forth>

	[SNIP]

</Randy and Frank going back and forth>

	I don't think it is a good idea to discuss agent architecture from
the external view, since the reasons for architectures tend to include a lot
of internal considerations.  One question is:  "Is it possible to redesign
and implement these functionalities using only AgentX as it stands?"  I
believe that the answer is "yes, except for authentication".  Another
question is: "Is it desireable to support capabilities beyond what is
currently provided by AgentX?"  I suspect that the answer will be "yes", but
that does not change the first answer.  Also please note that AgentX has no
security built in, which makes the connection of subagents which need
authentication intrinsically(sp?) dicey.  I suspect that authentication will
drive a second phase of this WG.

<WesH>
Which works as long as there isn't conflicts with multiple subagents
registering the same row with possibly different values.  Granted,
this is somewhat of an impossible problem to solve without the
external tables explicitly saying how to handle this case.
</WesH>

	Unless I'm misreading you, the protocol for handling that case is
already explicitly stated.

/|/|ike

---

From: Bob Natale <[email-masked]>
Date: Fri, 20 Apr 2001 16:33:33 -0400

At 4/20/2001:02:41 PM, Ayers, Mike wrote:

><...>
>could not have circumvented such needs.

Quite right, Mike.  In part, the fact that many new MIB efforts since the
initial standardization of AgentX have not taken it into consideration
during the design phase reflects a failure on my part to generate
adequate PR for the protocol, both within the IETF and in the industry
at-large.  Lots of reasons for that -- some good, some lame.  I plan to
make a concerted effort to rectify that error once we move past (or get
very near to completing) the new milestones for this round.

>  Even the EoS RowOps proposal, upon light consideration, seems to be
>implementable by having the master agent reconstruct the RowOps PDUs
>into traditional PDUs to pass to the subagents.

Good idea for further discussion.  We'll have to see how such a flexible
approach might fly in practice.

><...>

BobN

---

From: Lauren Heintz <[email-masked]>
Date: Fri, 20 Apr 2001 14:27:25 -0700

Hi,

> approach might fly in practice.

The rowop PDUs as defined in the current draft can indeed
by translated into convention Sets/gets, but only with
some loss of semantics in some cases, and only if the
cmd generator takes care to address certain issues when deciding
what to put into the PDUs.  In other words, not all
EOS row operations (as defined) are translatable.  That
draft discusses this issue a bit.  It is not yet an EOS
requirement that any new rowops MUST NOT impact the current
AgentX protocol (rather, only minimize such impact, whatever
that means).

Thanks,
Lauren