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

From: "Durham, David" <[email-masked]>
Date: Tue, 23 Jan 2001 14:52:21 -0800

> -----Original Message-----
> From: David Partain [mailto:[email-masked]]
> 
> 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.

[Dave] There is the Diffserv MIB, you can use that as a standard set of
managed objects. There are a set of PIBs for managing large IPsec/DiffServ
networks which are also expressed using standards-tract managed objects. 

Basically, with setcli, SNMPConf is: 1. Not using the SNMP protocol for
configuration; 2. Not even utilizing MIB objects for configuration; and 3.
Not providing legitimate standards for configuration. In short setcli
fundamentally violates the charter for this working group. So unless there
is the intention to invert the charter, I suggest that this group focus on
delivering standards based mechanisms for network configuration, and not
backdoor hacks into CLI. 

> 
> 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.
> 
[Dave] Use the standard managed objects that already exist or are coming
into existence. Otherwise invent the ones that are missing (the WG charter
says that's a goal), and/or encourage vendors to expose vendor specific
functionality through private managed objects. If this WG endorses a
backdoor to CLI, this will only work to subvert the standards process, and
discourage companies from exposing device configuration through managed
objects.

> 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.
> 
[Dave] If SNMPConf can only work via non-standard hacks into vendor
proprietary CLI, then it  becomes painfully obvious that one really can't do
configuration management via SNMP.

---

From: Jon Saperia <[email-masked]>
Date: Wed, 24 Jan 2001 09:11:19 -0500

Since, I started this thread to get consensus, we have had a number of 
messages. I will catch up on them and see if I can form a consensus statement. 
I suggest we close discussion on this point by tomorrow so we can move on to 
the other items on  the  list. Soo... if you have anything to add that you 
have not already, please do so by close of business tomorrow.

Thanks,
/jon
--

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

---

From: Mike MacFaden <[email-masked]>
Date: Wed, 24 Jan 2001 10:36:46 -0800

Riverstone Network's position:

1) We do not need a  "setcli()" 

2) We favor an explicit definition in the document as to how vendor extensions, if any,
can be added in a way that does not interfere with how this mechanism is
meant to operate.

Regards,
Mike MacFaden
www.riverstonenet.com

---

From: John Schnizlein <[email-masked]>
Date: Wed, 24 Jan 2001 13:42:13 -0500

Just a reminder: IETF is an organization of individual contributors,
not and organization of companies (or any other organizations).
Therefore the position of any company has no standing here.
Technical reasons from any interested person have standing, and are valued.

John

At 10:36 AM 01/24/2001 -0800, Mike MacFaden wrote:
>2) We favor an explicit definition in the document as to how vendor 
>extensions, if any, can be added in a way that does not interfere 
>with how this mechanism is meant to operate.
>
>Regards,
>Mike MacFaden
>www.riverstonenet.com
>

---

From: Mike MacFaden <[email-masked]>
Date: Wed, 24 Jan 2001 12:05:44 -0800

Thanks John.

g/Riverstone/s//My
g/We/s//I

Regards,
Mike MacFaden

---

From: Jon Saperia <[email-masked]>
Date: Thu, 25 Jan 2001 11:03:07 -0500

Mike Wrote:

> extensions, if any, can be added in a way that does not interfere with
> how this mechanism is meant to operate.

Mike, as you know I am attempting to see what type of consensus there is
on the Setcli issue. As I think about it, the sentence you wrote above
is not quite clear to me. Can you add a bit more explanation?

Thanks,
/jon
--

---

From: Mike MacFaden <[email-masked]>
Date: Thu, 25 Jan 2001 12:06:32 -0800

>is not quite clear to me. Can you add a bit more explanation?

I favor an explicitly clear definition as to the boundry between standard things
and vendor added things.

As an example, the C Language Spec: ISO IEC C 9899:1999 
Section 7.1.3 provides for ways for vendors to introduce extensions:

  - All identifiers that begin with an underscore and either an upppercase letter
    or another underscrore are always reserved for any use.
  [snip]
   - If the program declares or defines an identifier in a context in which it
     it is reserved (other than allowed by section 7.1.4), or defines a reserved
     identifier as a macro name, the behavior is undefined.

The Microsoft C++ compiler was thus able to introduce various extensions
such as their support for 64 bit integers prior to the current C standard 
by using the data type: _int64 

The characteristic I most like is that its easy to determine
what is non-standard. 

I think we should avoid vendor extensions if possible by having a
fully functional model but I don't want to rule them out if someone wants
to try something out.

Regards,
Mike  MacFaden
www.riverstonenet.com