Subject: RE: snmpconf 11. Setcli accessor function - Item to be resolved o n email list

From: Dan Romascanu <[email-masked]>
Date: Sun, 21 Jan 2001 15:01:22 +0200

...living in a country blessed with a lot of sun, I must use protecting
covers for the driving wheels. What I have observed, is that despite the
fact that there seems to be no standard for steering wheels, their form and
diameter have enough commonality to allow for the same cover to be used for
my last three different models of cars. 

One more reason for supporting the point made in the message by dbh.

Regards,

Dan

> -----Original Message-----
> From:	David Harrington [SMTP:[email-masked]]
> Sent:	Thu January 18 2001 21:33
> To:	[email-masked]
> Subject:	Re: snmpconf 11. Setcli accessor function - Item to be
> resolved on email  list
> 
> Hi,
> 
> I am a real evangelizer for standards, but sometimes must deal with
> reality.
> 
> If my car manufacturer provided me a car that didn't have a steering
> wheel because the industry hadn't yet set a standard for steering
> wheels, I wouldn't be able to use the car, no matter how well it
> complied with those standards that did exist.
> 
> If we provide a configuration mechanism that can only manipulate SNMP
> MIB objects, then snmpconf may be unable to apply customer policies to
> existing devices. Most devices are still configured more via CLI than
> SNMP. If we don't support a CLI "gateway", then operators cannot
> translate high-level policies into available configuration commands. 
> 
> The ideal solution, of course, is to expand the number of SNMP objects
> to include all functionality of managed devices, but it isn't very
> realistic to expect that this will happen soon. We should provide a
> migration strategy that allows for configuration of existing devices,
> and encourages development of additional mib modules.
> 
> I think it is important, albeit distasteful, to provide the ability to
> integrate SNMP and CLI and possibly other existing mechanisms to
> configure devices to meet customer policies. The current proposal calls
> for a setcli() function; maybe this should be expanded to a more generic
> execute_this_non-snmp_command() function, i.e. we need a system()
> function. 
> 
> If we don't support some type of system() function, then we should
> define an SNMP octet-string object that can be SET to a non-snmp command
> and executed as part of an snmpconf rule, although I think this approach
> might be very inefficient.
> 
> my $.02
> dbh
> 
> Jon Saperia wrote:
> > 
> > On observing the exchange between Joel and Jeff and in the absence of
> > other comments, I have not seen a lot of support for the idea and while
> > I think Jeffs points are helpful, they fix things that really are not
> > issues today (that I know of) but might be if we were to introduce this
> > feature.
> > 
> > /jon
> > >
> > > >I must be missing something.   I do not understand the value of our
> > > >standardizing "the name of the function and the minimum error
> > > >behavior".  Given that the parameters will be different for different
> > > >systems, having the name the same actually seems almost
> > > >counter-productive.  It certainly does not seem like something we
> should be
> > > >puttting time and energy into at this point in the process.
> > >
> > > one of us is missing something but it may be me
> > >
> > > here is a bit more about what i was thinking ...  if one has an
> > > implementation-specific feature, like we are discussing, one error
> > > that i think is likely to happen in practice is that somebody will
> > > download and attempt to run a script for a flintstone router onto a
> > > yogiberra router
> > >
> > > if the names of the accessors and the minimum error behaviors are not
> > > standardized, then you get a generic error that is indistinguishable
> from
> > > a language syntax error, e.g., a typo and any recovery is impossible
> > >
> > > if, however, you have a standard for the accessor, you can define
> minimal
> > > error behaviors like
> > >       no cli subsystem
> > >       cli syntax error
> > >       and the like (perhaps more, perhaps not)
> > >
> > > then, a prudent coder can do some defensive driving against these
> common
> > > errors as we have been taught to do (but do all too seldomly)
> > >
> > >       [i am aware that you could achieve the same result via use of an
> > >       additional generic accessor function similar to the c-shell
> operator
> > >       " -e " for file inquiries, but this seems to be an unnecessary
> and
> > >       unwarranted complexity unless justified elsewhere and that seems
> > >       pretty unlikely]
> > >
> > > i think that the diagnostic benefits of an error mechanism that is
> more
> > > specific and localized to the the problem rather than less specific
> are
> > > uncontroversial, but, then, i thought that the above was
> uncontroversial
> > >
> > > if this turns out to be real contentious, i am reluctantly willing to
> > > duck and cover in the interest of timely progress on other issues
> > >
> > > perhaps if i had not been prevented from being able to join you in san
> diego,
> > > i would be better equipped and able to anticipate how controversial
> this
> > > might be
> > >
> > > regards,
> > > jdc
> > >
> > 
> > Thanks,
> > /jon
> > --
> > 
> > Jon Saperia                  [email-masked]
> >                              Phone: 617-744-1079
> >                              Fax:   617-249-0874
> >                              http://www.jdscons.com/
> 
> -- 
> ---
> David Harrington            Network Management Standards Architect
> [email-masked]           Office of the CTO
> +1 603 337 2614 - voice     Enterasys Networks
> +1 603 332 1524 - fax       Rochester NH, USA

