Re: Verbs Again

[Phil Shafer <phil@juniper.net>]

Martin Bjorklund writes:
>Again, suppose an agent actually did make this data configurable
>through NETCONF.  First of all, it would have to do this in a
>vendor-specific way.  Second, it would have to make this data
>available _both_ as a normal <get-config> part, _and_ as a new RPC,
><get-syslog-streams>.

The config is vendor-specific, by nature, and the translation from
this form to a standard data model isn't always straight-forward.

Take a look at the config groups and commit scripts features in JUNOS
and think about how the mapping from device config to standard config
isn't trivial:

http://www.juniperfederal.net/techpubs/software/junos/junos61/swconfig61-getting-started/html/cli-config-groups2.html

http://www.juniper.fi/techpubs/software/junos/junos76/swconfig76-automation/html/commit-scripts-overview.html

These are slick features that reduce the size and complexity of the
configuration.  The trade-off is that what you see from "show
configuration" (or <get-config>) isn't the config the system
components see (unless you use the "display" pipes).  In addition,
stuff like "inactive" configuration can cloud the issue further.

http://www.juniper.net/techpubs/software/junos/junos57/swconfig57-getting-started/html/cli-configuration-mode43.html

While these features are outside the WG's concerns, they are inside
mine ;^)

In operational mode, the user sees full operational impact of the
expanded configuration, so the CLI's "show log" will see all the
defined syslog streams, regardless of where they came from.  This
same information is available via the <get-syslog-streams> operation.

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