Subject: Re: snmpconf 11. Setcli accessor function - Item to be resolved on email list

From: Jeff Case <[email-masked]>
Date: Tue, 16 Jan 2001 11:55:31 -0500 (EST)

>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

---

From: Jon Saperia <[email-masked]>
Date: Wed, 17 Jan 2001 14:50:48 -0500

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 would be better equipped and able to anticipate how controversial this

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

---

From: David Harrington <[email-masked]>
Date: Thu, 18 Jan 2001 14:32:31 -0500

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

-- 
---
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: "Joel M. Halpern" <[email-masked]>
Date: Thu, 18 Jan 2001 15:22:22 -0500

It has been observed by several people that vendors wille xtend the library 
function collection.  They will define their own functions.

Thus, the trade-off is between doing a thurough job of defining this setcli 
/ system function, including mandated error behaviors and security issues,
or just leaving it for vendors.

To use your analogy, it is not that I want you to have a car with no 
steering wheel, but rather that the state of the industry is such that 
there is no standard shape for the steering wheel.

Yours,
Joel M. Halpern