---

From: David Partain <[email-masked]>
Date: Mon, 22 Jan 2001 13:22:51 +0000

Howdy all,

Co-chair hat off, techie hat on (I have one here somewhere...).

When the idea of the setcli() (or system() or whatever) came
up, I was quite opposed to the idea.  It's an ugly hack (just
like the "system" system call is), and it, in some sense,
subverts the goal of this work.  We don't _want_ to write a
different policy script for every different kind of device we
have in our networks.

Then I got blind-sided by reality and changed my mind.  The fact
of the matter is that much of what you want to configure with
policy scripts cannot be twiddled with using SNMP.  This is
unfortunate, but it's also true.  We can choose:

 - to accept the reality and say that, nonetheless, doing things
   with SNMP objects is the Right Thing to Do.  This means that
   standards organizations and enterprises will need to get to
   define the appropriate objects and include agents that allow
   you to do sets to those objects

 - to accept reality and say that because it is reality, we're
   going to put in a "short-term" mechanism that allows you to
   change the device using existing configuration mechanisms.
   One of the most common ways is via a CLI, so the initial
   suggestion was that.

I greatly fear that if we do not adopt the latter of the two,
with all of its warts, we're going to limit the utility of what
we're creating very significantly.  I realize it's not pretty
and breaks some of the fundamental tenets of what we're about,
but I think we must do what can reasonably be done to include
this functionality.

With kind regards,

--
David Partain                  [email-masked]
Ericsson Radio Systems AB      Tel:    +46 13 28 41 44
Research and Innovation        Fax:    +46 13 28 75 67
P.O. Box 1248
SE-581 12  Linköping, Sweden

---

From: Andrew Smith <[email-masked]>
Date: Mon, 22 Jan 2001 10:22:23 -0800

Dave,

Of course the only really pragmatic solution is to standardise on that single 
CLI language. Oh ... OK ... we're all doing that already ... :-)

Seriously though, the more groups like this one go with your option 2, the 
longer such "short-term" solutions hang around.

Andrew

---

From: "Wayne F. Tackabury" <[email-masked]>
Date: Mon, 22 Jan 2001 14:57:26 -0500

>but I think we must do what can reasonably be done to include

For general purpose applicability, it's been our experience that this is 
absolutely true.

Let me give an example I haven't heard articulated before.  Going forward, 
it will be impossible to tune configuration scripts for operation in a 
given environment where a given configuration control, as represented in a 
MIB object, must have its conflicts/coordination with some vendor-specific 
control tangentially covering the same function handled in some agent 
environment.  This could easily show up in the adoption of a new version of 
the agent image which hasn't had updated MIBs either standardized or 
implemented.  I don't think that "wait for the vendor to update the vendor 
MIB and tune the scripts then" to cover that control will work in practice.

I could conjure examples that aren't very far from real world 
conditions--and as far as these "CYA" escape mechanisms go, in our product, 
we've been spooked enough by this risk to have actually extended them into 
two dimensions.  But regardless, in many agents, without a setcli() or 
something like it, snmpconf applicability will be academic at best.

And I've intentionally avoided the more obvious case--whole control 
functions which are essential and not (yet) configurable via SNMP by virtue 
of MIB incompleteness.  I know that's not a situation we want to allow 
proliferation of by providing setcli(), but I think that's a risk we'll 
have to take. Indeed, for many of its good points, one of the big problems 
I see with COPS as a provisioning vehicle is the lack of awareness of these 
issues of integration with legacy (or rather, current :) PEP implementation 
agent architectures.

Does it help at all that setcli() really should be an open ended interface, 
in that it takes a raw character string, and intentionally doesn't specify 
semantics of that string?  Am I being naive?  Since any script with 
setcli() in it will need to be tuned for the vendor environment anyway, I 
think that issues such as execution latency, whether a cli command needs to 
be specified with an end-of-line, or whatever can be deemed as agent 
implementation-dependent.  I think this falls under what Joel called only 
specifying "the existence of a steering wheel and its rough shape"--we need 
little more here to get what we're after.

Now, circa San Diego, I seem to recall that the only open issue here that 
intrigued me was whether we could assume agent feasibility to issue a raw 
textual CLI command as a "loopback" in the agent environment, from the 
point where the setcli() implementation would want to dispatch the 
command.  In other words, are there any potential agent vendors here who 
for some reason have trouble architecturally dispatching a cli command 
internally from the running snmpconf agent?  Perhaps this was resolved, 
forgive my resurrecting the question if so.

Regards,
Wayne

--------
Wayne F. Tackabury		Internet: [email-masked]
Gold Wire Technology		Phone: (781) 647-2211, x213
411 Waverley Oaks Rd., Ste 331
Waltham, MA  02452             Cell: (617) 699-6156