Multiple "Running" configurations

["Allen, Keith" <Keith_Allen@labs.sbc.com>]

All,

Naturally, we couldn't solve all of the issues that came up during the
interim working group meeting last week, or even to discuss them all in
depth.  I thought, though, that an issue that David Harrington brought up
was particularly sticky, especially given some of the decisions that were
made during the meeting.

The protocol is being developed to enable operations on configurations
stored on an Internet device.  One configuration, the "running"
configuration, has a special meaning - it's the configuration currently
active on the device.  The protocol as it is currently envisioned identifies
operations on this configuration with a special "<running>" XML tag.  The
problem brought up by David (correct me if I mischaracterize this, David)
was that some devices might have multiple running configurations (running on
separate cards, for example), and he would like to see the protocol support
operations on devices of this type.

The general tone of the responses to David's issue seemed to be that even
though a device might have several different configurations active at one
time, they are all part of the "grand configuration" (my term) of the
device.  If these devices support the NETCONF protocol, they will be
responsible for presenting their multiple running configurations as snippets
of the grand configuration of the device.

This is certainly possible, and I think reasonable.  The problem is,
currently only the get-config and edit-config operations operate on subsets
of a device's grand configuration.  Other important operations, such as copy
and lock and validate, do not.  So, it seems that either the devices of
concern to David will have to live with this restriction, or the protocol
will have to be modified by enabling these other operations to also operate
on snippets of configurations.  I fear the former may not sit well with
David and perhaps others, but the latter has some rather negative
implications, too.  Does anybody see another way around this?

I think if we're going to consider modifying those operations, we should
address it soon.

Keith Allen
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
keith_allen@labs.sbc.com


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>