[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Verbs Again
I see one big difference between state data and config data that is read
only on a *specific* device. My point is that config data is potentially
writable, just not on the device in question. To keep with the syslog
sample: I could modify stock syslogd to accept configuration via a
hypothetical syslog-streams configuration object (the same that's
queried). So in theory it is for read-write access. Some devices might
actually grant read-write access, some just read access (because their
vendor doesn't care about implementing write access for whatever reason)
and some others do not implement it at all.
I think this idea is beyond syslog. I agree with Andy that the netconf
WG most probably is not the right place to discuss syslog data models.
Unfortunately, the syslog-sec WG is also not the right place (being in
the security area and chartered to just provide a secure transport). It
might make sense to try to form a WG that looks at syslog configuration
and content standardization.
> -----Original Message-----
> From: Phil Shafer [mailto:email@example.com]
> Sent: Wednesday, June 28, 2006 6:09 PM
> To: Rainer Gerhards
> Cc: Martin Bjorklund; firstname.lastname@example.org;
> email@example.com; firstname.lastname@example.org
> Subject: Re: Verbs Again
> "Rainer Gerhards" writes:
> >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.
> The benefits of having this appear as config are lost if it's
> read-only. At the point, it becomes state data, where I agree, one
> should be able to reasonably represent device-specific state (whether
> from defaults or config) in a standard way. This is pretty much
> what <get-syslog-streams> does.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.