Hi,
I am also considering an implementation.
I share the same concerns that Alex has brought up.
Some detailed comments:
1) /syslog/actions: seems like everything is in this container.
Why is it needed? Seems like it could be removed as it serves no purpose
2) 8 features: the granularity seems wrong. The main container for each
section
should have its own if-feature
/console
/buffer
/file
/remote
3) What is the 'buffer' container for?
How is the internal memory accessed by the client?
4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the
facility-list
5) pattern-match:
leaf pattern-match {
if-feature select-match;
type string;
description
"This leaf desribes a Posix 1003.2 regular expression
string that can be used to select a syslog message for
logging. The match is performed on the RFC 5424
SYSLOG-MSG field.";
}
The field SYSLOG-MSG is referenced but never defined or listed in
the terminology section.
6) how are the syslog-facility identities mapped to SYSLOG messages?
6a) how to distinguish acme:foo-facility from example:foo-facility in a
SYSLOG message?
7) source-interface: what if the server does not let a source interface be
used and instead
normal routing determines the source interface (this leaf is very
router-centric)
8) signing-options: are these widely deployed on all routers and Linux
hosts?
9) logrotate: there are several features related to log file cleanup
allowing lots of
server variability and forces the client to support all the options.
Can't this be simplified
and all the micro-behavior YANG features removed?
10) numeric limits: there is some odd usage of YANG types; some limits are
uint64, some uint32,
some uint16. Seems like uint32 is sufficient
Andy
On Tue, Dec 13, 2016 at 8:16 PM, Alex Campbell <[email protected]>
wrote:
> 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
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
