Subject: Re: snmpconf draft-bakker-jain-scml-00.txt

From: Randy Presuhn <[email-masked]>
Date: Mon, 19 Nov 2001 17:46:31 -0800 (PST)

Hi -

> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: Re: snmpconf draft-bakker-jain-scml-00.txt 
> From: Jon Saperia <[email-masked]>
> In-reply-to: Your message of Fri, 16 Nov 2001 16:34:28 -0800.
>              <[email-masked]> 
> Date: Mon, 19 Nov 2001 08:47:36 -0500
...
> I was unaware of this until your post. I spent a very short time with it
> and it seems like it is not as directed at the managed devices as is the
> case with the Policy Module. Have I got this wrong? It is clear though
> that there are some concepts that are the same such as
> capabilities. 
...

I'm not too sure how to read "directed at the managed devices".
In the case of snmpconf, it seems almost tautological, since if
it's not a managed device, we really can't do too much with it.

I think both documents leave quite a bit of freedom as to
whether the entity executing the policy specification will
be the one whose configuration is consequently modified.

A few points where I think this I-D is on the right track:

   1) explicitly leaving open the possibility of both compiled
      and interpreted script execution, rather than requiring
      interpretation.

   2) its decision to use off-the shelf language(s), rather than
      a new one or changing the semantics of an existing one.

   3) compartmentalizing the special-purpose library additions
      to support this application.

But I didn't want to get into a lengthy discussion of the
details of this I-D; that would be better done with someone
knowledgeable.  It looked like something that should be of
some interest to this WG, so I posted a note.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Steve Waldbusser <[email-masked]>
Date: Tue, 20 Nov 2001 01:40:21 -0800

> be the one whose configuration is consequently modified.

I agree on both points. The differences are elsewhere.

 The SCML language defined in that document isn't a programming language (it
specifically says so in their document), so it doesn't have expressions or
program control (iteration and such). Here's what it looks like:

      <scml>
            <terminating>
             <address-switch field="terminating">
              <address is="sip:[email-masked]">
               <disconnected causeCode="CAUSE_BUSY">
                <routeCall connectionPtr="conC">
                 <arguments>

           <targetAddress>sip:[email-masked]</targetAddress>
                 </arguments>
                </routeCall>
               </disconnected>
              </address>
             </address-switch>
            </terminating>
           </scml>

                     Figure 2, Example SCML Fragment: Voicemail on Busy

It's a machine parseable static definition of data. In the SNMP world our
analogy would be:
ipForwarding.0 = 1
ipRouteIfIndex.0.0.0.0 = 1
ipRouteMetric1.0.0.0.0 = 0
ipRouteNextHop.0.0.0.0 = 192.168.1.1
ipRouteType.0.0.0.0 = direct(3)
ipRouteProto.0.0.0.0 = local(2)
ipRouteMask.0.0.0.0 = 255.255.255.255

(If you collected these commands into a file called setDefaultRoute.snmp and
then later piped it into an SNMP tool I think it's fair to say you wrote an
SNMP script of sorts. I used to do this years ago. However, it's only useful
for the most simplistic things.)

Another example of the same genre is CLI.

The first problem with SCML specifically is that it's in a whole different
schema/framework, so throw away all MIBs and all instrumentation and start
over. The second problem is with the lack of programmability. For example, in
my ipRoute example, the statement "ipRouteIfIndex.0.0.0.0 = 1" is problematic
because you really don't know if if#1 is the correct interface. You want to
say "ipRouteIfIndex.0.0.0.0 = getIfIndex("eth0/0")"

Such collections of data are very useful in describing bootup configs, where
you're starting from a known (zero) configuration. Many things require human
intervention after that. One reason is that while they are great for adding
things (each statement is an assertion that something should exist), they are
less good for deleting things. For example, if I wanted to replace a mess of
192.168.*.0 subnet routes with a single 192.168.0.0/255.255.0.0 route, the
only way to specify that is to "clear route" and then apply the config from
that base, but that's a bit heavyweight. CLI users will recognize this
problem.

A while ago I thought this might be a good approach but after I tried
sketching it out I exhausted all the possible fixes I could think of and gave
up.

> some interest to this WG, so I posted a note.

Thanks. I think it's also relevant to the XML CLI discussion in the NM area.

Regards,
Steve