[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





Randy Presuhn wrote:

> 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.

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:smith@phone.example.com">
               <disconnected causeCode="CAUSE_BUSY">
                <routeCall connectionPtr="conC">
                 <arguments>

           <targetAddress>sip:smith@voicemail.example.com</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.


> 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.

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


Regards,
Steve