Hi Phil, Thanks for your review. My comments inline as [clyde].
On 10/31/16, 5:45 PM, "netmod on behalf of Phil Shafer" <netmod-boun...@ietf.org on behalf of p...@juniper.net> wrote: > Title : A YANG Data Model for Syslog Configuration I've a few questions: - The description says that the "facility/no-facility" case/leaf is used "to effectively disable a particular log-action". Why not make an explicit "disable" leaf instead? Using no-facilities like this is confusing. - Why use an explicit/mandatory selector node instead of making this implicit, with the lack of a selector meaning match all? - compare-op: we've always tried to use full words; would this be better as "compare-operation" or just "compare"? - equals-or-higher: you might want to explain that this is the default even in the absence of the "select-sev-compare" feature. (I'm assuming this is true.) - You use "facility" as both a case and a list under selector-facility. This seems confusing and misleading. [clyde] There have been numerous iterations of the filter specification to make it clearer, to simplify, and to include the requirements put forward by the vendors that we have worked with. I welcome your input to make it even better. We have reached agreement on the intent of the filter specification. Here it is in words: A selector consists of two parts: one or more facility-severity matches, and if supported via the select-match feature, an optional regular expression pattern match that is performed on the SYSLOG-MSG field. The facility is one of a specific syslogtypes:syslog-facility, none, or all facilities. None is a special case that can be used to turn off an action. The severity is one of syslogtypes:severity, all severities, or none. None is a special case that can be used to turn off a facility. When filtering severity, the default comparison is that all messages of the specified severity and higher are logged. This is shown in the model as “default equals-or-higher”. This behavior can be altered if the select-sev-compare feature is enabled to specify: “equals” to specify only this single severity; “not-equals” to ignore that severity; “equals-or-higher” to specify all messages of the specified severity and higher. [clyde] I agree that “compare-op” can be simplified to “compare”. - "structured-data": says "describes how log messages are written to the log file" but it applies to more than log files. [clyde] I will reword this to “This leaf describes how log messages are written.” - Consider making "syslog-sign" into "signing-options" or something similar, to be more clear. The "syslog-" prefix is not needed, since the reader knows we are talking about syslog, and the "sign" is not clear. Then you can remove the "sig-" prefix on the child nodes. [clyde] I will change “syslog-sign” leaf to “signing-options” if no one objects, and remove the “sig-“ prefix. - The "session" name is not clear, since there are many sort of sessions; would "local-users" be better? [clyde] An earlier version of the model supported a “user” action. Alcatel/Lucent requested that we rename the user action into a session action that could be augmented if needed to handle more than user sessions. - What purpose for the "actions" container serve? Can it be removed? [clyde] “actions” serve a purpose should a vendor wish to extend the model to support operational data ie “show log” or an RPC such as “clear log”. - "buffer" should be a feature, since many platforms do not implement it. [clyde] I will make “buffer” a feature since it is only implemented by Cisco and Alcatel/Lucent. - How does an implementation specify the set of valid characters usable for user names? [clyde] Would a pattern statement like ‘pattern "[0-9a-fA-F]*";’ solve this issue? - Many networking devices have special tags at the front of their messages, indicating the specific message. For example "%ASA-1-104001" in IOS, or "BGP_CEASE_PREFIX_LIMIT_EXCEEDED" in JUNOS. We carry these are specific SD-PARAMS when SD is used. Is there a way to filter using theses tags, or more generic SD-PARAMS? [clyde] We added the ability to filter anything in the SYSLOG-MSG field including structured data using a regular expression with the pattern-match leaf. That should cover this. Thanks, Clyde Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod