Patrick, Thanks for your review.
Regarding the severity leaf: multiple severities are already covered when severity is specified because the default severity comparison is all messages of the specified severity and greater. You can use of the optional pattern-match string to select a message with a specific priority (includes severity and facility). If you need further filtering capability, you could add this through augmentation of the log-selector container. Regarding the specification for the remote destination: in an earlier review it was required that the model conform to the recommendation in Section 3 of draft-schoenw-netmod-yang-pattern-00. Your proposal does not follow that pattern. Regarding the leaf nodes to be added request: - The presence or absence of a leaf in the log-actions container indicates whether the intended action is enabled/disabled. This pattern is used for all log actions. - The proposed ietf-syslog model does not include operational state or notifications. Operational state in the model's config section would have to be flagged as such. Please refer to the "State Data" statement from RFC 6020 section 4.2.3. - A custom-prefix leaf to prepend a custom signature for each log message could be added though augmentation. If there is a consensus that this should be added for all implementations I will gladly add it. Thanks, Clyde From: "Hinshaw, Patrick" <[email protected]<mailto:[email protected]>> Date: Tuesday, March 1, 2016 at 11:22 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: draft-ietf-netmod-syslog-model Resent-From: <[email protected]<mailto:[email protected]>> Resent-To: <[email protected]<mailto:[email protected]>> Resent-Date: Tuesday, March 1, 2016 at 11:54 PM Hello, There are a few leaves in this current draft that I believe should be altered, as well as a few that should be added. First, the severity leaf node in the syslog-severity grouping could be changed to a leaf-list node. This will enable a user to choose any combination of severities, instead of being strictly limited to a range. This functionality would be used when the severity-operator leaf is set to “equal”. Second, in the remote container, there is a list called “destination” with the key “name” of type string. Another way to do this would be to change this type to inet:host, as well as adding a new leaf node that holds the resolved IP address of type inet:ip-address (read-only). We would in turn delete the leaf node “address” under both the tcp and udp choice statement. This would eliminate the need to create an arbitrary name for each server, having the hostname as the list key seems to be the more intuitive approach. Lastly, there are a few leaf nodes that I believe should added to the remote container: 1) An administrative state leaf node to enable/disable the remote server. 2) An operational state leaf node to see the operational state of the remote server (This is read-only). a. Both of these nodes would allow the user to be aware of the status of their syslog servers, something this model is currently lacking. b. Both would be enumerated types with values enable and disable. 3) A custom-prefix leaf node of type string allowing a custom signature to be prepended to each syslog message. Here’s a tree of the remote container made in pyang showing the changes I’ve proposed. Note that these changes will affect other containers using the severity node from the syslog-severity grouping: module: draft-ietf-netmod-syslog-model-06 …. +--rw remote | +--rw destination* [name] | +--rw name inet:host | +--ro resolved-ip? inet:ip-address | +--rw (transport) | | +--:(tcp) | | | +--rw tcp | | | +--rw port? inet:port-number | | +--:(udp) | | +--rw udp | | +--rw port? inet:port-number | +--rw log-selector | | +--rw (selector-facility) | | | +--:(no-log-facility) | | | | +--rw no-facilities? empty | | | +--:(log-facility) | | | +--rw log-facility* [facility] | | | +--rw facility union | | | +--rw severity* union // now a leaf-list node | | | +--rw severity-operator? enumeration {selector-severity-operator-config}? | | +--rw pattern-match? string {selector-match-processing-config}? | +--rw destination-facility? identityref | +--rw source-interface? if:interface-ref | +--rw custom-prefix? string | +--rw administrative-state? enumeration | +--ro operational-state? enumeration | +--rw syslog-sign! {signed-messages-config}? | +--rw cert-initial-repeat uint16 | +--rw cert-resend-delay uint16 | +--rw cert-resend-count uint16 | +--rw sig-max-delay uint16 | +--rw sig-number-resends uint16 | +--rw sig-resend-delay uint16 | +--rw sig-resend-count uint16 …. Please let me know what your thoughts are on these proposed changes. Respectfully, Patrick Hinshaw [email protected]<mailto:[email protected]>
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
