I am considering to implement the data model in this draft.
I have reviewed this draft and found the following issues. In approximately
decreasing order of severity:
* In the "selector-facility" choice statement the cases have misleading names -
the case where no facility is matched is named "facility", and the case where
specific facilities are matched is named "name". I suggest "no-facilities" and
"specified-facilities", or similar.
* I disagree with the premise of the "no-facilities" case, which is that it can
be used to disable a log action, according to the description:
description
"This case specifies no facilities will match when
comparing the syslog message facility. This is a
method that can be used to effectively disable a
particular log-action (buffer, file, etc).";
If an administrator wants to disable a log action they should do it by either
removing it from the configuration, or by setting an "enabled" leaf to false.
With that in mind, there is no reason for the "no-facilities" case to exist.
* What is the behaviour of a selector if neither "no-facilities" nor
"facility-list" is present?
* In the "selector" grouping it is not clear how the facility and pattern
conditions are combined to decide whether a message is selected.
Must they both match the message, or is it sufficient for either one to match
the message?
* Not all servers have a console; there should be a feature to indicate whether
logging to the console is supported.
* Likewise, not all servers may support logging to user sessions.
* Likewise, not all servers may support a user-accessible filesystem.
* RFC 5424 states that the severity and protocol values are not normative.
* It's not clear to me why this needs to be split into two modules. Is it so
that other modules can define logging parameters but still be usable on a
device without syslog?
* "log-severity" defines a severity filter, not a severity, so its name is
misleading.
* Perhaps the "severity" type and the facility identities should have
"reference" statements referring to RFC 5424, rather than referring to it in
the description.
* In section "8.2", "admisintrator" is a typo.
I assume that the means of accessing the memory buffer and log files are out of
scope of this data model.
Alex
________________________________________
From: netmod <[email protected]> on behalf of Kent Watsen
<[email protected]>
Sent: Wednesday, 14 December 2016 2:01 p.m.
To: [email protected]
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
This is a notice to start a two-week NETMOD WG last call for the document:
A YANG Data Model for Syslog Configuration
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11
Please indicate your support or concerns by Tuesday, December 27, 2016.
We are particularly interested in statements of the form:
* I have reviewed this draft and found no issues.
* I have reviewed this draft and found the following issues: ...
As well as:
* I have implemented the data model in this draft.
* I am implementing the data model in this draft.
* I am considering to implement the data model in this draft.
* I am not considering to implement the data model in this draft.
Thank you,
NETMOD WG Chairs
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
