RE: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)

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

Andy, 

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Tuesday, June 27, 2006 8:53 PM
> To: Phil Shafer
> Cc: Sharon Chisholm; netconf@ops.ietf.org
> Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
> 
> Phil Shafer wrote:
> > Andy Bierman writes:
> >> Unless standard data shows up in exactly the same place,
> >> with the same syntax and same semantics, using the <get> operation,
> >> then it isn't a standard that meets this requirement.
> > 
> > Does <get-config> pass that test?
> > 
> >> Data model discovery becomes quite a nightmare if a manager
> >> has to know priori, each different set of special RPCs to
> >> use for every device it manages, and try them all to discover
> >> the entire device configuration and state.
> > 
> > Yes, this is a hard problem.  But thinking that all devices will
> > instantly converge on a new standard data model won't fly. 
> 
> 
> This is where we strongly disagree.
> If they want to conform to the standard "notification" capability,
> then they will do everything that is specified, including
> implementing the tiny standard data model in the spec.

Phil wants to transport syslog messages. I do not think there is a
specific data model for a syslog messages needed, at least at this time
and in the NETCONF WG alone. The entity "syslog message" is
well-defined, so you do have a single element inside a syslog event
notification. Over time, I agree, it would be useful to have an extended
data model that specfies detailled semantics for syslog messages (and
probably notifiation messages at all). This, however, I think is far
beyond the current discussion. I consider it to be a separate effort,
probably even in a separate WG that draws people from the syslog and
netconf WGs.

Syslog stream configuration, IMHO, could relatively quickly be done
because this is something that merely happens in the netconf-syslog
draft context. I can also envison that a generic syslog rule
configuration data model can quickly be done. One, that takes into
account what almost all syslogd implementations supports. It may require
two optional capabilities, but you would immediately be able to capture
the majority of syslog receivers and relays. I am not so experienced
with schema defintion, but I am tempted to write a quick draft on a
basic syslog config schema. I defintely know what is required inside the
model (acting as a least common denominator approach).

> 
> I will be even more clear -- the standard data models
> for netconf will be usable with the existing standard netconf
> operations.  I doubt the co-Chairs and ADs will except
> a solution that did otherwise.
> 
> If the data is particularly complicated (e.g., deeply
> nested data structures with complex keys), then special
> RPCs in ADDITION to the standard RPCs may be useful,
> which do not redefine data, but rather simplify access to
> the nested data instances within the overall target data model.
> 
> In this case, I don't think the notification data is complicated
> enough to warrant additional special RPCs, but we haven't finalized
> the data model at all, so who knows right now.

I think this is not just a data model question. Something like
<get-syslog-events> is not a datamodel thing, at least I think so. It
definitely is not configuration data, so <get-config> is out of
question. I also do not consider it to be state data, so I have some
concerns on <get>. What else would be the right verb to transport
notification data?

Rainer
> 
> 
> Andy
> 
> 
> 
> 
>   The
> > difference between the model and the device can be ignored 
> or painted
> > over for monitoring (ala SNMP MIBs) but when you move into
> > configuration, it's the details that matter.
> > 
> > So my proposal is to fly little fish first.  If your application
> > wants to get notification data, it has to know a priori that it
> > gets the list of streams via one RPC and gets the notification data
> > via another RPC.  Come to think of it, even if you had all this
> > hidden under <get>, your application would still have to know the
> > magic filter to pass in to get the list of streams and the magic
> > filter to pass in to get the notification data.  The difference is
> > whether you put this knowledge in the RPC (name and arguments) or
> > the filter's XML content (and the schema that defines it).
> > 
> > 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/>