Re: AgentX WG: New work items or close?

Robert> With the advancement of the AgentX specs to Draft Standard
Robert> status some time ago, we now need to decide whether we want to
Robert> take on any new work items as an WG or ask the IESG to close
Robert> the WG until the time comes to review the specs'
Robert> qualifications for Full Standard status.


Robert> I have bcc:'d the "AgentPP" and "NET-SNMP" lists on this
Robert> notice since they have more AgentX traffic than this list

Wes>                           Dave Shield and John Naylon are two of
Wes> our core AgentX developers, as you might know, are not available this
Wes> week but hopefully they'll be back next week and might have further
Wes> thoughts.


Sorry for the delay in responding - I've now had a bit of a thunk about
this, so would offer the following comments.
  Please note that my main involvement was with the original coding,
and John's been doing much of the AgentX development recently (fixing
my mistakes!) So this is based on observation of mailing list traffic,
and abstract pondering - rather than being a view from the coalface.


  The main issue that's come up on the net-snmp lists is one of access
control.  i.e. authentication/authorisation between the subagent & master.
Using the SNMPv3 security features is related to this, of course, but
seems more concerned with the master->subagent information  handling.
It's not so immediately applicable to the subagent->master admin-style
traffic (e.g. is this subagent allowed to connect/register/etc).

   Such concerns can be handled to a certain extent using out-of-protocol
mechanisms (such as socket permissions, or tcpwrapper-style access lists).
But it's probably worth considering some form of (optional) in-band
validation process (passwords, challenge-response, kerberos, etc)



  The other area that sprang to mind was preparing for future
expandability.  Mark's already mentioned the possible impact of the
EOS and SMIng work.  And reading through the EOS discussions prior to
London, I felt a definite reluctance to adopt anything that wouldn't
fit into the existing AgentX structures (e.g. new data types).

  While stability is obviously to be desired, this shouldn't become
a total bar to advancement.  I wonder whether some form of "feature
negotiation" might be useful - analogous with the EHLO handshake of
extended SMTP.   That would free the EOS and SMIng people to extend
the protocol and data structures, without having to worry about breaking
all our fledgling AgentX implementations.


Those are the issues that come to mind immediately, anyway.

Dave
-- 
Dave Shield		      [email protected]
Dept. of Computer Science,
Liverpool University,	     "He who brings [computers] on to his premises
PO Box 147,		      should be absolutely liable ... for any mischief
Liverpool, L69 7ZF	      that ensues."     Haddock v. Computer 1578/32/W1