Subject: [netmod] Some feedback on syslog-model-03

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Fri, 27 Mar 2015 00:22:44 +0000

Hi all,

During a number of discussions this week with other vendors and operators I was encouraged to ensure that I raise comments/issues from ALU with some of the YANG models underway including syslog.  Clyde and I met this morning and we thought it would be good for me to post the comments to the list.

I'm going to break the comments into a few email threads - it sometimes gets confusing if too many issues are combined into a single discussion.

-----------------------------------------------
A) clarify syslog-selector behavior
-----------------------------------------------

It would be good to clarify the behavior of the selector/filter in the draft text & yang module. If we consider the use of the syslog-selector inside the message-distributors (buffered-logging-action, file-logging-action, etc) I believe the intended behavior is that when a selector is used/configured then it is effectively a "default deny" filter that only allows log events to pass the selector if they match the configured facility+severity (or the configured severity).  In other words -> if there is no <severity> or <facility> tags inside a <buffered-logging-action> (i.e. no selector config) then no log events would go to the buffer.

I'm a little less clear on the expected behavior or need for the <none> (case logging-facility-none) leaf. Isn't it just equivalent to the absence of any <severity> or <facility> items configured ?

We should also be explicit that the (basic) severity selection is an 'equals-or-higher' severity decision (note that although lower severity enum values are actually more critical than higher values, e.g. emergency=0, we should describe this in terms of severity/criticality IMO).

Is all the behavior above (including <none>) intended to be the exact same for the optional global-logging-action ?  If that is the case and the feature is supported on a platform then I think that means that no global config would mean no log messages sent to any distributors.

I'm happy to help construct some specific text/descriptions but wanted to make sure I understand the intent first.

-----------------------------------------------
B) structured data as a single feature
-----------------------------------------------
There are currently two structured data related features.  Should we combine that into a single feature ?  Do the vendors who support this not tend to then support it for both files and remote destinations anyways ?

-----------------------------------------------
C) max sizes/numbers for logs
-----------------------------------------------
There are a few places where a size is configured (buffer-size, file-size). Implementations will vary on what units are used in a way that isn't really directly convertible (e.g. bytes vs # of log messages).

For file logging some implementations use a retention time rather than a size limit or file number limit so I'm glad to see an if-feature around this (or remote it and let the vendor augment for that)

It is probably more common to have a size for the memory buffers so that is probably OK to leave in.

Whatever sizes remain in the model:
- remove any default values
- explain in the description that "This leaf specifies the maximum xyz size.  The units are not specified in this model and varies by implementation (e.g. bytes vs number of log messages)."

-----------------------------------------------
D) terminal distributor and persistency
-----------------------------------------------
Terminal logging is session-specific in several implementations and config generally disappears once the session is done.  It is also not clear what logging to the local session should really mean for a netconf session.  I'm not sure this distributor should be in the model.

-----------------------------------------------
E) editorial/minor misc
-----------------------------------------------
- Should we update the WG chair name (David Kessens) ?
- I'd suggest 'list logging-facilities' and 'key "facility"' be changed to 'list facility' with 'key "facility-name"'.  If a list is in a container then the plural name makes sense for the container but I think singular is better for the list (like how ietf-interfaces is done).
- The introduction says "We are using definitions of Syslog protocol from [RFC3164] in this draft." but the YANG model mostly references 5424.
- In section 3 instead of "group level" perhaps it is better to use "global level" (and in the figure) ?  I'm not sure what group means (which group - implies it isn't necessarily the entire log stream).
- Maybe use the term "Remove Collector(s)" instead of Server(s) ? Collector seems more in line with RFC5424 (or "Remote Receiver" if others prefer that).
- In the Section 3 figure make all the Distributors have a common use of plural vs singular "buffer(s)", "Log File(s)", "Remote Collector(s)".   User Terminal should probably be singular.
- Document is missing the standard legend for the PYANG tree

Regards,
Jason

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Mar 2015 02:12:32 +0100

Assuming that the number of widely used differences is small, I think
this should be modeled properly and features may be used to announce
which of the options is supported. This way, I can write a robust
network management application that does not simply configure 42 and
then hopes something meaningful will happen. An API contract needs to
be tight to be useful.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>