Re: Separation of protocol and information model

[Phil Shafer <phil@juniper.net>]

"Allen, Keith" writes:
>One of our concerns was that the specification of
>those named configurations, including <running> or <startup> or whatever,
>should be up to the vendor and not imposed by the protocol.

The specification of the supported configuration targets is not
imposed by the protocol.  The protocol requires that the device
support a single running configuration that represents the current
state of the box.  Other additional targets are discovered via
capabilities. If the device does not announce the capability for
candidate configuration, it does not have that target.

The protocol does not require the device to support a candidate
configuration, it just gives a way for the application to discover
that a candidate configuration (and the semantic constructs associated
with it) are supported by the device.

The draft includes capabilities for distinct startup configuration and
candidate configuration, but does not require either.  Their inclusion
is motivated by our desire to model how existing devices treat
configuration and the three most common models are:

- running configuration only (CatOS, ERX, others)
- running plus startup (IOS and clones)
- running plus candidate (JUNOS and clones)

By discovering the capabilities of the device, an application
can know how that device can be managed and what operations
have to be invoked to get a desired outcome.

Thanks,
 Phil

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