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

From: "Durham, David" <[email-masked]>
Date: Mon, 22 Jan 2001 17:00:12 -0800

I would like to add my voice to the chorus dismissing a setcli accessor
function as a *REALLY* bad idea. 

David, we are here to do the right thing from the perspective of promoting
real standards. Promoting this subversive "ugly hack" runs exactly to the
contrary of that goal. Allowing the current bad habits to continue under the
guise of a standard is akin to providing all the booze you want to drink at
the local alcohol rehab center. 

-Dave

> -----Original Message-----
> From: David Partain [mailto:[email-masked]]
> Sent: Monday, January 22, 2001 5:23 AM
> To: [email-masked]
> Subject: Re: snmpconf 11. Setcli accessor function - Item to 
> be resolved
> o n email list 
> 
> 
> 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: David Partain <[email-masked]>
Date: Tue, 23 Jan 2001 12:50:58 +0000

Greetings,

> the local alcohol rehab center.

On a fundamental level, I _absolutely_ agree with you.
What I don't know how to do, given what you write, is how
to solve the _immediate_ problem of managing very complex,
large networks with IPsec/diffserv capabilities.

Assuming we do not add setcli(), how are we going to be able to
deliver products which can be used to networks that exist today?
Because I couldn't answer that question to my own satisfaction,
I grudgingly accepted the idea of a setcli().  I'd be thrilled
if there were another answer.

I would also note that having a CLI driver is exactly what most
"policy-based management" systems today use for configuring a
large subset of the devices that exist today.  This is no worse
than that, and, in my opinion, is a step forward by integrating
the SNMP capability that we have and is being added.

With kind regards,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Jan 2001 09:55:05 -0500

Given that even with setcli the scripts will have to be customized, the 
answer to "how do we do this now" is one small step short of standardizing 
setcli.  We recognize that vendor extensions are inevitable.  We document 
(as with SNMP) where vendor extensions go so that they do not colide with 
standard items (it does not matter in this case if they colide with another 
vendors extensions).  And we leave it at that.  If the vendor decides that 
setcli (or system, or ...) is the right answer, they can do that.  If they 
decide that some more specific escape functions are what are needed, they 
can do that.  And the question of how the mechanisms should itneract with 
both the standard SNMP security and the vendor's own security mechanism is 
then clearly up to the vendor.

After all, there is no way we can mandate a useful setcli function when we 
can not say what it will do.  So putting setcli in the spec does not 
actually ensure that the vendors give the users sufficient hooks to 
actually solve the problem.

Yours,
Joel M. Halpern

---

From: David Harrington <[email-masked]>
Date: Tue, 23 Jan 2001 10:21:23 -0500

Hi DD,

Religious standardization is nice - I frequently practice it myself -
but we need to solve the real-world problems of our customers or our
solution simply won't be useful.

For the snmpconf standard to be accepted, we need to convince users to
use it, but even more importantly we need to convince device vendors to
support it in their products. We will need to convince every vendor to
make all their products completely policy-manageable using strictly SNMP
objects. After twelve years of trying, the SNMP community hasn't even
achieved the goal of making it possible to just monitor using strictly
SNMP yet, never mind having it all based on standardized mibs. 

What makes you think that suddenly the industry is going to reverse
itself and believe that all their devices should be totally manageable
using SNMP objects, to the point that the CLI won't need to be supported
to configure devices?

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