RE: Verbs Again

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

Phil,

I can not fully agree with you here. My understanding is that you can do
something like this (probably with a different URN):

      <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config";>
             <syslog-streams/>
           </top>
         </filter>
       </get-config>

I understood netconf-prot so that a config must not necessarily be
writeable. Of course, that would be best. But looking at your scenario
below: what if you create the syslog-streams object by whatever
vendor-specific method you have but still provide read-only access to a
standardized (but virtual) syslog-streams object? So even the
configuration does not natively support syslog-streams, it still allows
a manager to deal with your syslog-streams, provided you advertise the
capability. If then I modify the stock linux syslogd to support netconf,
I could also provide read-only access to a standardized syslog-streams
object. Again, it would be virtual, because my stock syslogd config is
quite different from what you have in your JUNOS config.

The benefit of these virtual read-only syslog-streams config objects
would still be that a manager could handle them in a vendor-neutral way.
Even though different vendor-specific data models are required to setup
that virtual config, it could be useed in a device-independent way.

As far as syslog is concerned, I think a useful least common denominator
writeable syslog-config object could also be defined. It is my firm
belief that it would not be much of a burden to implement this even on
very different configuration models (because the base objects are quite
obvious and supported by all implementations anyway).

I hope I have not overlooked anything obvious.

Rainer

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer
> Sent: Wednesday, June 28, 2006 5:10 PM
> To: Martin Bjorklund
> Cc: ietf@andybierman.com; schishol@nortel.com; netconf@ops.ietf.org
> Subject: Re: Verbs Again 
> 
> 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/swconfig
> 76-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/swconfi
> g57-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/>
> 

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