Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

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 <netmod-bounces@ietf.org> on behalf of Kent Watsen <kwatsen@juniper.net>
Sent: Wednesday, 14 December 2016 2:01 p.m.
To: netmod@ietf.org
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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod