[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Verbs Again
I can not fully agree with you here. My understanding is that you can do
something like this (probably with a different URN):
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.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Phil Shafer
> Sent: Wednesday, June 28, 2006 5:10 PM
> To: Martin Bjorklund
> Cc: email@example.com; firstname.lastname@example.org; email@example.com
> 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,
> 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:
> 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.
> 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.
> to unsubscribe send a message to firstname.lastname@example.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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.